Talk:COSMOS Design 215123

Design discussion minutes (Feb 4)

Meeting attendees: Mark, Ali, Sheldon, Hubert

The data manager client now has an API for getting the WSDL from the data manager. MEX client is used to get the WSDL.
- Need pluggable ways to get wsdl. i.e. the client should be able to use different mechanisms to retrive WSDL from the data manager. This is important if the client needs to communicate non-COSMOS MDRs.
- Ways to get WSDL include:
  - ?wsdl (Axis2)
  - MEX
We need an API for getting the metadata information in POJO representation. The goal is to avoid the need to manipulation of XML and WSDL as much as possible.
The comment about using POJO applies to query and registration APIs as well. i.e. the parameters of the operation and the return value should use POJO where possible.
- TODO: Need to open bugs to address this issue. (bug 217704)
Where should MDR metadata be stored?
- MDR: metadata is configured and stored at the MDR. Client can always query an MDR for its metadata.
- Broker: Broker can cache values or properties about MDRs that can help categorize the broker. The values cached at the broker are used as search criteria when querying for data manager EPRs. Some "service level" metadata (such as query capabilities) are not useful at the broker.
  - Values defined in the CMDBf service metadata that may be useful at the broker include:
    - serviceDescription/mdrId
    - serviceDescription/description

Configuring service metadata
- Put metadata section in an XML file
- Point to the file from config.properties
- Future: allow a factory class to retrieve metadata values. Deployers can provide a custom metadata factory class. The purpose is to allow getting metadata dynamically.
Metadata at the broker
- Only name and description are cached at the broker. (Description is a string value.)
- Not storing other service metatdata attributes.
User interface
- Not displaying metadata of MDRs in i9
- Use metadata to create query build if metadata is defined.