Introduce Metadata Support Overview

Several metadata-related features of caGrid manifest themselves as functionality in Introduce. Introduce is the graphical service development environment used in caGrid, and supports an extension framework, whereby functionality can be plugged into Introduce dynamically. While such functionality could have alternatively been implemented directly in Introduce, this approach promotes a loose coupling between the components without lose of functionality of any difference to the end user. This chapter details the various metadata-related Introduce extensions individually. All of these extensions are automatically installed into Introduce during the caGrid build process, and the caBIG Introduce Creation Viewer automatically loads the appropriate service-specific extensions to all services created with Introduce in caBIG.

caDSR Type Discovery

The caDSR Grid Data Service, provides read and query access to the information available in the caDSR. As such, the service provides useful information when creating services and so is integrated with Introduce as two extensions. Introduce has two types of datatype "discovery" extensions, which are both implemented for the caDSR. Specifically, there is a Discovery Tools extension, the CaDSRTypeDiscoveryComponent, and a Discovery Selection extension, the CaDSRTypeSelectionComponent.

The CaDSRTypeDiscoveryComponent, allows the user to browse registered Projects from the caDSR, and view a UML rendering of a selected package. This provides a means to browse the caDSR for available data types which could be used in the development of services. This component is a simple Panel, which uses the caDSR Data Service to populate the Project and Package combo boxes, and makes use of the MMS to generate Domain Models. The caGrid graph project is then used to render UML views of the generated Domain Models.

CaDSRTypeDiscoveryComponent

The CaDSRTypeSelectionComponent extension complements the CaDSRTypeDiscoveryComponent by providing a way to add XML Schemas to an Introduce service, which correspond to projects registered in caDSR. This component integrates into the "Import Data Types" section of the Types panel in Introduce. When a user browses to a particular package and presses the Add button, the component identifies the appropriate XML Schemas(s) for that package, and retrieves them from the GME. As of caGrid 1.3, the component makes use of the caDSR's ability to annotate Projects and Packages with their approproate XML Namespaces. If the selected Project and Package do not have such information registered in the caDSR, then the Namespace field will be populated with a guess based on XML Schema naming conventions, and will be shown in a blue font. The schemas may still be attempted to be added to the service using the Add button, but it should not be unexpected if an error is generated when the GME is consulted for those schemas. If the caDSR actually has such namespace annotations, then the Namespace field will be populated with the appropriate information, and shown in a black font. This indicates a much stronger confidence that such XML Schemas actually exist in the GME. Upon adding the schemas to the service, the extension will annotate the Introduce Namespace entries with details indicating the caDSR Project name and version from which they were extracted. This information can be used by other extensions (such as the caGrid Service Metadata Generator described below).

caGrid Service Metadata Generator

One of the most metadata-relevant Introduce extensions is a service-specific extension, which is actually a suite of components that hook into the Introduce service synchronization process when the extension is added to a service. These components comprise the Service Metadata Generator extension, and are responsible for creating an instance of the standard Service Metadata for a service whenever it is saved. The components, ServiceMetadataCreationPostProcessor, MetadataCodegenPreProcessor, and MetadataCodegenPostProcessor, run during the post creation, pre code generation, and post code generation processes (consult the Introduce design document for more details), respectively. The ServiceMetadataCreationPostProcessor is responsible for copying and installing the caGrid Service Metadata XML Schemas into the service, adding the appropriate metadata jars, and generating a shell Service Metadata instance. Then, each time a service is saved in Introduce, the code generation components read the Introduce model and edit the Service Metadata instance appropriately. That is, all of the descriptions from Introduce are put into the metadata, and all of the service contexts, operations, metadata, etc are updated. Essentially these components are responsible for extracting all the metadata-relevant information from the more complex Introduce service metadata model, and representing it in the caGrid standardized Service Metadata model. While somewhat laborious, the process is fairly straightforward. Upon editing the metadata model appropriately, the extension extracts any Namespace annotations that are present in the Introduce Namespace model (such as would be present if the schemas were added by the caDSR type selection component), and sends the model and annotations to the MMS Service for annotation.

A similar extension exists to generate standardized Data Service Metadata instances as part of the suite of Data Service Introduce extensions. Details about that extension and its functionality can be found in the Data Service design documents.

caGrid Service Metadata Editor

Complementing the Service Metadata Generator, an editor for the user-editable fields of the standardized Service Metadata instance of the service is provided as an Introduce metadata editor extension. The component, ServiceMetadataEditor, is a simple Panel that displays these fields from the current instance of metadata, and allows the user to edit and save it. Specifically the component allows the hosting research center information to be edited, including points of contact, address, and other information such as the display name and websites. It also allows the points of contact for the service to be edited.

ServiceMetadataEditor

caGrid Data Service Metadata Viewer

Similar to the ServiceMetadataEditor, the DomainModelViewer is an Introduce metadata editor extension. It provides a read-only UML display of the domain model to which the data service is providing query access. It uses the caGrid graph project to render the view, and simply reads the service's current Domain Model metadata instance to populate the view.

DomainModelViewer

caCORE SDK Schema Generation

To simplify the process of making use of the caCORE SDK XML Schema generation capabilities, as described in the section on Schema generation titled caCORE SDK in the Metadata Design, an Introduce extension is provided which can produce XML Schemas from an XMI model. The extension, SDKTypeSelectionComponent, is a type discovery extension as is the caDSR Grid Service Type Discovery component. Rather than using the caDSR however, this extension makes use of the caCORE SDK transparently without requiring the user to install or configure the caCORE SDK. The feature can be found on the "Types" tab of Introduce, under the "Create from XMI" subtab.

The component, provides the user with a browse button to select their XMI file, and various input boxes to enter supplemental information about the project represented by the XMI file. These fields are used to control the XML Schema generation process (indicating the information needed to select a namespace, and which packages from the Project to process). As the user fills out the form, a status box below is updated, as are status icons on each of the field. These are validators that ensure valid information is provided. If the user presses the "Add" button before all of the error indicators are cleared, a dialog showing the errors will be displayed, and no processing will occur. The warnings will not prevent processing from occurring, but generally indicate something that should probably be examined. Once the "Add" button is press with no validation errors, the component goes through the process of generating XML Schemas, and adding them to the service.

The components which implement the logic of the extension, use the following process when a type is to be added. First, as mentioned above, the input is validated. Next, if everything is valid, the component extracts a local copy of the caCORE SDK version 4.1.1, to a temporary directory. Then, the SDKExecutor is used to execute the process, by passing it an instance of SDKGenerationInformation, which is basically a Bean to represent the input gathered from the user. The executor creates an instance of SDKExecutionResult, which is a bean which represents access to the artifacts created by execution on the SDK. To do this, the executor applies the necessary configuration changes in the SDK configuration file, by reading the values of the SDKGenerationInformation bean. Then the SDK is executed as an Ant process. The results are then validated and returned. If everything is valid, the component then copies and installs the generated schemas to the service.