Skip to main content

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.

Jump to: navigation, search

COSMOS Design 231343

Revision as of 16:15, 23 June 2008 by Hkyleung.ca.ibm.com (Talk | contribs) (New web service operations for the broker)

Improve query capability of the COSMOS broker

Change History

Name: Date: Revised Sections:
Hubert Leung June 23, 2008
  • Initial version

Workload Estimation

Rough workload estimate in person weeks
Process Sizing Names of people doing the work
Design 0 Hubert Leung
Code 0 Hubert Leung
Test 0 Hubert Leung
Documentation 0 Hubert Leung
Build and infrastructure 0 Saurabh Dravid
Code review, etc.*
TOTAL 0

'* - includes other committer work (e.g. check-in, contribution tracking)

Purpose

Allow the COSMOS broker to accept more specific search criteria when searching for a list of data managers. The goal is to return a more relevant list of data managers.

Requirements

In the current implementation (as of i11), the broker supports three query operations:

  1. Get all data managers: return the list of all data managers registered at the broker
  2. Get data managers by hostname and name
  3. Get data managers that support a given web service: Provide the namespace of a web service definition as a parameter. Return the list of all data managers that support a web service with that namespace. E.g. "Find all data managers that support the CMDBf query service" will return the list of all MDRs.

Limitations:

  1. Searching for data managers by service namespace is sometimes insufficient. For example, when searching for MDRs, we want to filter by the record types managed by the MDRs. "Find all MDRs that manages asset data." Simply asking for data managers that support the CMDBf query service is not specific enough, and the query result may include EPRs of data managers that manage irrelevant data.
  2. Cannot support for data managers by new configuration values introduced by enhancement 233690.

New query capabilities to be supported:

  1. query EPRs by ID
    • use case: a client queries the federating CMDB for a list of configuration items. Each item will have an InstanceID element which include the mdrId and the localId. Given the mdrId, the client can find the EPR the actual MDR where the item resides from the broker. The client can then issue CMDBf queries to the MDR.
  2. query by property values of the data manager: return data managers that has the required properties name-value pairs
  3. query by data-namespace of a CMDBf query service: return data managers that support the CMDBf query service, which indicates the given namespace in the service metadata for the recordTypes.
    • Address limitation 1 explained above.
    • use case: The current implementation allows the broker client to query for data managers by the namespace of the web services supported by the data managers. In CMDBf scenario, all MDRs support the CMDBf query service. However, we need more information to differentiate between the MDRs as they provide different information. We want to avoid asking the broker client to get a long list of MDRs and loop through them to decide which one in fact contains the type of data the client application is looking for. The service metadata of the CMDBf query service can indicate the namespace of record types. This new function is to allow broker client query for MDRs by the data-type namespace. The namespace is the unique identifier of the schema that defines the data structure.
  4. Remove the get data managers by hostname and group name function: enhancement 233690 has proposed to consolidate the indentifiers of all data managers to use globally unique URIs.

Design

Cache more static values of the data managers at the broker, and allow the use of these values as query criteria when querying for EPRs of data managers.

Design considerations

  1. Broker clients can only query for EPRs of data managers by values cached at the broker. The broker won't dispatch queries to multiple queries to do the filter matching at real time.
  2. Use namespaces to identify data model and schema instead of keywords.

Registering data managers with broker

  • During registration, the following values will be included for each data manager
    1. ID
    2. Display name
    3. Description
    4. Data namespace (for CMDBf query service only)

New web service operations for the broker

  1. getDataManager

Schema for the SOAP body:

<getDataManager>
  <id></id> |
  (<property name="" value =""> *
  <services>
    <serviceNamespace></serviceNamespace> + 
    <recordTypesNamespace></recordTypesNamespace> *
  </services>)
</getDataManager>

Impacts of this enhancement

Open Issues/Questions

Back to the top