Notice: this Wiki will be going read only early in 2024 and edits will no longer be possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
Difference between revisions of "COSMOS Design 212185"
(→Meeting on 7-Jan-07) |
(→Meeting on 7-Jan-07) |
||
| Line 41: | Line 41: | ||
** Need to add set of policy assertions--use inside of capability | ** 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, | + | * 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 === | === Implementation Steps === | ||
Revision as of 13:35, 7 January 2008
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
- 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?
- 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.
- COSMOS MDR
- 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.