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 220952

Revision as of 22:27, 31 March 2008 by Hkyleung.ca.ibm.com (Talk | contribs) (Broker)

Broker to manage MDRs that do not support WSA and WSRF

Change History

Name: Date: Revised Sections:
Hubert Leung 03/04/2008
  • Initial version

Workload Estimation

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

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

Purpose

This enhancement depends on enhancement 220949 - the support of stateless web services. The management domain and broker are services groups. They expect services to implement the WS-Addressing and WS-ResourceProperties standards. With the support of stateless web services, the broker will need to store addresses and properties of data managers that do not support WS-Addressing and WS-ResourceProperties standards.

Design

Broker

Note: This section describe more features than what would be implemented in i10. See the proposal at the end of the section for what will be implemented in i10.

  • Remove the notion of management domain in i10, but we will have equivalent (or more) flexibility of providing a hierachical registry structure.
  • A broker is a general purpose web service registry. It is not just designed for "data managers".
  • The COSMOS broker is a conceptually centralized registry for locating services.
  • The COSMOS broker can be a physically distributed network of brokers.
  • Each broker is a registry that consists of:
    • a list of web services: each web serivce entry has an EPR, a namespace, a display name and a description (optional)
    • a list of service groups: a "service group" is a logical collection of (related) web services
    • a list of data managers: a "data manager" is a speicalized service group that includes the data manager service
    • a list of brokers: This allows a hierarchy of brokers. i.e. any broker can be a broker of brokers. It is up to the deploy to decide how to organize the broker hierarchy.
  • Non-COSMOS MDR can be registered at the COSMOS broker. As long as the MDR provides a query and/or registration service that comply to the CMDBf standard, the UI can discover it and interact with it.
  • The entry point of COSMOS is an EPR to a broker, from which the client can discover services, and other brokers.
  • We can have a "broker explorer" user interface that navigate the content of the COSMOS broker network. In i10, it is done using commmand line.
Broker1 <- entry point of system
+- services
|  +- service1
|  +- service2
+- service groups
|  +- group1 (data manager) 
|  |  +- service1
|  |  +- service2
|  +- group1 (data manager)
|     +- service1
|     +- service2
+- broker2 <- reference another broker
  • data structure at a broker: (COSMOS service registry schema)
<broker>
  <serviceGroups>
    <serviceGroup>
      <id></id>
      <name></name>
      <description></description>?
      <services>
        <service>
          <namespace></namespace>
          <endpoint></endpoint>
          <name></name>?
          <description></description>?
        </service>+
      </services>
    </serviceGroup>*
  </serviceGroups>?
  <services>
    <service>
      <namespace></namespace>
      <endpoint></endpoint>
      <name></name>?
      <description></description>?
    </service>*
  </services>?
</broker>
  • "Uniqueness" of services:
    • The namespace values are the identifiers of web services. However, it is not a unique identifier.
    • Usecase: The query service can be part of multiple service groups. Their namespace is the same, but EPRs are different. When searching for services by namespace, all EPRs tagged with that namespace will be returned.
    • EPR values are unique. That is, there is no two services in a broker with the same EPR.
  • Web service operations of the broker:
    • registerService: request message payload is the service element
    • registerServiceGroup: request message payload is the service group element
    • deregisterService: Deregisters services that are not part of a service group. This operation will remove services from a service group. Payload is EPR.
    • deregisterServiceGroup: Deregister service group by group ID.
    • getServices: get service by service namespace
    • getAllServices: get all services registered at the broker
    • getServiceGroup: get serviceGroup by group ID
    • getDataManager: same as getServiceGroup, but only return groups that include the data manager service
    • getAllServiceGroups: get all service groups registered at the broker
    • getAllDataManagers: get all service groups registered at the broker
  • Registration response data structure: TBD
  • Deregistration response data structure: TBD
  • Proposal: In version 1.0 (i10), we will only support the operations in bold, and the part of the data schema required for these operations. This is the scenario of having a single broker. The broker design can be extended to support the multi-broker configuration in the future. Since the UI in version 1.0 assumes there is only one broker and there is no urgent requirement for having multiple brokers, version 1.0 will only support the mimimum for completing the end-to-end scenario.
  • Other future extensions:
    • The schema is to be extended to support translation of translatable values like names and descriptions.
    • support WSA

Service discovery service

  • axis2 specific implementation
  • It helps finding service EPRs of axis2 web services deployed at a server.
  • It helps finding data managers deployed at a server.
  • COSMOS provide a web service that discovers all COSMOS data managers deployed on the same web server.
  • operations:
    • getServiceGroups
      • response payload: serviceGroup element
    • getServices
      • response payload: services element
    • getDataManagers
      • response payload: serviceGroup element
  • operation responses use the COSMOS service registry schema.

Data Manager Service

  • *may* support auto-register function
    • will support this feature only if I find a solution to get service EPRs upon deployment of axis2 web services. (looking for help...)
    • It is not a show-stopper.
  • configures properties of the data manager in services.xml
  • operation:
    • getServices: return all details of the data manager. Payload is the service group element

Demo config program

  • Use service discovery service to find all data managers, and register them with the broker.
  • This feature is very useful if we don't have auto-register feature.

Open Issues/Questions

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

Back to the top