CaGrid:Metadata:IntroduceSupport

From caGridWiki

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 Grid Service Type Discovery

The caDSR Grid Service, provides read and query access to the information available in the caDSR, as well as provides the ability to generate standard service metadata. 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 browser 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 Grid Service API to populate the Project and Package combo boxes, and makes use of the caGrid graph project, which provides a means to render UML views.

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. Currently the component makes use of the namespace naming conventions described in the section titled: XML Schema Namespace Conventions. If a schema matching the namespace derived by using the conventions for the selected project does not exist, the user is prompted to make an alternate selection when presented with namespaces that actually are available in the GME.

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

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 caDSR Grid Service and Data Service design documents.

In caGrid 1.0, Introduce did not support editing documentation for most of the aspects of the caGrid Service Metadata model which require documentation (operations, metadata, etc). Users in caGrid 1.0, were left to manually update the generated metadata instance to populate these fields. In caGrid 1.1, Introduce added the ability to edit all of these descriptions directly in Introduce, so the Service Metadata Generator components where updated to make use of this information. However, for users which already edited the Service Metadata manually in caGrid 1.0, this information would be lost when these new Introduce fields were added to their service. To address this problem, an Introduce upgrade process was created for the Service Metadata Generator which runs during the upgrade process of a service from 1.0 to 1.1. Introduce provides an extension point for extensions to install into the upgrade process. The MetadataUpgrade1pt0to1pt1 component implements this functionality. Essentially the MetadataUpgrade1pt0to1pt1 component first copies any descriptions from the Service Metadata instance to their corresponding entries in the Introduce model, then relies on the Service Metadata Generator components to repopulate the metadata from the Introduce model as normal.

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. In order to populate the research center information, the ability to load it from the caDSR is provided. To make use of this feature, the user supplies a short name for the center and presses the “Load from caDSR” button. The component then searches the caDSR model for Organizations, using the ApplicationService. If a center is found with a name matching the provided name, all of the relevant fields are updated.

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.

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, 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 Grid Service, however, this extension makes use of the caCORE SDK transparently without requiring the user to install or configure the caCORE SDK.

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 valuators 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.0, 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.