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

Difference between revisions of "COSMOS Design 220949"

(Impacts)
(Impacts)
Line 84: Line 84:
 
# Broker: Affects the way broker and management domain store addresses and properties of data managers.
 
# Broker: Affects the way broker and management domain store addresses and properties of data managers.
 
# Tooling
 
# Tooling
 +
# Existing exmaple data managers: Port to use the new framework.
  
 
=Open Issues/Questions=
 
=Open Issues/Questions=

Revision as of 10:24, 26 March 2008

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.4 Hubert Leung
Code 1.4 Hubert Leung
Test 0.6 Hubert Leung
Documentation 0.2 Hubert Leung
Build and infrastructure 0.4 Saurabh Dravid
Code review, etc.*
TOTAL 3

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

Purpose

The current implementation of the data manager framework makes use of the COSMOS annotations and MUSE. The SOAP message does not follow the document/literal style because there are wrapping elements around the message payload. We are also using WS-Addressing in the message header. In order to ensure interoperability of the MDRs with non-COSMOS MDRs and to comply with the CMDBf standard more strictly, we want to support stateless web services in COSMOS. SOAP messages will not require WS-Addressing and use document/literal payload style.

Design

Technology Stack

  1. Java 5
  2. Axis2 without JAX-WS
  3. data binding: use existing binding in org.eclipse.cosmos.dc.cmdbf.services

Programming model

Framework

  • Generate skeleton and stub from WSDL, with no data binding. The interface will accept an OMElement and return an OMElement. The parameter is the payload of the SOAP message, and the return value is the payload of the response message. OMElement is the object that represent an XML element in the Axiom object model, which can be thought of as an equivalent model as DOM, but it uses streaming XML technology.
  • COSMOS Framework: The concept of AbstractMdr and AbstractFederatingCMDB will remain. They will be subclasses of their corresponding skeletons. However, AbstractFederatingCMDB will not be subclass of AbstractMDR.
  • The CMDBf services will have separate EPRs. Unlike the muse annotation approach, the WSDL is not generated on the fly, and the WSDL of different services is not merged into one WSDL. For example:
http://myhost:8080/axis2/services/QueryService
http://myhost:8080/axis2/services/RegistrationService
  • The code for the EPRs for each data manager need to be deployed in the same .aar file and share the same services.xml.
  • Custom APIs: COSMOS data managers allows developers to create custom APIs. (such as the logging and stat data manager examples.) Under the axis2 approach, they will be web services deployed in axis2. There is no restriction on how they are created.
  • Since there will be more than one EPR for each data manager, we need a way to define the set of endpoints that constitute a data manager. Axis2 has a feature called service group which is a grouping of services. (Don't confuse this with WS Service Group standard.) Services in the same service group can share the same service group context. Services from more than one data managers can be deployed in the same Axis2 container, but services for each data manager will be in the same group. It is done by a configuration/deployment file called services.xml.
  • Address registry: The groups of EPRs will be registered at the broker. Each EPR is identified by their target namespace (e.g. http://cmdbf.org/schema/1-0-0/query). So from each data manager, the client can get the EPR of the CMDBf query EPR if available. (I will need to confirm whether this is possible during implementation.)


Policy

Metadata is defined as WS-Policy. Axis2 claim some support of WS-Policy using WS-Commons/Neethi framework. More research is required to determine if we can leverage their support. The current code defines the metadata policy in a file. We can provide a web service operation in data manager web service to return the policy. But there may be more elegant ways to handle this.

Tooling

WTP provides eclipse tooling for axis2. A "Data manager project" is a dynamic web project.

Impacts

  1. UI: Since the SOAP message payload format will change, UI will need to adapt to the change when parsing SOAP body for data.
  2. Broker: Affects the way broker and management domain store addresses and properties of data managers.
  3. Tooling
  4. Existing exmaple data managers: Port to use the new framework.

Open Issues/Questions

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

Back to the top