This line was removed.
This word was removed. This word was added.
This line was added.
Changes (1)View Page History
The ServiceMetadataAnnotator is similar to the DomainModelBuilder in that it creates caGrid metadata instances. However, the ServiceMetadataAnnotator produces the standard ServiceMetadata common to all caGrid services, and it requires the client to supply a partially populated model as input. The caGrid common service metadata specifies information about a grid service and its operations. For more information on the model, consult the the [caGrid metadata overview|metadata14:Metadata Models]. The ServiceMetadataAnnotator takes this model and populates the UML and semantically oriented components by querying the caDSR appropriately. Specifically, it populates the semantically annotated UML Class information (similar to the type used in Data Service Domain Model metadata) for each input and output type of every operation the service provides. It does this by examining the XML Qualified Name (QName) of each type used in the signature of the operation and locating its UML equivalent in caDSR using the new caDSR 4.0 [GME Namespace feature|Use this: https://wiki.nci.nih.gov/display/caDSR/caDSR+Release+4.0+Highlights]. feature|https://wiki.nci.nih.gov/display/caDSR/caDSR+Release+4.0+Highlights]. In this approach, UML items (Projects, Classes, Attributes, etc) in the caDSR are annotated with their representative XML Schema namespace. The ServiceMetadataAnnotator use the QName to construct an appropriate "prototype" object (e.g. UMLClassMetadata), populating the _gmeNamespace_ and _gmeName_ attributes, and passes it to the _ApplicationService.search_ operation.
In addition to the ServiceMetadata instance, the anotator also takes a Map of XML Namespace to _QualifiedProject_ (which specifies and ApplicationService and UML Project to use) that the _CaDSRMMSImpl_ creates based on the NamespaceToProjectMappping passed to the annotateServiceMetadata operation. The NamespaceToProjectMappping provides a way for clients to give a hint to the MMS as to which Project (and Metadata Source) should be used for a particular Namespace. The caGrid Metadata Introduce Extension is an example where this capability is leveraged. The caDSR Data Type Discovery component of Introduce allows one to add models (XML Schemas) to their project, by browsing the caDSR and selecting a Project/Package. When such a model is added, it notes its caDSR information (e.g. Project name and version). Later when the caGrid Metadata Introduce Extension uses the MMS to annotate the service's metadata, it reads this information and creates a series of NamespaceToProjectMappping which map each XML Schema's Namespace to the appropriate caDSR Project. The MMS then uses this information to ensure the correct metadata is associated with the operations which make use of types from those XML Schemas. As such, the NamespaceToProjectMappping array provides clients the ability to control the MMS behavior when there are multiple external metadata repositories supported and/or a given XML Schema Namespace ambiguously maps to multiple UML Models (i.e. multiple projects are reusing the same XML Schema).