Changes in caGrid 1.3

The caGrid 1.3 Deprecation Plan details comprehensively the major deprecations and stable aspects of the caGrid 1.3 release. The notable aspects to the metadata infrastructure the retirement of the EVS, GME, and caDSR grid services. Full details of the retirement and the migration plans can be found on the aforementioned documents, but are summarized here.

EVS

The first is the migration from the caGrid-provided EVS grid service, to an EVS-team provided grid service. Previous versions of caGrid provided an EVS grid service, which was just a simple grid "wrapper" for the functionality provided by the EVS caCORE Application Service. As such, its functionality was entirely dependent upon that remote service, and caGrid provided no real vocabulary management, it just exposed EVS information to the grid. As part of the general retirement of the caCORE 3.1 Application Service which the EVS grid service relied upon, the EVS team took the responsibility of exposing vocabulary management operations to the grid themselves. caGrid users dependent upon such functionality are encouraged to leverage their distribution, and can find assistance in migration on their support site.

GME

For caGrid 1.3, the Global Model Exchange (GME) service was completely rewritten to address several limitations of the previous implementation and add numerous new features. The service still plays the same conceptual role in the infrastructure, and users should find the migration to the new service fairly trivial. For more details, see the GME section of the deprecation plan.

caDSR Grid Service

Similar to the EVS service, the caDSR grid service in previous versions of caGrid was completely dependent upon the caCORE 3.1 Application Service for all of the real "data" which the caDSR Grid Service provided. Like the EVS team, the caDSR team has taken the responsibility of providing the definitive grid access to the content their system provides. Such information is now readily available on the grid via the caDSR Grid Data Service. Aside from providing access to information in the caDSR, the caDSR Grid service provided the capability to generate Data Service metadata, and annotate caGrid standard service metadata. This functionality has been replaced by the Metadata Model Service (MMS). Users wishing to leverage this new API should find the transition fairly trivial, and the migration process is described in an appropriate section in the MMS Developer's Guide. The user experience of the caDSR Grid Service functionality of integrating with Introduce for discovery of data types and browsing the caDSR (see [this section|#Introduce Metadata Support Overview) for more details) is still maintained, though its implementation has just been changed to leverage the new APIs and services as appropriate. While the caDSR as a source of metadata information is still fully supported, the migration to use the MMS service now makes it possible to integrate other such repositories (or multiple caDSRs), through a common interface.

Index Service

In caGrid 1.3, the Index Service performance has been significantly improved, through the use of additional threading and primarily via its new XML Database backend (for more information, see the Index Service Administrators Guide). From the client's perspective, the service behaves in nearly the exact same fashion. Generally, clients do not directly interact with the Index Service, but rather leverage the Discovery Client. For those clients which do, all of the previous operations of the service are still supported. However, one behavioral aspect of the operations have changed. Whereas previously one could request the "full contents" of the Index Service (such as via a GetResourceProperty or root level QueryResourceProperties operation), for performance reasons, the service will now only return an internal identifier of the aggregated contents of each entry. In order to get the contents of the aggregated data, you can supply such an identifier to the new "GetContent" operation of the service. However, the service properly supports "query-through" behavior of these identifiers so most real world use cases will not need to leverage this operation, as it can always be replaced with an appropriately constructed query to return the data (i.e. only "root level" queries will not be populated with the aggregated metadata).