Notice: This Wiki is now read only and edits are no longer possible. Please see: https://gitlab.eclipse.org/eclipsefdn/helpdesk/-/wikis/Wiki-shutdown-plan for the plan.
COSMOS Design 204921: Service Group in Broker i8
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. By 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.