COSMOS Design 212185

This is a stub for the design for bugzilla 212185. It was spun off from COSMOS Design 208584. Please expand this stub to follow the formatting of other COSMOS designs.

Service Metadata

Service metadata is a new concept introduced in CMDBf1.0 specification. It's an optional mechanism for an MDR to advertise the query and registration service capabilities. There will be a new module added to the CMDBf project to allow consumers to add this support. The new module will be called CMDBfMetadata.jar and will have a very similar structure to CMDBfQueryTransformation.jar and CMDBfRegistrationTransformation.jar.

The library will include a POJO representation with a mirror transformation operation. How an MDR exposes the service metadata is left to the COSMOS code base that morphs a data store to a data manager. The library will simply provide a POJO representation that can be converted/generated to/from an XML document.

Section 6 of the spec describes new constructs called queryServiceMetadata and registrationServiceMetadata to represent this metadata.

Open Issues/Questions

All reviewer feedback should go in the Talk page for 212185.

---

---

Meeting on 7-Jan-07

Attendees: Joel, Bill, Hubert, David, Ali, Valentina, Sheldon, Mark

• How does the spec intend the supported metadata element to be used?
• Handshake b/t broker and MDR.
• Do we want to cache the MDR metadata in the data broker?
• How do we use this in the visualization?
• What's considered a valid CMDBf WSDL, e.g. can there be other operations included in the WSDL that are not defined by CMDBf, e.g. getResourceProperties?

• How do we get the metadata?
  • COSMOS MDR
    •  ? WSDL
    • MEX
  • Non-COSMOS MDR
  •  ? WSDL
  •  ???
  • Because of the potential dynamic nature of the record type list we need to generate wsdl dynamically.

• How does this affect the annotation work?
  • The annotations generate their own wsdl dynamically (does not use muse)
  • Need to add set of policy assertions--use inside of capability

• The use of CMDBf metadata is considered both a design time thing and a runtime thing. For example, it is conceivable that the record type list, depth limit, et. can change dynamically at runtime.

Implementation Steps

• Add "getPolicyAssertions" internal interface to capabilities that want to provide policy metadata (joel)
• Provide implementation of getPolicyAssertions to the CMDBfQuery and CMDBfRegistration capabilities that...
  • The return type of the getPolicyAssertions is a collection of POJOs. This POJO must support the the IPolicyAssertion interface. The IPolicyAssertion should have the following:
    • toXML() [starts at line 3412 through 3451] look at IXMLWritable interface, found in the org.eclipse.cosmos.dc.cmdbf.services plug-in in the Data Collection subproject. See also implementors of that interface for useful helper methods and recursive implementation patterns.
    • policyAssertionId()
  • The metadata can be implemented as properties on the capability, e.g. depthLimit

Post meeting update including scoping

• i8 will include the transformations of the metadata between XML and POJOs, as specified in ER 212185 (Bill)

• i9 will include a general mechanism for the Data Managers to expose their policy metadata in their WSDL. This general mechanism will be used by the MDRs to expose CMDBf service metadata. Client appplications (and other components) can use the metadata transformations to process the service metadata.
  • i9 will add the IPolicyAssertion interface and support in the contribution manager to obtain the policy metadata for inclusion into the WSDL (Joel)
  • i9 will include the change to the MDRs to expose their CMDBf service metadata as policy metadata
  • i9 will include support for the CMDBf metadata in the Data Visualization to determine the appropriate DV Outputter for the visualization

Refer to COSMOS_Design_215123