COSMOS Design 220952

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

• 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 has an EPR, a namespace, a display name, 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 include the data manager service with service
  • a list of brokers: This allows a hierarchy of brokers. i.e. any broker can be a broker of brokers.
• 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>
  <serviceGroup>
    <id></id>
    <name></name>
    <description></description>?
    <services>
      <service>
        <namespace></namespace>
        <endpoint></endpoint>
        <name></name>?
        <description></description>?
      </service>+
    </services>
  </serviceGroup>*
  <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.
  • getService: get service by service namespace
  • getServiceGroup: get serviceGroup by group ID
  • getDataManager: same as getServiceGroup, but all returned groups include the data manager service
• Registration response data structure: TBD
• Deregistration response data structure: TBD
• 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.
  • the service will list out all service groups and their contents that include a service with the namespace http://www.eclipse.org/cosmos/datamanager
• 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.

Open Issues/Questions

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