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 215123"

(Removing all content from page)
Line 1: Line 1:
 +
== ''' Complete CMDBf 1.0 Service Metadata implementation ''' ==
  
 +
This is the design for [https://bugs.eclipse.org/bugs/show_bug.cgi?id=215123 Bugzilla 215123].
 +
 +
=== '''Change History''' ===
 +
{|{{BMTableStyle}}
 +
!align="left"|Name:
 +
!align="left"|Date:
 +
!align="left"|Revised Sections:
 +
|-
 +
|Bill Muldoon
 +
|1/28/2008
 +
|<ul><li>Initial version</li></ul>
 +
|-
 +
|}
 +
 +
= ''' Workload Estimation''' =
 +
 +
{|{{BMTableStyle}}
 +
|+{{BMTableCaptionStyle}}|Rough workload estimate in person weeks
 +
|-{{BMTHStyle}}
 +
! Process
 +
! Sizing
 +
! Names of people doing the work
 +
|-
 +
| align="left" | Design
 +
| 0.2 week
 +
| Bill Muldoon
 +
|-
 +
| align="left" | Code
 +
| 1 week
 +
| Joel/Bill
 +
|-
 +
| align="left" | Test
 +
| 0
 +
| Bill/QA team
 +
|-
 +
| align="left" | Documentation
 +
| 0
 +
| N/A
 +
|-
 +
| align="left" | Build and infrastructure
 +
| 0
 +
| N/A
 +
|-
 +
| align="left" | Code review, etc.'''*'''
 +
| 0
 +
| N/A
 +
|-
 +
! align="right" | TOTAL
 +
| 1.2 weeks
 +
|
 +
|}
 +
 +
'''*''' -  includes other committer work (e.g. check-in, contribution tracking)
 +
 +
= ''' 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:
 +
 +
 +
{|{{BMTableStyle}}
 +
|-{{BMTHStyle}}
 +
! Term
 +
! Definition
 +
|-
 +
|MDR
 +
|management data repository
 +
|-
 +
|CMDBf
 +
|specification for a CMDB that federates between multiple MDRs [http://cmdbf.org/schema/1-0-0/CMDBf%20v1.0.pdf]
 +
|-
 +
|federating CMDB
 +
|the CMDB that federates between MDRs, offering a common access point to clients and correlating identifying record data
 +
|-
 +
|CMDB
 +
|configuration management database
 +
|}
 +
 +
='''Purpose'''=
 +
 +
CMDBf 1.0 introduced metadata to describe MDR query and registration metadata. This metadata is exposed as WS-Policy elements in WSDL. The purpose of this enhancement is to enable COSMOS MDRs to expose their metadata in WSDL.
 +
 +
 +
='''External Implementation'''=
 +
 +
== How does a COSMOS MDR expose its metadata? ==
 +
 +
A COSMOS MDR exposes its metadata by implementing the IPolicyAssertion interface:
 +
 +
public interface IPolicyAssertion {
 +
    String getPolicyId();
 +
    Element toXml();
 +
    String toXmlString();
 +
}
 +
 +
The getPolicyId() operation returns the policy identification. The toXml() and toXmlString() operations return the actual metadata.
 +
 +
For example, the Example MDR will support the '''IPolicyAssertion''' interface:
 +
 +
public class ExampleMdr extends AbstractMdr implements IDataManager, IMdrQuery, IPolicyAssertion
 +
 +
 +
== How does the client application obtain the MDR metadata? ==
 +
 +
First the client application must obtain the WSDL. The mechanism to obtain the WSDL is dependent on the container.
 +
* In Axis2, the "?WSDL" operation can be used.
 +
* In MUWS, Metadata Exchange (MEX) can be used.
 +
 +
 +
Then the client application can extract the metadata from the WSDL. As a convenience, it may use the COSMOS CMDBf metadata transformations to convert the metadata into POJOs.
 +
 +
 +
='''Internal Implementation'''=
 +
 +
 +
When the WSDL is requested from a COSMOS Data Manager, the COSMOS Contribution Manager searches for the IPolicyAssertion interface in the annotations of the Data Manager. If found, it invokes its operations to retrieve the policy data and then includes it when generating the WSDL.
 +
 +
 +
= ''' Test Coverage ''' =
 +
A JUnit test will obtain the metadata from the Example MDR using MEX.
 +
 +
Also the COSMOS UI will be able to display the metadata from an MDR. Refer to related [https://bugs.eclipse.org/bugs/show_bug.cgi?id=215521 Bugzilla 215521]
 +
 +
 +
= '''  Open Issues ''' =
 +
 +
How does the client obtain the WSDL in the JAX-WS environment?
 +
 +
All reviewer feedback should go in the [[Talk:COSMOS_Design_215123|Talk page for 215123]].
 +
 +
----
 +
[[Category:COSMOS_Bugzilla_Designs]]

Revision as of 18:25, 28 January 2008

Complete CMDBf 1.0 Service Metadata implementation

This is the design for Bugzilla 215123.

Change History

Name: Date: Revised Sections:
Bill Muldoon 1/28/2008
  • Initial version

Workload Estimation

Rough workload estimate in person weeks
Process Sizing Names of people doing the work
Design 0.2 week Bill Muldoon
Code 1 week Joel/Bill
Test 0 Bill/QA team
Documentation 0 N/A
Build and infrastructure 0 N/A
Code review, etc.* 0 N/A
TOTAL 1.2 weeks

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

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
MDR management data repository
CMDBf specification for a CMDB that federates between multiple MDRs [1]
federating CMDB the CMDB that federates between MDRs, offering a common access point to clients and correlating identifying record data
CMDB configuration management database

Purpose

CMDBf 1.0 introduced metadata to describe MDR query and registration metadata. This metadata is exposed as WS-Policy elements in WSDL. The purpose of this enhancement is to enable COSMOS MDRs to expose their metadata in WSDL.


External Implementation

How does a COSMOS MDR expose its metadata?

A COSMOS MDR exposes its metadata by implementing the IPolicyAssertion interface:

public interface IPolicyAssertion {
    String getPolicyId();
    Element toXml();
    String toXmlString();
}

The getPolicyId() operation returns the policy identification. The toXml() and toXmlString() operations return the actual metadata.

For example, the Example MDR will support the IPolicyAssertion interface:

public class ExampleMdr extends AbstractMdr implements IDataManager, IMdrQuery, IPolicyAssertion


How does the client application obtain the MDR metadata?

First the client application must obtain the WSDL. The mechanism to obtain the WSDL is dependent on the container.

  • In Axis2, the "?WSDL" operation can be used.
  • In MUWS, Metadata Exchange (MEX) can be used.


Then the client application can extract the metadata from the WSDL. As a convenience, it may use the COSMOS CMDBf metadata transformations to convert the metadata into POJOs.


Internal Implementation

When the WSDL is requested from a COSMOS Data Manager, the COSMOS Contribution Manager searches for the IPolicyAssertion interface in the annotations of the Data Manager. If found, it invokes its operations to retrieve the policy data and then includes it when generating the WSDL.


Test Coverage

A JUnit test will obtain the metadata from the Example MDR using MEX.

Also the COSMOS UI will be able to display the metadata from an MDR. Refer to related Bugzilla 215521


Open Issues

How does the client obtain the WSDL in the JAX-WS environment?

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


Back to the top