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 204921: Service Group in Broker i8"
(→''' Overview ''') |
(→''' Use Cases ''') |
||
Line 54: | Line 54: | ||
== ''' Use Cases ''' == | == ''' Use Cases ''' == | ||
+ | === Use Case 1: Configure Broker service group === | ||
+ | * Configure some properties of the broker for a specific deployment of the broker. It's expected that the configuration is rather static and is done before the first data manager registers with the broker. | ||
+ | * Configurable properties include: | ||
+ | ** MembershipContentRule: resource properties required by member data managers | ||
+ | ** Persistence: | ||
+ | *** Turn persistence on/off | ||
+ | *** Provide alternative persistence mechanism (MUSE provides a file-based persistence) | ||
+ | * Some tooling can be provided to facilitate this step. With the help of tooling, the implementation aspect of WSDM and MUSE implementation can be shielded from the deployers, who wants to focus on the business meanings of these configuration values. Tooling is not out of scope in this enhancement. | ||
+ | === Use Case 2: Data Manager register with broker === | ||
+ | * Data manager registers with broker on start up, or by executing an operation defined by the data manager. | ||
+ | * Data manager invokes the add API defined by the service group registration capability, providing the data manager EPR as a parameter. | ||
+ | * The broker service group creates a client to the data manager using the ERP, and retrieves the values required by the service group using the GET capability defined in WS-RP standard. If the data manager does not support a required property, the registration will faile. Otherwise, the EPR along with the property values are persisted in a file. (The operations in this step is provided by the MUSE implementation.) | ||
+ | |||
+ | === Use Case 3: Query broker for Data Manager EPRs with constraints === | ||
== ''' Implementation Detail ''' == | == ''' Implementation Detail ''' == |
Revision as of 15:49, 10 December 2007
Contents
Adding support for the CMDBf query service on top of the SML repository
Change History
Name: | Date: | Revised Sections: |
---|---|---|
Hubert Leung | 12/10/2007 |
|
Terminologies/Acronyms
The terminologies/acronyms below are commonly used throughout this document. The list below defines each term regarding how it is used in this document:
Term | Definition |
---|---|
service group |
Overview
The Broker is the component in the COSMOS data collection framework that holds a registry of Data Managers and allows clients to query for addresses based on some constraints. In a system supporting COSMOS and CMDBf, Management Data Repositories (MDR) and federating CMDB are speialized instances of data managers, and will also be registered at the broker.
In i7, we have an implementation of a data broker that makes use of an XML file to store the EPRs and property values (such as classification, dialect and name) of data managers, and we support querying ERPs by classification value. We will improve the implementation in i8 by using web service standards as defined in WS-ResourceFramework (WSRF) and WS-DistributedManagement (WSDM) in the broker for the storage and retrival of properties of data managers.
Web Services Service Groups
The service group specification defines a method for grouping web services. This specification is very suitable for the implementation of the COSMOS broker as a registry of data managers, which are exposed as WSDM endpoints.
Specifically, here are a few quotes from the service group specification for defining the purpose and scope of service groups:
"This WS-ServiceGroup specification defines a means by which Web services and WS-Resources can be aggregated or grouped together for a domain specific purpose. In order for requestors to form meaningful queries against the contents of the ServiceGroup, membership in the group must be constrained in some fashion. The constraints for membership are expressed by intension using a classification mechanism. Further, the members of each intension must share a common set of information over which queries can be expressed."
"[...] specialized interfaces may offer means of querying the contents of the ServiceGroup, and for performing collective operations across members of the ServiceGroup."
Here are some benefits of using service groups:
- Standard APIs
- Persistence
- Apache MUSE provides an implementation of service groups, which includes a file-based serialization implementation of group entries.
- It is possible to use an alternative persistence mechanism (e.g. database), simply by modifying the muse.xml to point to another persistence implementation class, which can be provided by the adopters.
- Configurable: The service group can be configured to require a set of mandatory properties by member services (data managers). These properties can be used as query contraints when querying for EPRs.
Requirements
Use Cases
Use Case 1: Configure Broker service group
- Configure some properties of the broker for a specific deployment of the broker. It's expected that the configuration is rather static and is done before the first data manager registers with the broker.
- Configurable properties include:
- MembershipContentRule: resource properties required by member data managers
- Persistence:
- Turn persistence on/off
- Provide alternative persistence mechanism (MUSE provides a file-based persistence)
- Some tooling can be provided to facilitate this step. With the help of tooling, the implementation aspect of WSDM and MUSE implementation can be shielded from the deployers, who wants to focus on the business meanings of these configuration values. Tooling is not out of scope in this enhancement.
Use Case 2: Data Manager register with broker
- Data manager registers with broker on start up, or by executing an operation defined by the data manager.
- Data manager invokes the add API defined by the service group registration capability, providing the data manager EPR as a parameter.
- The broker service group creates a client to the data manager using the ERP, and retrieves the values required by the service group using the GET capability defined in WS-RP standard. If the data manager does not support a required property, the registration will faile. Otherwise, the EPR along with the property values are persisted in a file. (The operations in this step is provided by the MUSE implementation.)