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