https://wiki.eclipse.org/api.php?action=feedcontributions&user=Joel.hawkins.compuware.com&feedformat=atomEclipsepedia - User contributions [en]2024-03-29T05:08:52ZUser contributionsMediaWiki 1.26.4https://wiki.eclipse.org/index.php?title=COSMOS_Design_216809&diff=87102COSMOS Design 2168092008-03-12T19:13:26Z<p>Joel.hawkins.compuware.com: </p>
<hr />
<div>== '''Line up JAX-WS annotations and management annotations in ME''' ==<br />
<br />
This is the design document for [https://bugs.eclipse.org/bugs/show_bug.cgi?id=216809 bugzilla 216809].<br />
<br />
=== '''Change History''' ===<br />
{|{{BMTableStyle}}<br />
!align="left"|Name:<br />
!align="left"|Date: <br />
!align="left"|Revised Sections:<br />
|-<br />
|Joel Hawkins<br />
|3/12/2008 <br />
|<ul><li>Initial version</li></ul><br />
|-<br />
== ''' Workload Estimation''' ==<br />
<br />
{|{{BMTableStyle}}<br />
|+{{BMTableCaptionStyle}}|Rough workload estimate in person weeks<br />
|-{{BMTHStyle}}<br />
! Process<br />
! Sizing <br />
! Names of people doing the work<br />
|-<br />
| align="left" | Design<br />
| 1<br />
| Joel <br />
|-<br />
| align="left" | Code<br />
| 2<br />
| Joel<br />
|-<br />
| align="left" | Test <br />
| 1<br />
| Joel/Hubert/QA<br />
|-<br />
| align="left" | Documentation <br />
| 2<br />
| Joel/Rich<br />
|-<br />
| align="left" | Build and infrastructure<br />
| 0<br />
|<br />
|-<br />
| align="left" | Code review, etc.*<br />
| 0<br />
|<br />
|-<br />
! align="right" | TOTAL<br />
| 6.0<br />
|<br />
|}<br />
<br />
== '''Terminologies/Acronyms''' ==<br />
<br />
The terminologies/acronyms below can be used throughout this document. <br />
<br />
'''Note:''' These definitions are not meant to be general definitions of these terms, but rather refer to how the terms are used within this design document as applied to COSMOS.<br />
<br />
{|{{BMTableStyle}}<br />
|-{{BMTHStyle}}<br />
! Term <br />
! Definition<br />
|-<br />
|JAX-WS<br />
|The Java WebServices API specified by JSRs 224 and 181<br />
|-<br />
|}<br />
<br />
== '''Purpose''' ==<br />
Axis2 provides an implementation of JAX-WS, which provides a library of<br />
annotations for web services. COSMOS code has been using annotations that Joel<br />
contributed to the project. The "COSMOS annotations" are oriented towards<br />
management interfaces. Despite the difference, there may be annotations that<br />
have similar purposes, and can be reconciled. This enhancement is for "lining<br />
up" the two set of annotations, and use the JAX-WS standard where possible.<br />
<br />
== '''Use Cases''' ==<br />
<br />
The following have been identified as use cases related to this enhancement.<br />
<br />
<ol><br />
<li>Developer binds a statefull (instance) provider<br><br />
<br />
There are two variations on this use case:<br />
<ol><br />
<li>Data manager is being created from scratch.<br><br />
This is addressed in [[#Creating a new Data Manager project|Creating a new Data Manager project]].</li><br />
<li>Data manager is being adapted to existing data source.<br><br />
This is the case where the user imports an MDR into Eclipse. Users will create a normal Eclipse project, and then based on the config.properties and domainEPR.xml files, new manifest editor pages will be displayed for editing these. See [[#Updating Data Manager Project|Updating Data Manager Project]].</li><br />
</ol><br />
</li><br />
<li>Developer binds a stateless (singleton) provider.<br><br />
This is addressed in [[#Deployment|Deployment]].<br />
</ol><br />
<br />
== '''Development environment''' ==<br />
<br />
<br />
== '''Extensibility''' ==<br />
<br />
<br />
== '''Detailed Design''' ==<br />
<br />
The code for this enhancement will be part of the Management Enablement project. The code will span multiple plug-ins. Both J2EE and OSGi deployments will be supported.<br />
<br />
* <code>org.eclipse.cosmos.me.management.common</code> - base annotation definitions and utility classes<br />
* <code>org.eclipse.cosmos.me.management.webservices</code> - contains the JAX-WS specific code. This plug-in will have a dependency on an external provider of the JAX-WS annotation classes.<br />
<br />
The programming model for COSMOS centers around the concepts of state and composition. COSMOS managed objects are currently exposed as instances, <br />
and these instances expose operations and properties as parts of distinct capabilities. <br />
<br />
JAX-WS, on the other hand, centers around the concept of stateless interfaces. A large part of the reconcilliation effort resides in mapping JAX-WS's descriptive<br />
characteristics onto the COSMOS statefull composition model. <br />
<br />
<br />
Resource/Type-Level annotations<br />
<pre><br />
ManagedResource<br />
ManagedResource --- ManagedResource (Substitute WebService, WebServiceProvider)<br />
ManagedAdvertisement (Optional), <br />
ManagedState (Optional), <br />
ManagedReferece (Optional)<br />
<br />
ManagedResourceCapability --- ManagedResourceCapability (Substitute WebService, WebServiceProvider)<br />
<br />
ComposableManagedCapabilitySet --- Untouched. No substitute<br />
<br />
Honored JAX-WS annotations<br />
SOAPBinding - verify that this must match Muse expectations - fail the bind and log otherwise<br />
BindingType - verify that this must match Muse expectations - fail the bind and log otherwise<br />
RequestWrapper - may be useful for some operations...TBD <br />
ResponseWrapper - may be useful for some operations...TBD <br />
ServiceMode - verify that this must match Muse expectations - fail the bind and log otherwise<br />
WebFault - may be useful for some operations...TBD<br />
</pre><br />
<br />
Method-Level annotations<br />
<pre><br />
ManagedResourceFactory --- Deprecate. Use JAX-WS singleton semantics instead<br />
CreateManagedRelation --- Untouched. No substitute<br />
DestroyManagedRelation --- Untouched. No substitute.<br />
ManagedPropertyGetter --- Untouched. No substitute. <br />
ManagedPropertySetter --- Untouched. No substitute.<br />
ManagedEvent --- Untouched. No substitute.<br />
ManagedEventConsumer --- Untouched. No substitute.<br />
<br />
ManagedOperation<br />
ManagedOperation --- ManagedOperation(Substitute WebMethod)<br />
<br />
<br />
Honored JAX-WS annotations<br />
Oneway - invalid for COSMOS - fail the bind and log<br />
WebResult <br />
SOAPBinding - verify that this must match Muse expectations - fail the bind and log otherwise<br />
WebEndpoint - TBD<br />
<br />
</pre><br />
Parameter-Level annotations <br />
<pre><br />
ManagedParameter --- (Substitute WebParam) TBD - using JAXB or Muse serialization. <br />
ManagedEventSource --- Untouched. No substitute.<br />
ManagedEventSituation --- Untouched. No substitute<br />
</pre><br />
<br />
=== '''Resource Level Annotation Mapping'''===<br />
<br />
The base annotation for COSMOS components is the ManagedResource interface. This interfaces is currently used as a tagging interface to identify a<br />
component implementation's suitability for management under COSMOS.<br />
<br />
''Managed Resource''<br />
<br />
<pre><br />
/**<br />
* Annotation used to indicate a class to be exposed as a manageable resource. <br />
*/<br />
@Target(TYPE)<br />
@Retention(RUNTIME)<br />
public @interface ManagedResource {<br />
/**<br />
* A text description of the resource. This value will be used as the<br />
* default description when the resource is introspected.<br />
*/<br />
String description() default "";<br />
/**<br />
* The namespace of the resource. This namespace will be used for all<br />
* operations and properties exposed by this resource (unless overridden) <br />
* that are not part of some other capability <br />
*/<br />
String namespace() default "";<br />
/**<br />
* The desired persistence model for the resource. <br />
*/<br />
String persistent() default "never";<br />
<br />
/**<br />
* If true, indicates that the resource should support advertisement, and<br />
* that the initial advertisementConsumer should be honored. <br />
*/<br />
boolean advertise() default false;<br />
/**<br />
* A text string used by the management host to identify the<br />
* endpoint of an initial advertisement. This attribute is only used<br />
* if advertise is true. <br />
*/<br />
String advertisementConsumer() default "";<br />
<br />
/**<br />
* A name used to supply a target for AutoWire-annotated<br />
* fields in other managed components.<br />
*/<br />
String autowireName() default "";<br />
<br />
}<br />
</pre><br />
<br />
The JAX-WS analogs to ManagedResource are WebService and WebServiceProvider<br />
<br />
<pre><br />
@Retention(value=RetentionPolicy.RUNTIME)<br />
@Target({TYPE})public <br />
@interface WebService {<br />
String name() default "";<br />
String targetNamespace() default "";<br />
String serviceName() default "";<br />
String wsdlLocation() default "";<br />
String endpointInterface() default "";<br />
String portName() default "";<br />
}<br />
</pre><br />
<br />
<pre><br />
/**<br />
* Used to annotate a Provider implementation class.<br />
*<br />
* @since JAX-WS 2.0<br />
* @see javax.xml.ws.Provider<br />
*/<br />
@Target(ElementType.TYPE)<br />
@Retention(RetentionPolicy.RUNTIME)<br />
public @interface WebServiceProvider {<br />
/**<br />
* Location of the WSDL description for the service.<br />
*/<br />
String wsdlLocation() default "";<br />
/**<br />
* Service name.<br />
*/<br />
String serviceName() default "";<br />
/**<br />
* Target namespace for the service<br />
*/<br />
String targetNamespace() default "";<br />
/**<br />
* Port name.<br />
*/ <br />
String portName() default "";<br />
}<br />
</pre><br />
<br />
ManagedResource as it is currently constituted enapsulates a number of concerns: <br />
* Tagging (identifying a resource as one that COSMOS can manage)<br />
* Namespace (WSDL identity)<br />
* State (persistence handling)<br />
* LifeCycle (advertisement)<br />
* Reference handling (autowiring)<br />
<br />
These concerns will be seperated into different annotations as follows:<br />
<br />
''ManagedResource''<br />
<pre><br />
/**<br />
* Annotation used to indicate a class to be exposed as a manageable resource. <br />
*/<br />
@Target(TYPE)<br />
@Retention(RUNTIME)<br />
public @interface ManagedResource {<br />
/**<br />
* Service name.<br />
*/<br />
String serviceName() default "";<br />
/**<br />
* Target namespace for the service<br />
*/<br />
String targetNamespace() default "";<br />
}<br />
</pre><br />
<br />
''JAX-WS Replacement''<br />
WebService or WebServiceProvider can completely replace ManagedResource<br />
<br />
''ManagedState''<br />
<pre><br />
/**<br />
* Annotation used to indicate a class to be exposed as a manageable resource. <br />
*/<br />
@Target(TYPE)<br />
@Retention(RUNTIME)<br />
public @interface ManagedState {<br />
/**<br />
* The desired persistence model for the resource. <br />
*/<br />
String persistent() default "never";<br />
}<br />
</pre><br />
<br />
''ManagedAdvertisement''<br />
<pre><br />
/**<br />
* Annotation used to indicate a class to be exposed as a manageable resource. <br />
*/<br />
@Target(TYPE)<br />
@Retention(RUNTIME)<br />
public @interface ManagedAdvertisement {<br />
/**<br />
* If true, indicates that the resource should support advertisement, and<br />
* that the initial advertisementConsumer should be honored. <br />
*/<br />
boolean advertise() default false;<br />
/**<br />
* A text string used by the management host to identify the<br />
* endpoint of an initial advertisement. This attribute is only used<br />
* if advertise is true. <br />
*/<br />
String advertisementConsumer() default "";<br />
<br />
}<br />
</pre><br />
<br />
''ManagedReference''<br />
<pre><br />
/**<br />
* Annotation used to indicate a class to be exposed as a manageable resource. <br />
*/<br />
@Target(TYPE)<br />
@Retention(RUNTIME)<br />
public @interface ManagedReference {<br />
/**<br />
* A name used to supply a target for AutoWire-annotated<br />
* fields in other managed components.<br />
*/<br />
String autowireName();<br />
<br />
}<br />
</pre><br />
<br />
=== '''Type Level (Non-Resource) Annotation Mapping'''===<br />
<br />
=== '''Method Level Annotation Mapping'''===<br />
<br />
=== '''Field Level Annotation Mapping'''===<br />
<br />
=== '''Contribution Manager Modifications'''===<br />
Convert to opt-in.<br />
Process common annotations.<br />
<br />
=== '''WebServices Binding Implementation'''===<br />
Define precedence order for annotations<br />
Define failure cases (seen above).<br />
<br />
=== '''UI workflows''' ===<br />
<br />
There are no UI implications for this enhancement.<br />
<br />
=== '''Testing (J2EE)''' ===<br />
<br />
<br />
=== '''Deployment (J2EE)''' ===<br />
<br />
<br />
=== '''Testing (OSGi)''' ===<br />
<br />
<br />
=== '''Deployment (OSGi)''' ===<br />
<br />
This approach is TBD.<br />
<br />
== '''Task Breakdown''' ==<br />
<br />
Required tasks:<br />
# Axis2 bundle updates to supply JAX-WS imports<br />
# Modification of ContributionManager to support Binding opt-in approach.<br />
# WSDL management.<br />
# JUnits to test opt-in.<br />
# Update WSRF and WSDM capability implementations to use JAX-WS <br />
# Create a me.management.webservices component to handle binding management targets with JAX-WS annotations<br />
# JUnits to JAX-WS scenarios.<br />
# Deprecate me.management.wsdm and replace all of the current annotated components in COSMOS with JAX-WS annotations<br />
<br />
== '''Test Coverage''' ==<br />
<br />
<br />
== '''Open Issues/Questions '''==<br />
<br />
IPZilla for Axis2<br />
Security requirement interactions<br />
<!--* What other things are available, e.g. STP or WTP may have annotations for web services--><br />
<br />
All reviewer feedback should go in the [[Talk:COSMOS_Design_216809|Talk page for 216809]].<br />
<br />
== '''References''' ==<br />
<br />
[[Category:COSMOS_Bugzilla_Designs]]</div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=COSMOS_Design_216809&diff=87083COSMOS Design 2168092008-03-12T18:45:09Z<p>Joel.hawkins.compuware.com: New page: == '''Line up JAX-WS annotations and management annotations in ME''' == This is the design document for [https://bugs.eclipse.org/bugs/show_bug.cgi?id=216809 bugzilla 216809]. === '''Cha...</p>
<hr />
<div>== '''Line up JAX-WS annotations and management annotations in ME''' ==<br />
<br />
This is the design document for [https://bugs.eclipse.org/bugs/show_bug.cgi?id=216809 bugzilla 216809].<br />
<br />
=== '''Change History''' ===<br />
{|{{BMTableStyle}}<br />
!align="left"|Name:<br />
!align="left"|Date: <br />
!align="left"|Revised Sections:<br />
|-<br />
|Joel Hawkins<br />
|3/12/2008 <br />
|<ul><li>Initial version</li></ul><br />
|-<br />
== ''' Workload Estimation''' ==<br />
<br />
{|{{BMTableStyle}}<br />
|+{{BMTableCaptionStyle}}|Rough workload estimate in person weeks<br />
|-{{BMTHStyle}}<br />
! Process<br />
! Sizing <br />
! Names of people doing the work<br />
|-<br />
| align="left" | Design<br />
| 1<br />
| Joel <br />
|-<br />
| align="left" | Code<br />
| 2<br />
| Joel<br />
|-<br />
| align="left" | Test <br />
| 1<br />
| Joel/Hubert/QA<br />
|-<br />
| align="left" | Documentation <br />
| 2<br />
| Joel/Rich<br />
|-<br />
| align="left" | Build and infrastructure<br />
| 0<br />
|<br />
|-<br />
| align="left" | Code review, etc.*<br />
| 0<br />
|<br />
|-<br />
! align="right" | TOTAL<br />
| 6.0<br />
|<br />
|}<br />
<br />
== '''Terminologies/Acronyms''' ==<br />
<br />
The terminologies/acronyms below can be used throughout this document. <br />
<br />
'''Note:''' These definitions are not meant to be general definitions of these terms, but rather refer to how the terms are used within this design document as applied to COSMOS.<br />
<br />
{|{{BMTableStyle}}<br />
|-{{BMTHStyle}}<br />
! Term <br />
! Definition<br />
|-<br />
|JAX-WS<br />
|The Java WebServices API specified by JSRs 224 and 181<br />
|-<br />
|}<br />
<br />
== '''Purpose''' ==<br />
Axis2 provides an implementation of JAX-WS, which provides a library of<br />
annotations for web services. COSMOS code has been using annotations that Joel<br />
contributed to the project. The "COSMOS annotations" are oriented towards<br />
management interfaces. Despite the difference, there may be annotations that<br />
have similar purposes, and can be reconciled. This enhancement is for "lining<br />
up" the two set of annotations, and use the JAX-WS standard where possible.<br />
<br />
== '''Use Cases''' ==<br />
<br />
The following have been identified as use cases related to this enhancement.<br />
<br />
<ol><br />
<li>Developer binds a statefull (instance) provider<br><br />
<br />
There are two variations on this use case:<br />
<ol><br />
<li>Data manager is being created from scratch.<br><br />
This is addressed in [[#Creating a new Data Manager project|Creating a new Data Manager project]].</li><br />
<li>Data manager is being adapted to existing data source.<br><br />
This is the case where the user imports an MDR into Eclipse. Users will create a normal Eclipse project, and then based on the config.properties and domainEPR.xml files, new manifest editor pages will be displayed for editing these. See [[#Updating Data Manager Project|Updating Data Manager Project]].</li><br />
</ol><br />
</li><br />
<li>Developer binds a stateless (singleton) provider.<br><br />
This is addressed in [[#Deployment|Deployment]].<br />
</ol><br />
<br />
== '''Development environment''' ==<br />
<br />
<br />
== '''Extensibility''' ==<br />
<br />
<br />
== '''Detailed Design''' ==<br />
<br />
The code for this enhancement will be part of the Management Enablement project. The code will span multiple plug-ins. Both J2EE and OSGi deployments will be supported.<br />
<br />
* <code>org.eclipse.cosmos.me.management.common</code> - base annotation definitions and utility classes<br />
* <code>org.eclipse.cosmos.me.management.webservices</code> - contains the JAX-WS specific code. This plug-in will have a dependency on an external provider of the JAX-WS annotation classes.<br />
<br />
The programming model for COSMOS centers around the concepts of state and composition. COSMOS managed objects are currently exposed as instances, <br />
and these instances expose operations and properties as parts of distinct capabilities. <br />
<br />
JAX-WS, on the other hand, centers around the concept of stateless interfaces. A large part of the reconcilliation effort resides in mapping JAX-WS's descriptive<br />
characteristics onto the COSMOS statefull composition model. <br />
<br />
<br />
Resource/Type-Level annotations<br />
<pre><br />
ManagedResource<br />
ManagedResource --- ManagedResource (Substitute WebService, WebServiceProvider)<br />
ManagedAdvertisement (Optional), <br />
ManagedState (Optional), <br />
ManagedReferece (Optional)<br />
<br />
ManagedResourceCapability --- ManagedResourceCapability (Substitute WebService, WebServiceProvider)<br />
<br />
ComposableManagedCapabilitySet --- Untouched. No substitute<br />
<br />
Honored JAX-WS annotations<br />
SOAPBinding - verify that this must match Muse expectations - fail the bind and log otherwise<br />
BindingType - verify that this must match Muse expectations - fail the bind and log otherwise<br />
RequestWrapper - may be useful for some operations...TBD <br />
ResponseWrapper - may be useful for some operations...TBD <br />
ServiceMode - verify that this must match Muse expectations - fail the bind and log otherwise<br />
WebFault - may be useful for some operations...TBD<br />
</pre><br />
<br />
Method-Level annotations<br />
<pre><br />
ManagedResourceFactory --- Deprecate. Use JAX-WS singleton semantics instead<br />
CreateManagedRelation --- Untouched. No substitute<br />
DestroyManagedRelation --- Untouched. No substitute.<br />
ManagedPropertyGetter --- Untouched. No substitute. <br />
ManagedPropertySetter --- Untouched. No substitute.<br />
ManagedEvent --- Untouched. No substitute.<br />
ManagedEventConsumer --- Untouched. No substitute.<br />
<br />
ManagedOperation<br />
ManagedOperation --- ManagedOperation(Substitute WebMethod)<br />
<br />
<br />
Honored JAX-WS annotations<br />
Oneway - invalid for COSMOS - fail the bind and log<br />
WebResult <br />
SOAPBinding - verify that this must match Muse expectations - fail the bind and log otherwise<br />
WebEndpoint - TBD<br />
<br />
</pre><br />
Parameter-Level annotations <br />
<pre><br />
ManagedParameter --- (Substitute WebParam) TBD - using JAXB or Muse serialization. <br />
ManagedEventSource --- Untouched. No substitute.<br />
ManagedEventSituation --- Untouched. No substitute<br />
</pre><br />
<br />
=== '''Resource Level Annotation Mapping'''===<br />
<br />
The base annotation for COSMOS components is the ManagedResource interface. This interfaces is currently used as a tagging interface to identify a<br />
component implementation's suitability for management under COSMOS.<br />
<br />
''Managed Resource''<br />
<br />
<pre><br />
/**<br />
* Annotation used to indicate a class to be exposed as a manageable resource. <br />
*/<br />
@Target(TYPE)<br />
@Retention(RUNTIME)<br />
public @interface ManagedResource {<br />
/**<br />
* A text description of the resource. This value will be used as the<br />
* default description when the resource is introspected.<br />
*/<br />
String description() default "";<br />
/**<br />
* The namespace of the resource. This namespace will be used for all<br />
* operations and properties exposed by this resource (unless overridden) <br />
* that are not part of some other capability <br />
*/<br />
String namespace() default "";<br />
/**<br />
* The desired persistence model for the resource. <br />
*/<br />
String persistent() default "never";<br />
<br />
/**<br />
* If true, indicates that the resource should support advertisement, and<br />
* that the initial advertisementConsumer should be honored. <br />
*/<br />
boolean advertise() default false;<br />
/**<br />
* A text string used by the management host to identify the<br />
* endpoint of an initial advertisement. This attribute is only used<br />
* if advertise is true. <br />
*/<br />
String advertisementConsumer() default "";<br />
<br />
/**<br />
* A name used to supply a target for AutoWire-annotated<br />
* fields in other managed components.<br />
*/<br />
String autowireName() default "";<br />
<br />
}<br />
</pre><br />
<br />
The JAX-WS analogs to ManagedResource are WebService and WebServiceProvider<br />
<br />
<pre><br />
@Retention(value=RetentionPolicy.RUNTIME)<br />
@Target({TYPE})public <br />
@interface WebService {<br />
String name() default "";<br />
String targetNamespace() default "";<br />
String serviceName() default "";<br />
String wsdlLocation() default "";<br />
String endpointInterface() default "";<br />
String portName() default "";<br />
}<br />
</pre><br />
<br />
<pre><br />
/**<br />
* Used to annotate a Provider implementation class.<br />
*<br />
* @since JAX-WS 2.0<br />
* @see javax.xml.ws.Provider<br />
*/<br />
@Target(ElementType.TYPE)<br />
@Retention(RetentionPolicy.RUNTIME)<br />
public @interface WebServiceProvider {<br />
/**<br />
* Location of the WSDL description for the service.<br />
*/<br />
String wsdlLocation() default "";<br />
/**<br />
* Service name.<br />
*/<br />
String serviceName() default "";<br />
/**<br />
* Target namespace for the service<br />
*/<br />
String targetNamespace() default "";<br />
/**<br />
* Port name.<br />
*/ <br />
String portName() default "";<br />
}<br />
</pre><br />
<br />
ManagedResource as it is currently constituted enapsulates a number of concerns: <br />
* Tagging (identifying a resource as one that COSMOS can manage)<br />
* Namespace (WSDL identity)<br />
* State (persistence handling)<br />
* LifeCycle (advertisement)<br />
* Reference handling (autowiring)<br />
<br />
These concerns will be seperated into different annotations as follows:<br />
<br />
''ManagedResource''<br />
<pre><br />
/**<br />
* Annotation used to indicate a class to be exposed as a manageable resource. <br />
*/<br />
@Target(TYPE)<br />
@Retention(RUNTIME)<br />
public @interface ManagedResource {<br />
/**<br />
* Service name.<br />
*/<br />
String serviceName() default "";<br />
/**<br />
* Target namespace for the service<br />
*/<br />
String targetNamespace() default "";<br />
}<br />
</pre><br />
<br />
''JAX-WS Replacement''<br />
WebService or WebServiceProvider can completely replace ManagedResource<br />
<br />
''ManagedState''<br />
<pre><br />
/**<br />
* Annotation used to indicate a class to be exposed as a manageable resource. <br />
*/<br />
@Target(TYPE)<br />
@Retention(RUNTIME)<br />
public @interface ManagedState {<br />
/**<br />
* The desired persistence model for the resource. <br />
*/<br />
String persistent() default "never";<br />
}<br />
</pre><br />
<br />
''ManagedAdvertisement''<br />
<pre><br />
/**<br />
* Annotation used to indicate a class to be exposed as a manageable resource. <br />
*/<br />
@Target(TYPE)<br />
@Retention(RUNTIME)<br />
public @interface ManagedAdvertisement {<br />
/**<br />
* If true, indicates that the resource should support advertisement, and<br />
* that the initial advertisementConsumer should be honored. <br />
*/<br />
boolean advertise() default false;<br />
/**<br />
* A text string used by the management host to identify the<br />
* endpoint of an initial advertisement. This attribute is only used<br />
* if advertise is true. <br />
*/<br />
String advertisementConsumer() default "";<br />
<br />
}<br />
</pre><br />
<br />
''ManagedReference''<br />
<pre><br />
/**<br />
* Annotation used to indicate a class to be exposed as a manageable resource. <br />
*/<br />
@Target(TYPE)<br />
@Retention(RUNTIME)<br />
public @interface ManagedReference {<br />
/**<br />
* A name used to supply a target for AutoWire-annotated<br />
* fields in other managed components.<br />
*/<br />
String autowireName();<br />
<br />
}<br />
</pre><br />
<br />
=== '''Type Level (Non-Resource) Annotation Mapping'''===<br />
<br />
=== '''Method Level Annotation Mapping'''===<br />
<br />
=== '''Field Level Annotation Mapping'''===<br />
<br />
=== '''Contribution Manager Modifications'''===<br />
Convert to opt-in.<br />
Process common annotations.<br />
<br />
=== '''WebServices Binding Implementation'''===<br />
Define precedence order for annotations<br />
Define failure cases (seen above).<br />
<br />
=== '''UI workflows''' ===<br />
<br />
There are no UI implications for this enhancement.<br />
<br />
=== '''Testing (J2EE)''' ===<br />
<br />
<br />
=== '''Deployment (J2EE)''' ===<br />
<br />
<br />
=== '''Testing (OSGi)''' ===<br />
<br />
<br />
=== '''Deployment (OSGi)''' ===<br />
<br />
This approach is TBD.<br />
<br />
== '''Task Breakdown''' ==<br />
<br />
Required tasks:<br />
# Axis2 bundle updates to supply JAX-WS imports<br />
# Modification of ContributionManager to support Binding opt-in approach.<br />
# WSDL management.<br />
# JUnits to test opt-in.<br />
# Update WSRF and WSDM capability implementations to use JAX-WS <br />
# Create a me.management.webservices component to handle binding management targets with JAX-WS annotations<br />
# JUnits to JAX-WS scenarios.<br />
# Deprecate me.management.wsdm and replace all of the current annotated components in COSMOS with JAX-WS annotations<br />
<br />
== '''Test Coverage''' ==<br />
<br />
<br />
== '''Open Issues/Questions '''==<br />
<br />
IPZilla for Axis2<br />
Security requirement interactions<br />
<!--* What other things are available, e.g. STP or WTP may have annotations for web services--><br />
<br />
All reviewer feedback should go in the [[Talk:COSMOS_Design_208274|Talk page for 208274]].<br />
<br />
== '''References''' ==<br />
<br />
[[Category:COSMOS_Bugzilla_Designs]]</div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=COSMOS_Design_218016&diff=81905COSMOS Design 2180162008-02-12T20:06:45Z<p>Joel.hawkins.compuware.com: New page: Back to Management Enablement Design = '''Change History''' = {|{{BMTableStyle}} !align="left"|Name: !align="left"|Date: !align="left"|Revised Sectio...</p>
<hr />
<div>Back to [[CosmosManagementEnablementDesign|Management Enablement Design]]<br />
<br />
= '''Change History''' =<br />
{|{{BMTableStyle}}<br />
!align="left"|Name:<br />
!align="left"|Date: <br />
!align="left"|Revised Sections:<br />
|-<br />
|Joel Hawkins <br />
|02/12/2008 <br />
|<ul><li>Initial version</li></ul><br />
|}<br />
<br />
= ''' Workload Estimation''' =<br />
<br />
{|{{BMTableStyle}}<br />
|+{{BMTableCaptionStyle}}|Rough workload estimate in person weeks<br />
|-{{BMTHStyle}}<br />
! Process<br />
! Sizing <br />
! Names of people doing the work<br />
|-<br />
| align="left" | Design<br />
| 0.2<br />
| Joel Hawkins<br />
|-<br />
| align="left" | Code<br />
| 2<br />
|<br />
|-<br />
| align="left" | Test <br />
| 1<br />
|<br />
|-<br />
| align="left" | Documentation <br />
| 0.5<br />
|<br />
|-<br />
| align="left" | Build and infrastructure<br />
| 0.3<br />
|<br />
|-<br />
| align="left" | Code review, etc.*<br />
|<br />
|<br />
|-<br />
! align="right" | TOTAL<br />
| 4<br />
|<br />
|}<br />
<br />
'* - includes other committer work (e.g. check-in, contribution tracking)<br />
<br />
=Requirement=<br />
When serializing EPRs for cosmos components, the underlying muse infrastructure<br />
replaces the hostname supplied for the managed resource with the IP address<br />
corresponding to the host name. This may cause problems when communicating with<br />
IPv6 networks or when re-basing a given host onto a different address.<br />
<br />
=Design=<br />
By default, the wsdm binding use the canonical host name of the local host as the host portion of the endpoint reference address. <br />
If the system property org.eclipse.cosmos.me.management.UseIPAddressForEPR is true, then the binding will use the IP address of the local host.<br />
<br />
The ManagedResource annotation will be augmented to allow adopters to specify how to represent the hostname when constructing the resource's EPR. <br />
<br />
<pre><br />
/**<br />
* Annotation used to indicate a class to be exposed as a manageable resource. <br />
*/<br />
@Target(TYPE)<br />
@Retention(RUNTIME)<br />
public @interface ManagedResource {<br />
/**<br />
* A text description of the resource. This value will be used as the<br />
* default description when the resource is introspected.<br />
*/<br />
String description() default "";<br />
/**<br />
* The namespace of the resource. This namespace will be used for all<br />
* operations and properties exposed by this resource (unless overridden) <br />
* that are not part of some other capability <br />
*/<br />
String namespace() default "";<br />
/**<br />
* The desired persistence model for the resource. <br />
*/<br />
String persistent() default "never";<br />
<br />
/**<br />
* If true, indicates that the resource should support advertisement, and<br />
* that the initial advertisementConsumer should be honored. <br />
*/<br />
boolean advertise() default false;<br />
/**<br />
* A text string used by the management host to identify the<br />
* endpoint of an initial advertisement. This attribute is only used<br />
* if advertise is true. <br />
*/<br />
String advertisementConsumer() default "";<br />
<br />
/**<br />
* A name used to supply a target for AutoWire-annotated<br />
* fields in other managed components.<br />
*/<br />
String autowireName() default "";<br />
<br />
/**<br />
* Use the host name when generating the resource's EPR.<br />
* If useHostNameInEPR is set to false, the numeric IP address<br />
* is used instead.<br />
*/<br />
boolean useHostNameInEPR() default true;<br />
<br />
}<br />
</pre><br />
<br />
==Open Issues/Questions==<br />
<br />
All reviewer feedback should go in the [[Talk:COSMOS_Design_218016|Talk page for 218016]].<br />
<br />
<br />
[[Category:COSMOS_Bugzilla_Designs]]</div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=COSMOS_Design_209227&diff=69454COSMOS Design 2092272007-12-18T15:49:23Z<p>Joel.hawkins.compuware.com: /* Logging an Exception */</p>
<hr />
<div>== Overview ==<br />
<br />
Comments and discussion on the [[Talk:COSMOS Design 209227|talk page]]<br />
<br />
The scope of this document is to define the exception and error handling in a consistent manner throughout the scope of the COSMOS project. It is expected that COSMOS will have different adoption patterns. For example, the Management Data Repository framework does not have to require the COSMOS user interface. Therefore, it is important for the logging and exception strategy of COSMOS to be compatible with existing management infrastructure. . Because COSMOS does not have any existing exception or logging facilities, it makes sense to look towards existing standards for guidelines and ideas.<br />
<br />
<br />
*[update this section with conversation from Jimmy. Elaborate on adoption scenarios and how exceptions matter in here]<br />
<br />
* show this<br />
WS-Soap Fault -> Convenience API -> DataManager API -> Native API<br />
* Network Boundary is the only place where soap faults come into play<br />
* The convenience api must be able to catch exceptions b/c it may need to return a fault that is specified by a spec, e.g. CMDBf<br />
* Data Managers should be able to catch exceptions when wrapping native/existing access APIs to the data<br />
* Do not want to expose the soap faults to: a) the user b) the adopter<br />
* What is the difference b/t convenience api and data manager api? (convenience api will have spec defined faults, map to exceptions)<br />
<br />
<br />
== Exception Definition ==<br />
The Oasis Web Services Distributed Management specification defines a general purpose event format and a set of situations that will be used as the logging and event structure for COSMOS. The WSDM Event Format (WEF) is derived from the Common Base Event (CBE) structure found in the TPTP project. In fact, CBE was the initial submission to Oasis and served as the starting point for WEF<br />
<br />
<br />
One of the goals of the COSMOS is consistency between the exceptions in the code, entries that are logged, and the management events that are raised. Consistency between the logs and exceptions brings the management aspects closer to the point of origin in the code and improves manageability. A key aspect of this consistency is situations, and more specifically, situation category.<br />
<br />
<br />
The WSDM specification defines a “situation” element that helps classify an event. The situations were derived by a “thorough analysis of event types” [MUWS, Part 2, 2.5.1]. Situations allow another dimension of classifications for events and facilitate consistent analysis across heterogeneous components, including COSMOS. All COSMOS developers should be familiar with the WSDM specification, specifically, WSDM 1.1, MUWS Part 1, section 4 , as well as WSDM 1.1, MUWS Part 2, section 2.5, and Appendix F. These sections define the situation format and present guidelines for its usage.<br />
*[Is the burden to understand situations too much for the developer? They would need to know what situation that applies. ]<br />
<br />
<br />
Not all fields defined by the WSDM specification for situation type are necessary for exceptions. For example, because exceptions are thrown when bad things happen, SuccessDisposion will always be “Unsuccessful”. Likewise, the “Message” field is logically the same as the private variable “detailedMessage” in Java Exception. Where COSMOS can take guidance from the WSDM specification is by creating a common exception class that captures the extra detail that can be placed directly into the logs as part of the situation. <br />
* SituationCategory (required)<br />
* SituationTime (optional, defaults to System time)<br />
* Priority (optional)<br />
* Severity (optional)<br />
<br />
<br />
There will be a root level exception defined as part of COSMOS (org.eclipse.cosmos.common.exceptions.CosmosException). This will subclass java.lang.Exception and define protected variables for each of the four additional fields defined above. An enumerated list of values will be provided for SituationCategory and Severity. ''Exceptions are considered part of the COSMOS API and will conform to the API guidelines specified by Eclipse''.<br />
<br />
<br />
The use of the additional fields added by COSMOSException is strongly encouraged throughout the project. However, there are circumstances within the code where it may be difficult to determine additional classification via situation. Thus, the use of these additional fields are optional. Further, in the situations where third party users are extending the framework, we will encourage, but not require the adoption of these fields.<br />
<br />
== Exception Hierarchy ==<br />
The main exception class in COSMOS is: org.eclipse.cosmos.common.COSMOSException. It is the intent of the COSMOS project to keep the exception hierarchy shallow, and introduce child exceptions only when necessary.<br />
<br />
One situation where it is necessary to introduce a new subclass of exception is when a management standard defines a set of faults. An example of this is the CMDBf specification. In these circumstances, it is appropriate to map an Java exception onto the fault defined by the specification. For an example, please reference org.eclipsecosmos.dc.mdr.exception.CMDBfException.<br />
<br />
== Logging an Exception ==<br />
<br />
<br />
* Joel volunteered to take first pass here.<br />
** Some initial thoughts....<br />
<br />
All WSDM faults implemented in Muse derive from BaseFault. Base Fault contains an 'origin' field, for designating the party responsible for raising the fault. We may want to add this as an optional field in our CosmosException base class. When not present, a value can be intuited based on the current handler of an inbound request (this will require a bit of work to support, but is do-able). <br />
<br />
The current CosmosFault implementation appears to be situated somewhere between a Wef Event and a Base Fault. It contains situation info (Wef), but has none of the referential fields (like Reporter, etc).<br />
<br />
The relationship between exception and logging: Exceptions are created and thrown at the origin of the problem. Logging is (usually) done at the receiver end of the exception, e.g. a catch block. Logging can also be done at situations without exceptions. Logs are used for a debugging/tracing purposes, and exceptions are programming constructs to handle and recover from error situations. <br />
<br />
We appear to be settling on Log4j as an implementation, which is reasonable considering our relationship to Apache Muse. Log4j supports a logging delegation model based on appenders - which enables us to do things like advertise the existence of a log file or forward exceptions as wef events to an external listener, etc. by implementing our own appender for logged cosmos events. <br />
<br />
<br />
Components:<br />
- Domain<br />
- Broker<br />
- MDR/Data manager<br />
<br />
-> Each component will keep its own log file<br />
-> can use tooling (TPTP) to merge them when doing analysis<br />
<br />
Log format<br />
- Java logging<br />
- muse logging (?)<br />
- any transaction ID to inject into log record for correlation<br />
<br />
We'll require our own logging formatter to enable things like transaction injection, etc. This argues (again) for implementing a Cosmos log4j appender.<br />
<br />
Error code<br />
<br />
Translation<br />
* Message catalogs<br />
<br />
<br />
* Map Operational Status on the MDR<br />
** Datamanager available, but application it's wrapping is not available, what's the op status of the data manager<br />
<br />
* logfile registry & viewer<br />
* error/warning event pub/sub<br />
* cbe v. wef <br />
* msg formats & IDs (valentina to help here)<br />
<br />
<br />
<br />
<br />
----<br />
<br />
== Additional Topics to cover... ==<br />
<br />
*stratify the conversation<br />
** What do we do at the exact point of exception<br />
** What do we do where we catch / recover the exception<br />
** What is the interface between local exception handling and WSDM<br />
** How do we interact with the logging system - it must accept these WEF events?<br />
** How do we integrate with non-COSMOS exceptions?<br />
** Which component will build these features?<br />
<br />
<br />
----<br />
[[Category:COSMOS_Bugzilla_Designs]]</div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=Talk:COSMOS_Bug_Design_209248&diff=64364Talk:COSMOS Bug Design 2092482007-11-28T13:17:46Z<p>Joel.hawkins.compuware.com: </p>
<hr />
<div>Do we have a complete list of the Muse annotations? It would be good if we had an “Management Annotations Reference Page” on the wiki--a glossary of annotations if you will. It would be good to indicate the annotations that affect an external interface, e.g. “ManagedResourceCapability” vs. one that supports the framework “Autowire”.<br />
Can we java doc this and just use that?<br />
<br />
<Joel>I think a wiki page makes sense. Currently the annotations are all in an "annotations" package, so they're pretty easy to find. I can add some verbiage to the javadoc to indicate the external impact of each annotation.</Joel><br />
<br />
Why does the ManagedResourceCapability need to know if it’s composable or not? There could be situations where the capability can be used in either way. DataBroker may be an example. The DataBroker is essentially composing in a custom DataBroker capability with Service Groups. However, there could be another DataBroker that does not use service groups. Given this, why do we have to know? Why not just always make it composable?<br />
<br />
<Joel> The composible option is there to give users the ability to opt-in to a composition scheme. Hubert had a similiar question when I presented this on the DC call, and we agreed to switch the polarity on composible to opt-out, so by default all ManagedResourceCapability annotations are composable. It's just a question of control. Since you can annotate a class as well as an interface, someone may want to keep their implementation to themselves. </Joel><br />
<br />
Will the Muse resource router implement the ComposableManagedCapabilitySet interface? It might be a good fit to introduce an annotated router that does the composition. <br />
<br />
<Joel> Interesting thought. Muse doesn't currently expose the resource router itself, but I see no real reason not to. Are you thinking of decorating it with some MOWS interfaces?</Joel><br />
<br />
Will you elaborate on the “singleton requirement for CMDBf”? I’m not sure I’m following what you are referring to. We will have more than one MDR in the systems, so making that a singleton does not make sense? I suppose it’s conceivable that we would have multiple federating CMDBs in a system as well (although this does seem much less likely).<br />
<br />
<Joel>This was the issue with CMDBf specifying it's remote interface without addressing information. The Singlton aspect was within the scope of a ResourceRouter.</Joel> <br />
<br />
Is there a way to get to the Muse deployment descriptor? Are there options available in this that we might want to expose. Maybe a combination of an autowire target and a factory....<br />
<br />
<Joel>For annotations, there is no deployment descriptor - it's all generated on the fly. If we're going to put a management interface on the resource router, maybe that's a good place to provide deployment descriptor-level functionality. I like the concept, I just need to think about what's involved...</Joel><br />
<br />
When & where do the binding rules apply? Are they used by the factory? <br />
<br />
<Joel>Binding rules apply whenever a managed resource is handed to the ContributionManager. Since a factory would wind up handing it's output to the ContributionManager, then yes, the factory would essentially use the binding rules. </Joel><br />
<br />
Can we follow on this doc with a very simple example of the things that we talk about?<br />
<br />
<Joel>I was thinking of doing that with the WSDM properties we automagically add today. Of course, I'll also have test cases that will exercise this with generic interfaces/classes.</Joel></div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=COSMOS_Bug_Design_209248&diff=64350COSMOS Bug Design 2092482007-11-28T13:01:35Z<p>Joel.hawkins.compuware.com: </p>
<hr />
<div>Comments are on the [[Talk:COSMOS_Bug_Design_209248|Talk]] page<br />
<br />
<br />
The Muse programming model is a composition-oriented model, where capabilities<br />
can be imposed on a resource implementation externally. In the annotations, the<br />
composition model can be supported programatically by creating a single facade<br />
over multiple capability implementations, but the annotations don't provide any<br />
support to make this easier. <br />
<br />
The annotations should provide support for this model in order to<br />
enforce/encourage alignment with the existing Muse programming model.<br />
<br />
<pre><br />
/**<br />
* Annotation used to indicate an interface which to be exposed as a distinct <br />
* management capability. <br />
*/<br />
@Target(TYPE)<br />
@Retention(RUNTIME)<br />
public @interface ManagedResourceCapability {<br />
<br />
/**<br />
* A text description of the capability. <br />
* This attribute is intended for tooling support. <br />
* <br />
*/<br />
String description() default "";<br />
/**<br />
* The namespace of the capability. This namespace will be used for all<br />
* operations and properties exposed by this capability (unless overridden) <br />
* and will uniquely identify the capability when introspecting its resource. <br />
*/<br />
String namespace();<br />
<br />
/**<br />
* Indicates that the annotated implementation may be used in conjunction<br />
* with the ComposableManagedCapabilitySet annotation to implement a <br />
* composite managed resource <br />
*/<br />
boolean composable() default true;<br />
}<br />
</pre><br />
<br />
<pre><br />
<br />
/**<br />
* Annotation used to decorate a ManagedResource with externally implemented capabilities <br />
*/<br />
@Target(TYPE)<br />
@Retention(RUNTIME)<br />
public @interface ComposableManagedCapabilitySet {<br />
<br />
/**<br />
* The set of capability classes to decorate the targeted <br />
* ManagedResource instance with. This annotation works<br />
* in conjunction with the ManagedFrameworkAutowire, <br />
* ManagedResourceCapability, and ManagedResourceFactory <br />
* annotations to enable the framework to replicate the<br />
* delcarative programming model exposed by Muse.xml <br />
*/<br />
Class[] set() default {};<br />
<br />
}<br />
</pre><br />
<br />
<pre><br />
<br />
/**<br />
* Annotation used to support autowiring of <br />
* Components within the management framework.<br />
*/<br />
@Target(FIELD)<br />
@Retention(RUNTIME)<br />
public @interface ManagedFrameworkAutowire {<br />
/**<br />
* Name of the desired Component<br />
*/<br />
String name() default "";<br />
<br />
/**<br />
* Class of the desired Capability. This attribute works <br />
* in conjunction with the ComposableManagedCapabilitySet<br />
* annotation<br />
*/<br />
Class capability() default Void.class;<br />
}<br />
</pre><br />
<br />
The following annotations (proposed as a way to support the Singleton requirement for CMDBf) can be used for this purpose as well.<br />
<br />
<pre><br />
/**<br />
* Annotation used to indicate a factory method to construct a framework component. <br />
*/<br />
@Target(METHOD)<br />
@Retention(RUNTIME)<br />
public @interface ManagedResourceFactory {<br />
<br />
/**<br />
* If true, indicates that the resource is a singleton, and only the default <br />
* instance may be registered. All other instances attempting to register will<br />
* be rejected <br />
*/<br />
boolean singleton() default false;<br />
<br />
}<br />
</pre><br />
<br />
Binding rules:<br />
<br />
For composable capability set values:<br />
<br />
* check that each set element is annotated as a capability<br />
* check that each set element is composable<br />
* construct the composed capability instances<br />
** if the capability has a designated factory method, use that method to construct the instance<br />
** if the capability does not have a factory method, use the capability's namespace to see if a factory has been registered with the contribution manager (Minor change required to ContributionManager interface). If yes, use that factory to construct the capaiblity instance. Ensure that the instance matches the capability class. If no factory exists, or if the instance is not assignable, fail the bind request.<br />
* Perform any requested autowires. Wiring requests based on class are taken from the composed capability set. Wiring requests based on names are taken from the ContributionManager. <br />
* Ensure that all duplicated capabilities (between composed and interface implementation) share a satisfied wiring target. If a capability is duplicated, but no wiring target exists, fail the binding. The assumption is that the intent is to use the POJO interface to proxy to the delegated implementation. We don't want the POJO invocation and the bound invocation to take different paths through the resource. <br />
* Bind the result to the appropriate managagement binding. The binding needs to ensure that composed capabilities and capabilities based on implemented interfaces are not represented twice (No duplicated Port types!). Bindings should ensure that all calls route to the interface call first, based on the assumption that the interface call will delegate to the autowire target.</div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=COSMOS_Bug_Design_209248&diff=61835COSMOS Bug Design 2092482007-11-16T21:33:51Z<p>Joel.hawkins.compuware.com: </p>
<hr />
<div>The Muse programming model is a composition-oriented model, where capabilities<br />
can be imposed on a resource implementation externally. In the annotations, the<br />
composition model can be supported programatically by creating a single facade<br />
over multiple capability implementations, but the annotations don't provide any<br />
support to make this easier. <br />
<br />
The annotations should provide support for this model in order to<br />
enforce/encourage alignment with the existing Muse programming model.<br />
<br />
<pre><br />
/**<br />
* Annotation used to indicate an interface which to be exposed as a distinct <br />
* management capability. <br />
*/<br />
@Target(TYPE)<br />
@Retention(RUNTIME)<br />
public @interface ManagedResourceCapability {<br />
<br />
/**<br />
* A text description of the capability. <br />
* This attribute is intended for tooling support. <br />
* <br />
*/<br />
String description() default "";<br />
/**<br />
* The namespace of the capability. This namespace will be used for all<br />
* operations and properties exposed by this capability (unless overridden) <br />
* and will uniquely identify the capability when introspecting its resource. <br />
*/<br />
String namespace();<br />
<br />
/**<br />
* Indicates that the annotated implementation may be used in conjunction<br />
* with the ComposableManagedCapabilitySet annotation to implement a <br />
* composite managed resource <br />
*/<br />
boolean composable() default false;<br />
}<br />
</pre><br />
<br />
<pre><br />
<br />
/**<br />
* Annotation used to decorate a ManagedResource with externally implemented capabilities <br />
*/<br />
@Target(TYPE)<br />
@Retention(RUNTIME)<br />
public @interface ComposableManagedCapabilitySet {<br />
<br />
/**<br />
* The set of capability classes to decorate the targeted <br />
* ManagedResource instance with. This annotation works<br />
* in conjunction with the ManagedFrameworkAutowire, <br />
* ManagedResourceCapability, and ManagedResourceFactory <br />
* annotations to enable the framework to replicate the<br />
* delcarative programming model exposed by Muse.xml <br />
*/<br />
Class[] set() default {};<br />
<br />
}<br />
</pre><br />
<br />
<pre><br />
<br />
/**<br />
* Annotation used to support autowiring of <br />
* Components within the management framework.<br />
*/<br />
@Target(FIELD)<br />
@Retention(RUNTIME)<br />
public @interface ManagedFrameworkAutowire {<br />
/**<br />
* Name of the desired Component<br />
*/<br />
String name() default "";<br />
<br />
/**<br />
* Class of the desired Capability. This attribute works <br />
* in conjunction with the ComposableManagedCapabilitySet<br />
* annotation<br />
*/<br />
Class capability() default Void.class;<br />
}<br />
</pre><br />
<br />
The following annotations (proposed as a way to support the Singleton requirement for CMDBf) can be used for this purpose as well.<br />
<br />
<pre><br />
/**<br />
* Annotation used to indicate a factory method to construct a framework component. <br />
*/<br />
@Target(METHOD)<br />
@Retention(RUNTIME)<br />
public @interface ManagedResourceFactory {<br />
<br />
/**<br />
* If true, indicates that the resource is a singleton, and only the default <br />
* instance may be registered. All other instances attempting to register will<br />
* be rejected <br />
*/<br />
boolean singleton() default false;<br />
<br />
}<br />
</pre><br />
<br />
Binding rules:<br />
<br />
For composable capability set values:<br />
<br />
* check that each set element is annotated as a capability<br />
* check that each set element is composable<br />
* construct the composed capability instances<br />
** if the capability has a designated factory method, use that method to construct the instance<br />
** if the capability does not have a factory method, use the capability's namespace to see if a factory has been registered with the contribution manager (Minor change required to ContributionManager interface). If yes, use that factory to construct the capaiblity instance. Ensure that the instance matches the capability class. If no factory exists, or if the instance is not assignable, fail the bind request.<br />
* Perform any requested autowires. Wiring requests based on class are taken from the composed capability set. Wiring requests based on names are taken from the ContributionManager. <br />
* Ensure that all duplicated capabilities (between composed and interface implementation) share a satisfied wiring target. If a capability is duplicated, but no wiring target exists, fail the binding. The assumption is that the intent is to use the POJO interface to proxy to the delegated implementation. We don't want the POJO invocation and the bound invocation to take different paths through the resource. <br />
* Bind the result to the appropriate managagement binding. The binding needs to ensure that composed capabilities and capabilities based on implemented interfaces are not represented twice (No duplicated Port types!). Bindings should ensure that all calls route to the interface call first, based on the assumption that the interface call will delegate to the autowire target.</div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=COSMOS_Bug_Design_209248&diff=61804COSMOS Bug Design 2092482007-11-16T20:51:28Z<p>Joel.hawkins.compuware.com: </p>
<hr />
<div>The Muse programming model is a composition-oriented model, where capabilities<br />
can be imposed on a resource implementation externally. In the annotations, the<br />
composition model can be supported programatically by creating a single facade<br />
over multiple capability implementations, but the annotations don't provide any<br />
support to make this easier. <br />
<br />
The annotations should provide support for this model in order to<br />
enforce/encourage alignment with the existing Muse programming model.<br />
<br />
<pre><br />
/**<br />
* Annotation used to indicate an interface which to be exposed as a distinct <br />
* management capability. <br />
*/<br />
@Target(TYPE)<br />
@Retention(RUNTIME)<br />
public @interface ManagedResourceCapability {<br />
<br />
/**<br />
* A text description of the capability. <br />
* This attribute is intended for tooling support. <br />
* <br />
*/<br />
String description() default "";<br />
/**<br />
* The namespace of the capability. This namespace will be used for all<br />
* operations and properties exposed by this capability (unless overridden) <br />
* and will uniquely identify the capability when introspecting its resource. <br />
*/<br />
String namespace();<br />
<br />
/**<br />
* Indicates that the annotated implementation may be used in conjunction<br />
* with the ComposableManagedCapabilitySet annotation to implement a <br />
* composite managed resource <br />
*/<br />
boolean composable() default false;<br />
}<br />
</pre><br />
<br />
<pre><br />
<br />
/**<br />
* Annotation used to decorate a ManagedResource with externally implemented capabilities <br />
*/<br />
@Target(TYPE)<br />
@Retention(RUNTIME)<br />
public @interface ComposableManagedCapabilitySet {<br />
<br />
/**<br />
* The set of capability classes to decorate the targeted <br />
* ManagedResource instance with. This annotation works<br />
* in conjunction with the ManagedFrameworkAutowire, <br />
* ManagedResourceCapability, and ManagedResourceFactory <br />
* annotations to enable the framework to replicate the<br />
* delcarative programming model exposed by Muse.xml <br />
*/<br />
Class[] set() default {};<br />
<br />
}<br />
</pre><br />
<br />
<pre><br />
<br />
/**<br />
* Annotation used to support autowiring of <br />
* Components within the management framework.<br />
*/<br />
@Target(FIELD)<br />
@Retention(RUNTIME)<br />
public @interface ManagedFrameworkAutowire {<br />
/**<br />
* Name of the desired Component<br />
*/<br />
String name() default "";<br />
<br />
/**<br />
* Class of the desired Capability. This attribute works <br />
* in conjunction with the ComposableManagedCapabilitySet<br />
* annotation<br />
*/<br />
Class capability() default Void.class;<br />
}<br />
</pre><br />
<br />
The following annotations (proposed as a way to support the Singleton requirement for CMDBf) can be used for this purpose as well.<br />
<br />
<pre><br />
/**<br />
* Annotation used to indicate a factory method to construct a framework component. <br />
*/<br />
@Target(METHOD)<br />
@Retention(RUNTIME)<br />
public @interface ManagedResourceFactory {<br />
<br />
/**<br />
* If true, indicates that the resource is a singleton, and only the default <br />
* instance may be registered. All other instances attempting to register will<br />
* be rejected <br />
*/<br />
boolean singleton() default false;<br />
<br />
}<br />
</pre></div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=COSMOS_Bug_Design_209248&diff=61800COSMOS Bug Design 2092482007-11-16T20:44:08Z<p>Joel.hawkins.compuware.com: </p>
<hr />
<div>The Muse programming model is a composition-oriented model, where capabilities<br />
can be imposed on a resource implementation externally. In the annotations, the<br />
composition model can be supported programatically by creating a single facade<br />
over multiple capability implementations, but the annotations don't provide any<br />
support to make this easier. <br />
<br />
The annotations should provide support for this model in order to<br />
enforce/encourage alignment with the existing Muse programming model.<br />
<br />
<pre><br />
/**<br />
* Annotation used to indicate an interface which to be exposed as a distinct <br />
* management capability. <br />
*/<br />
@Target(TYPE)<br />
@Retention(RUNTIME)<br />
public @interface ManagedResourceCapability {<br />
<br />
/**<br />
* A text description of the capability. <br />
* This attribute is intended for tooling support. <br />
* <br />
*/<br />
String description() default "";<br />
/**<br />
* The namespace of the capability. This namespace will be used for all<br />
* operations and properties exposed by this capability (unless overridden) <br />
* and will uniquely identify the capability when introspecting its resource. <br />
*/<br />
String namespace();<br />
<br />
/**<br />
* Indicates that the annotated implementation may be used in conjunction<br />
* with the ComposableManagedCapabilitySet annotation to implement a <br />
* composite managed resource <br />
*/<br />
boolean composable() default false;<br />
}<br />
</pre><br />
<br />
<pre><br />
<br />
/**<br />
* Annotation used to decorate a ManagedResource with externally implemented capabilities <br />
*/<br />
@Target(TYPE)<br />
@Retention(RUNTIME)<br />
public @interface ComposableManagedCapabilitySet {<br />
<br />
/**<br />
* The set of capability classes to decorate the targeted <br />
* ManagedResource instance with. This annotation works<br />
* in conjunction with the ManagedFrameworkAutowire, <br />
* ManagedResourceCapability, and ManagedResourceFactory <br />
* annotations to enable the framework to replicate the<br />
* delcarative programming model exposed by Muse.xml <br />
*/<br />
Class[] set() default {};<br />
<br />
}<br />
</pre><br />
<br />
<pre><br />
<br />
/**<br />
* Annotation used to support autowiring of <br />
* Components within the management framework.<br />
*/<br />
@Target(FIELD)<br />
@Retention(RUNTIME)<br />
public @interface ManagedFrameworkAutowire {<br />
/**<br />
* Name of the desired Component<br />
*/<br />
String name() default "";<br />
<br />
/**<br />
* Class of the desired Capability. This attribute works <br />
* in conjunction with the ComposableManagedCapabilitySet<br />
* annotation<br />
*/<br />
Class capability() default Void.class;<br />
}<br />
</pre><br />
<br />
<pre><br />
/**<br />
* Annotation used to indicate a class to be exposed as a manageable resource. <br />
*/<br />
@Target(TYPE)<br />
@Retention(RUNTIME)<br />
public @interface ManagedResourceFactory {<br />
<br />
/**<br />
* If true, indicates that the resource is a singleton, and only the default <br />
* instance may be registered. All other instances attempting to register will<br />
* be rejected <br />
*/<br />
boolean singleton() default false;<br />
<br />
}<br />
</pre></div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=COSMOS_Bug_Design_209248&diff=61798COSMOS Bug Design 2092482007-11-16T20:39:26Z<p>Joel.hawkins.compuware.com: </p>
<hr />
<div>The Muse programming model is a composition-oriented model, where capabilities<br />
can be imposed on a resource implementation externally. In the annotations, the<br />
composition model can be supported programatically by creating a single facade<br />
over multiple capability implementations, but the annotations don't provide any<br />
support to make this easier. <br />
<br />
The annotations should provide support for this model in order to<br />
enforce/encourage alignment with the existing Muse programming model.<br />
<br />
<pre><br />
<br />
/**<br />
* Annotation used to decorate a ManagedResource with externally implemented capabilities <br />
*/<br />
@Target(TYPE)<br />
@Retention(RUNTIME)<br />
public @interface ComposableManagedCapabilitySet {<br />
<br />
/**<br />
* The set of capability classes to decorate the targeted <br />
* ManagedResource instance with. This annotation works<br />
* in conjunction with the ManagedFrameworkAutowire, <br />
* ManagedResourceCapability, and ManagedResourceFactory <br />
* annotations to enable the framework to replicate the<br />
* delcarative programming model exposed by Muse.xml <br />
*/<br />
Class[] set() default {};<br />
<br />
}<br />
</pre><br />
<br />
<pre><br />
<br />
/**<br />
* Annotation used to support autowiring of <br />
* Components within the management framework.<br />
*/<br />
@Target(FIELD)<br />
@Retention(RUNTIME)<br />
public @interface ManagedFrameworkAutowire {<br />
/**<br />
* Name of the desired Component<br />
*/<br />
String name() default "";<br />
<br />
/**<br />
* Class of the desired Capability. This attribute works <br />
* in conjunction with the ComposableManagedCapabilitySet<br />
* annotation<br />
*/<br />
Class capability() default Void.class;<br />
}<br />
</pre></div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=COSMOS_Bug_Design_209248&diff=61796COSMOS Bug Design 2092482007-11-16T20:34:20Z<p>Joel.hawkins.compuware.com: </p>
<hr />
<div>The Muse programming model is a composition-oriented model, where capabilities<br />
can be imposed on a resource implementation externally. In the annotations, the<br />
composition model can be supported programatically by creating a single facade<br />
over multiple capability implementations, but the annotations don't provide any<br />
support to make this easier. <br />
<br />
The annotations should provide support for this model in order to<br />
enforce/encourage alignment with the existing Muse programming model.<br />
<br />
<pre><br />
<br />
/**<br />
* Annotation used to support autowiring of <br />
* Components within the management framework.<br />
*/<br />
@Target(FIELD)<br />
@Retention(RUNTIME)<br />
public @interface ManagedFrameworkAutowire {<br />
/**<br />
* Name of the desired Component<br />
*/<br />
String name() default "";<br />
<br />
/**<br />
* Class of the desired Capability. This attribute works <br />
* in conjunction with the ComposableManagedCapabilitySet<br />
* annotation<br />
*/<br />
Class capability() default Void.class;<br />
}<br />
</pre></div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=COSMOS_Bug_Design_209248&diff=60726COSMOS Bug Design 2092482007-11-13T15:41:34Z<p>Joel.hawkins.compuware.com: New page: The Muse programming model is a composition-oriented model, where capabilities can be imposed on a resource implementation externally. In the annotations, the composition model can be supp...</p>
<hr />
<div>The Muse programming model is a composition-oriented model, where capabilities<br />
can be imposed on a resource implementation externally. In the annotations, the<br />
composition model can be supported programatically by creating a single facade<br />
over multiple capability implementations, but the annotations don't provide any<br />
support to make this easier. <br />
<br />
The annotations should provide support for this model in order to<br />
enforce/encourage alignment with the existing Muse programming model.</div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=COSMOS_Bug_Design_209246&diff=60705COSMOS Bug Design 2092462007-11-13T13:34:42Z<p>Joel.hawkins.compuware.com: New page: The CMDBf specification expresses the WebServices interface to an implementation using stateless semantics. COSMOS needs to support this mechanism, while lobbying CMDBf to expand their spe...</p>
<hr />
<div>The CMDBf specification expresses the WebServices interface to an<br />
implementation using stateless semantics. COSMOS needs to support this<br />
mechanism, while lobbying CMDBf to expand their specification to fit into a<br />
capbability-model view of the world.<br />
<br />
This can be handled in the annotations by tagging a static factory-type method<br />
(like static <T> getInstance()) as the implementation of a singleton-semantic<br />
instance.<br />
<br />
<br />
A @ManagedResourceFactory annotation will be created to tag a factory method within a class. The factory method must be static and take no arguments. This factory may optionally be designated as a singleton. <br />
<br />
<pre><br />
/*<br />
* Copyright (c) 2005-2007 Compuware Corporation and others.<br />
* All rights reserved. This program and the accompanying<br />
* materials are made available under the terms of the<br />
* Eclipse Public License v1.0 which accompanies this<br />
* distribution, and is available at:<br />
* http://www.eclipse.org/legal/epl-v10.html<br />
*<br />
* Contributors:<br />
* Compuware Corporation - initial API and implementation<br />
*<br />
*/<br />
package org.eclipse.cosmos.dc.mgmt.annotations;<br />
<br />
import static java.lang.annotation.ElementType.TYPE;<br />
import static java.lang.annotation.RetentionPolicy.RUNTIME;<br />
<br />
import java.lang.annotation.Retention;<br />
import java.lang.annotation.Target;<br />
<br />
/**<br />
* Annotation used to indicate a class to be exposed as a manageable resource. <br />
*/<br />
@Target(TYPE)<br />
@Retention(RUNTIME)<br />
public @interface ManagedResourceFactory {<br />
<br />
/**<br />
* If true, indicates that the resource is a singleton, and only the default <br />
* instance may be registered. All other instances attempting to register will<br />
* be rejected <br />
*/<br />
boolean singleton() default false;<br />
<br />
}<br />
</pre><br />
<br />
This mechanism will allow COSMOS to support the use case envisioned in this bug, and also provide a mechanism for constructing and initializing instances based on RMD. <br />
<br />
The ContributionManager interface will be extended to allow class-based registration, so that singleton creation and enforcement can be delegated to the runtime:<br />
<br />
<pre><br />
Object manage(Class clazz);<br />
<br />
</pre><br />
<br />
The required changes to integrate with Muse have not been scoped yet. More to come...</div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=COSMOS_Bug_Design_209244&diff=60704COSMOS Bug Design 2092442007-11-13T13:17:28Z<p>Joel.hawkins.compuware.com: New page: For annotated classes, there are cases where the implementation needs addressability to underyling management implementations. For example, there is a need for a managed resource to be abl...</p>
<hr />
<div>For annotated classes, there are cases where the implementation needs<br />
addressability to underyling management implementations. For example, there is<br />
a need for a managed resource to be able to access it's WSDM EPR. <br />
<br />
In the current implementation, each management techonolgy (JMX, WSDM, etc.)<br />
corresponds to an existing binding implementation. There is also a mechanism<br />
that allows the annotation framework to bind references within an<br />
implementation class. This mechanism could be used to wire in access to the set<br />
of binding technologies that the annotated class is exposed thruough. Each of<br />
these binding types could then be cast to technology-specific interfaces.<br />
<br />
This functionality is currently supported using the @ManagedFrameworkAutowire annotation.<br />
<br />
<pre><br />
/*<br />
* Copyright (c) 2005-2007 Compuware Corporation and others.<br />
* All rights reserved. This program and the accompanying<br />
* materials are made available under the terms of the<br />
* Eclipse Public License v1.0 which accompanies this<br />
* distribution, and is available at:<br />
* http://www.eclipse.org/legal/epl-v10.html<br />
*<br />
* Contributors:<br />
* Compuware Corporation - initial API and implementation<br />
*<br />
*/<br />
package org.eclipse.cosmos.dc.mgmt.annotations;<br />
<br />
import static java.lang.annotation.RetentionPolicy.RUNTIME;<br />
import static java.lang.annotation.ElementType.FIELD;<br />
<br />
import java.lang.annotation.Retention;<br />
import java.lang.annotation.Target;<br />
<br />
/**<br />
* Annotation used to support autowiring of Components within the management framework.<br />
*/<br />
@Target(FIELD)<br />
@Retention(RUNTIME)<br />
public @interface ManagedFrameworkAutowire {<br />
/**<br />
* Name of the desired Component<br />
*/<br />
String name();<br />
}<br />
<br />
</pre><br />
<br />
This annotation allows the framework to 'wire in' references to various components. Currently, the framework only exposes Binding implementations ("WSDM"), but additional components can be exposed using the addAutowireTarget method using the ContributionManger instance. <br />
<br />
An example of how to resolve an Endpoint for an managed object can be found in the <code>org.eclipse.cosmos.dc.sample.components.source.WefSource</code> class. Some excerpts are provided below:<br />
<br />
Provide a setter method for the wiring mechanism to use.<br />
<pre><br />
@ManagedFrameworkAutowire(name="WSDM")<br />
private Binding wsdmBinding;<br />
<br />
public void setWsdmBinding(Binding wsdmBinding){<br />
this.wsdmBinding = wsdmBinding;<br />
<br />
}<br />
</pre><br />
<br />
Using the Wired binding to access the EndpointReference<br />
<pre><br />
... code removed for clarity<br />
Object consumerObject = wsdmBinding.getBindingForObject(this);<br />
if(consumerObject != null && consumerObject instanceof WsResource){<br />
EndpointReference consumer = ((WsResource)consumerObject).getEndpointReference();<br />
... code removed for clarity<br />
</pre></div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=COSMOSAnnotationsRoadmapPage&diff=60701COSMOSAnnotationsRoadmapPage2007-11-13T13:03:15Z<p>Joel.hawkins.compuware.com: /* Requirements */</p>
<hr />
<div>== Requirements ==<br />
#Support J2EE environment<br />
#Need a way to access resource manager from resource class<br />
#Ability to control which standard capabilities to include in the resource<br />
#mgmt.wsdm and mgmt.common bundles should not depend on other cosmos bundles.<br />
#Need to have an easy client story<br />
#Need to have the ability to take a "generic" web services call. For example, the CMDBf web services calls will not have the addressing context.<br />
#Must be able to support service groups<br />
<br />
http://wiki.eclipse.org/WSDMProgrammingModel<br />
<br />
TODOs:<br />
<br />
1. Compare JAX-WS annotations processing with how we do annotations processing (all)<br />
<br />
2. Document feature.xml usage to do server-side osgi configuration to help Hubert's ManagementBroker work. (Dennis is the resident expert here). (Denis to provide documentation on wiki.)<br />
<br />
ERs: (Target these for i8 - with the possible exception of ServiceGroups and tooling)<br />
<br />
1. [https://bugs.eclipse.org/bugs/show_bug.cgi?id=209331 Get J2ee support working]. Tomcat with Axis2 as target. (Hubert's top)<br />
<br />
2. [https://bugs.eclipse.org/bugs/show_bug.cgi?id=209244 Expose the ManagementBindingProvider] to annotated class. This will allow annotated classes to access things like the WSDM EPR. [[COSMOS_Bug_Design_209244 | Design]]<br />
<br />
3. [https://bugs.eclipse.org/bugs/show_bug.cgi?id=209248 Work out the Delegation/Composition Model]. Needs to be able to specify implementations and support defaults (existing muse). [[COSMOS_Bug_Design_209248 | Design]]<br />
<br />
4. [https://bugs.eclipse.org/bugs/show_bug.cgi?id=209269 Create 'standard' interfaces for default capabilities]. (OperationalStatus, etc.).[[COSMOS_Bug_Design_209269 | Design]]<br />
<br />
<br />
5. [https://bugs.eclipse.org/bugs/show_bug.cgi?id=209246 Add a notion of 'default instance'] to support Balan's hack. We'll probably provide an annotation to designate a static factory method as the 'default instance' provider. (Mark's top - to support CMDBf) - for addressing the requirement of supporting generic web service clients. [[COSMOS_Bug_Design_209246 | Design]]<br />
<br />
<br />
6. Add annotation for ServiceGroups.<br />
<br />
7. Better RMD support.<br />
<br />
8. Tooling support</div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=COSMOSAnnotationsRoadmapPage&diff=60181COSMOSAnnotationsRoadmapPage2007-11-09T14:02:03Z<p>Joel.hawkins.compuware.com: /* Requirements */</p>
<hr />
<div>== Requirements ==<br />
#Support J2EE environment<br />
#Need a way to access resource manager from resource class<br />
#Ability to control which standard capabilities to include in the resource<br />
#mgmt.wsdm and mgmt.common bundles should not depend on other cosmos bundles.<br />
#Need to have an easy client story<br />
#Need to have the ability to take a "generic" web services call. For example, the CMDBf web services calls will not have the addressing context.<br />
#Must be able to support service groups<br />
<br />
http://wiki.eclipse.org/WSDMProgrammingModel<br />
<br />
TODOs:<br />
<br />
1. Compare JAX-WS annotations processing with how we do annotations processing (all)<br />
<br />
2. Document feature.xml usage to do server-side osgi configuration to help Hubert's ManagementBroker work. (Dennis is the resident expert here). (Denis to provide documentation on wiki.)<br />
<br />
ERs: (Target these for i8 - with the possible exception of ServiceGroups and tooling)<br />
<br />
1. [https://bugs.eclipse.org/bugs/show_bug.cgi?id=209331 Get J2ee support working]. Tomcat with Axis2 as target. (Hubert's top)<br />
<br />
2. [https://bugs.eclipse.org/bugs/show_bug.cgi?id=209244 Expose the ManagementBindingProvider] to annotated class. This will allow annotated classes to access things like the WSDM EPR.<br />
<br />
3. [https://bugs.eclipse.org/bugs/show_bug.cgi?id=209248 Work out the Delegation/Composition Model]. Needs to be able to specify implementations and support defaults (existing muse)<br />
<br />
4. [https://bugs.eclipse.org/bugs/show_bug.cgi?id=209269 Create 'standard' interfaces for default capabilities]. (OperationalStatus, etc.).<br />
<br />
5. [https://bugs.eclipse.org/bugs/show_bug.cgi?id=209246 Add a notion of 'default instance'] to support Balan's hack. We'll probably provide an annotation to designate a static factory method as the 'default instance' provider. (Mark's top - to support CMDBf) - for addressing the requirement of supporting generic web service clients. <br />
<br />
6. Add annotation for ServiceGroups.<br />
<br />
7. Better RMD support.<br />
<br />
8. Tooling support</div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=COSMOSAnnotationsRoadmapPage&diff=60117COSMOSAnnotationsRoadmapPage2007-11-08T21:13:54Z<p>Joel.hawkins.compuware.com: /* Requirements */</p>
<hr />
<div>== Requirements ==<br />
#Support J2EE environment<br />
#Need a way to access resource manager from resource class<br />
#Ability to control which standard capabilities to include in the resource<br />
#mgmt.wsdm and mgmt.common bundles should not depend on other cosmos bundles.<br />
#Need to have an easy client story<br />
#Need to have the ability to take a "generic" web services call. For example, the CMDBf web services calls will not have the addressing context.<br />
#Must be able to support service groups<br />
<br />
http://wiki.eclipse.org/WSDMProgrammingModel<br />
<br />
TODOs:<br />
<br />
1. Compare JAX-WS annotations processing with how we do annotations processing (all)<br />
<br />
2. Document feature.xml usage to do server-side osgi configuration to help Hubert's ManagementBroker work. (Dennis is the resident expert here). (Denis to provide documentation on wiki.)<br />
<br />
ERs: (Target these for i8 - with the possible exception of ServiceGroups and tooling)<br />
<br />
1. Get J2ee support working. Tomcat with Axis2 as target. (Hubert's top)<br />
<br />
2. [https://bugs.eclipse.org/bugs/show_bug.cgi?id=209244 Expose the ManagementBindingProvider] to annotated class. This will allow annotated classes to access things like the WSDM EPR.<br />
<br />
3. [https://bugs.eclipse.org/bugs/show_bug.cgi?id=209248 Work out the Delegation/Composition Model]. Needs to be able to specify implementations and support defaults (existing muse)<br />
<br />
4. [https://bugs.eclipse.org/bugs/show_bug.cgi?id=209269 Create 'standard' interfaces for default capabilities]. (OperationalStatus, etc.).<br />
<br />
5. [https://bugs.eclipse.org/bugs/show_bug.cgi?id=209246 Add a notion of 'default instance'] to support Balan's hack. We'll probably provide an annotation to designate a static factory method as the 'default instance' provider. (Mark's top - to support CMDBf) - for addressing the requirement of supporting generic web service clients. <br />
<br />
6. Add annotation for ServiceGroups.<br />
<br />
7. Better RMD support.<br />
<br />
8. Tooling support</div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=COSMOSAnnotationsRoadmapPage&diff=60087COSMOSAnnotationsRoadmapPage2007-11-08T19:49:24Z<p>Joel.hawkins.compuware.com: /* Requirements */</p>
<hr />
<div>== Requirements ==<br />
#Support J2EE environment<br />
#Need a way to access resource manager from resource class<br />
#Ability to control which standard capabilities to include in the resource<br />
#mgmt.wsdm and mgmt.common bundles should not depend on other cosmos bundles.<br />
#Need to have an easy client story<br />
#Need to have the ability to take a "generic" web services call. For example, the CMDBf web services calls will not have the addressing context.<br />
#Must be able to support service groups<br />
<br />
http://wiki.eclipse.org/WSDMProgrammingModel<br />
<br />
TODOs:<br />
<br />
1. Compare JAX-WS annotations processing with how we do annotations processing (all)<br />
<br />
2. Document feature.xml usage to do server-side osgi configuration to help Hubert's ManagementBroker work. (Dennis is the resident expert here). (Denis to provide documentation on wiki.)<br />
<br />
ERs: (Target these for i8 - with the possible exception of ServiceGroups and tooling)<br />
<br />
1. Get J2ee support working. Tomcat with Axis2 as target. (Hubert's top)<br />
<br />
2. [https://bugs.eclipse.org/bugs/show_bug.cgi?id=209244 Expose the ManagementBindingProvider] to annotated class. This will allow annotated classes to access things like the WSDM EPR.<br />
<br />
3. [https://bugs.eclipse.org/bugs/show_bug.cgi?id=209248 Work out the Delegation/Composition Model]. Needs to be able to specify implementations and support defaults (existing muse)<br />
<br />
4. Create 'standard' interfaces for default capabilities. (OperationalStatus, etc.).<br />
<br />
5. [https://bugs.eclipse.org/bugs/show_bug.cgi?id=209246 Add a notion of 'default instance'] to support Balan's hack. We'll probably provide an annotation to designate a static factory method as the 'default instance' provider. (Mark's top - to support CMDBf) - for addressing the requirement of supporting generic web service clients. <br />
<br />
6. Add annotation for ServiceGroups.<br />
<br />
7. Better RMD support.<br />
<br />
8. Tooling support</div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=COSMOSAnnotationsRoadmapPage&diff=60082COSMOSAnnotationsRoadmapPage2007-11-08T19:39:57Z<p>Joel.hawkins.compuware.com: /* Requirements */</p>
<hr />
<div>== Requirements ==<br />
#Support J2EE environment<br />
#Need a way to access resource manager from resource class<br />
#Ability to control which standard capabilities to include in the resource<br />
#mgmt.wsdm and mgmt.common bundles should not depend on other cosmos bundles.<br />
#Need to have an easy client story<br />
#Need to have the ability to take a "generic" web services call. For example, the CMDBf web services calls will not have the addressing context.<br />
#Must be able to support service groups<br />
<br />
http://wiki.eclipse.org/WSDMProgrammingModel<br />
<br />
TODOs:<br />
<br />
1. Compare JAX-WS annotations processing with how we do annotations processing (all)<br />
<br />
2. Document feature.xml usage to do server-side osgi configuration to help Hubert's ManagementBroker work. (Dennis is the resident expert here). (Denis to provide documentation on wiki.)<br />
<br />
ERs: (Target these for i8 - with the possible exception of ServiceGroups and tooling)<br />
<br />
1. Get J2ee support working. Tomcat with Axis2 as target. (Hubert's top)<br />
<br />
2. [https://bugs.eclipse.org/bugs/show_bug.cgi?id=209244 Expose the ManagementBindingProvider] to annotated class. This will allow annotated classes to access things like the WSDM EPR.<br />
<br />
3. Work out the Delegation/Composition Model. Needs to be able to specify implementations and support defaults (existing muse)<br />
<br />
4. Create 'standard' interfaces for default capabilities. (OperationalStatus, etc.).<br />
<br />
5. [https://bugs.eclipse.org/bugs/show_bug.cgi?id=209246 Add a notion of 'default instance'] to support Balan's hack. We'll probably provide an annotation to designate a static factory method as the 'default instance' provider. (Mark's top - to support CMDBf) - for addressing the requirement of supporting generic web service clients. <br />
<br />
6. Add annotation for ServiceGroups.<br />
<br />
7. Better RMD support.<br />
<br />
8. Tooling support</div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=COSMOSAnnotationsRoadmapPage&diff=60076COSMOSAnnotationsRoadmapPage2007-11-08T19:31:41Z<p>Joel.hawkins.compuware.com: /* Requirements */</p>
<hr />
<div>== Requirements ==<br />
#Support J2EE environment<br />
#Need a way to access resource manager from resource class<br />
#Ability to control which standard capabilities to include in the resource<br />
#mgmt.wsdm and mgmt.common bundles should not depend on other cosmos bundles.<br />
#Need to have an easy client story<br />
#Need to have the ability to take a "generic" web services call. For example, the CMDBf web services calls will not have the addressing context.<br />
#Must be able to support service groups<br />
<br />
http://wiki.eclipse.org/WSDMProgrammingModel<br />
<br />
TODOs:<br />
<br />
1. Compare JAX-WS annotations processing with how we do annotations processing (all)<br />
<br />
2. Document feature.xml usage to do server-side osgi configuration to help Hubert's ManagementBroker work. (Dennis is the resident expert here). (Denis to provide documentation on wiki.)<br />
<br />
ERs: (Target these for i8 - with the possible exception of ServiceGroups and tooling)<br />
<br />
1. Get J2ee support working. Tomcat with Axis2 as target. (Hubert's top)<br />
<br />
2. [https://bugs.eclipse.org/bugs/show_bug.cgi?id=209244 Expose the ManagementBindingProvider] to annotated class. This will allow annotated classes to access things like the WSDM EPR.<br />
<br />
3. Work out the Delegation/Composition Model. Needs to be able to specify implementations and support defaults (existing muse)<br />
<br />
4. Create 'standard' interfaces for default capabilities. (OperationalStatus, etc.).<br />
<br />
5. Add a notion of 'default instance' to support Balan's hack. We'll probably provide an annotation to designate a static factory method as the 'default instance' provider. (Mark's top - to support CMDBf) - for addressing the requirement of supporting generic web service clients. <br />
<br />
6. Add annotation for ServiceGroups.<br />
<br />
7. Better RMD support.<br />
<br />
8. Tooling support</div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=COSMOSAnnotationsRoadmapPage&diff=60069COSMOSAnnotationsRoadmapPage2007-11-08T18:44:48Z<p>Joel.hawkins.compuware.com: /* Requirements */</p>
<hr />
<div>== Requirements ==<br />
#Support J2EE environment<br />
#Need a way to access resource manager from resource class<br />
#Ability to control which standard capabilities to include in the resource<br />
#mgmt.wsdm and mgmt.common bundles should not depend on other cosmos bundles.<br />
#Need to have an easy client story<br />
#Need to have the ability to take a "generic" web services call. For example, the CMDBf web services calls will not have the addressing context.<br />
#Must be able to support service groups<br />
<br />
http://wiki.eclipse.org/WSDMProgrammingModel<br />
<br />
TODOs:<br />
<br />
1. Compare JAX-WS annotations processing with how we do annotations processing<br />
<br />
2. Get current annotations support working in J2EE environment<br />
<br />
3. Document feature.xml usage to do server-side osgi configuration to help Hubert's ManagementBroker work. (Dennis is the resident expert here).<br />
<br />
ERs: (Target these for i8 - with the possible exception of ServiceGroups)<br />
<br />
1. Get J2ee support working. Tomcat with Axis2 as target. (Hubert's top)<br />
<br />
2. Expose the ManagementBindingProvider to annotated class (ability to get EPR, etc.) (Hubert's other top)<br />
<br />
3. Work out the Delegation/Composition Model. Needs to be able to specify implementations and support defaults (existing muse)<br />
<br />
4. Create 'standard' interfaces for default capabilities. (OperationalStatus, etc.).<br />
<br />
5. Add a notion of 'default instance' to support Balan's hack. We'll probably provide an annotation to designate a static factory method as the 'default instance' provider. (Mark's top - to support CMDBf)<br />
<br />
6. Add annotation for ServiceGroups.<br />
<br />
7. Better RMD support.</div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=COSMOSAnnotationsRoadmapPage&diff=60067COSMOSAnnotationsRoadmapPage2007-11-08T18:42:09Z<p>Joel.hawkins.compuware.com: /* Requirements */</p>
<hr />
<div>== Requirements ==<br />
#Support J2EE environment<br />
#Need a way to access resource manager from resource class<br />
#Ability to control which standard capabilities to include in the resource<br />
#mgmt.wsdm and mgmt.common bundles should not depend on other cosmos bundles.<br />
#Need to have an easy client story<br />
#Need to have the ability to take a "generic" web services call. For example, the CMDBf web services calls will not have the addressing context.<br />
#Must be able to support service groups<br />
<br />
http://wiki.eclipse.org/WSDMProgrammingModel<br />
<br />
TODOs:<br />
<br />
1. Compare JAX-WS annotations processing with how we do annotations processing<br />
<br />
2. Get current annotations support working in J2EE environment<br />
<br />
3. Document feature.xml usage to do server-side osgi configuration to help Hubert's ManagementBroker work. (Dennis is the resident expert here).<br />
<br />
ERs: (Target these for i8 - with the possible exception of ServiceGroups)<br />
<br />
1. Get J2ee support working. Tomcat with Axis2 as target. (Hubert's top)<br />
<br />
2. Expose the ManagementBindingProvider to annotated class (ability to get EPR, etc.) (Hubert's other top)<br />
<br />
3. Work out the Delegation/Composition Model. Needs to be able to specify implementations and support defaults (existing muse)<br />
<br />
4. Create 'standard' interfaces for default capabilities. (OperationalStatus, etc.).<br />
<br />
5. Add a notion of 'default instance' to support Balan's hack. We'll probably provide an annotation to designate a static factory method as the 'default instance' provider. (Mark's top - to support CMDBf)<br />
<br />
6. Add annotation for ServiceGroups.</div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=COSMOSAnnotationsRoadmapPage&diff=60066COSMOSAnnotationsRoadmapPage2007-11-08T18:40:42Z<p>Joel.hawkins.compuware.com: /* Requirements */</p>
<hr />
<div>== Requirements ==<br />
#Support J2EE environment<br />
#Need a way to access resource manager from resource class<br />
#Ability to control which standard capabilities to include in the resource<br />
#mgmt.wsdm and mgmt.common bundles should not depend on other cosmos bundles.<br />
#Need to have an easy client story<br />
#Need to have the ability to take a "generic" web services call. For example, the CMDBf web services calls will not have the addressing context.<br />
#Must be able to support service groups<br />
<br />
http://wiki.eclipse.org/WSDMProgrammingModel<br />
<br />
TODOs:<br />
<br />
1. Compare JAX-WS annotations processing with how we do annotations processing<br />
<br />
2. Get current annotations support working in J2EE environment<br />
<br />
3. Document feature.xml usage to do server-side osgi configuration to help Hubert's ManagementBroker work. (Dennis is the resident expert here).<br />
<br />
ERs:<br />
<br />
1. Get J2ee support working. Tomcat with Axis2 as target. (Hubert's top)<br />
<br />
2. Expose the ManagementBindingProvider to annotated class (ability to get EPR, etc.) (Hubert's other top)<br />
<br />
3. Work out the Delegation/Composition Model. Needs to be able to specify implementations and support defaults (existing muse)<br />
<br />
4. Create 'standard' interfaces for default capabilities. (OperationalStatus, etc.).<br />
<br />
5. Add a notion of 'default instance' to support Balan's hack. We'll probably provide an annotation to designate a static factory method as the 'default instance' provider. (Mark's top - to support CMDBf)<br />
<br />
6. Add annotation for ServiceGroups.</div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=COSMOSAnnotationsRoadmapPage&diff=60065COSMOSAnnotationsRoadmapPage2007-11-08T18:39:01Z<p>Joel.hawkins.compuware.com: /* Requirements */</p>
<hr />
<div>== Requirements ==<br />
#Support J2EE environment<br />
#Need a way to access resource manager from resource class<br />
#Ability to control which standard capabilities to include in the resource<br />
#mgmt.wsdm and mgmt.common bundles should not depend on other cosmos bundles.<br />
#Need to have an easy client story<br />
#Need to have the ability to take a "generic" web services call. For example, the CMDBf web services calls will not have the addressing context.<br />
#Must be able to support service groups<br />
<br />
http://wiki.eclipse.org/WSDMProgrammingModel<br />
<br />
TODOs:<br />
1. Compare JAX-WS annotations processing with how we do annotations processing<br />
<br />
2. Get current annotations support working in J2EE environment<br />
<br />
3. Document feature.xml usage to do server-side osgi configuration to help Hubert's ManagementBroker work. (Dennis is the resident expert here).<br />
<br />
ERs:<br />
<br />
1. Get J2ee support working. Tomcat with Axis2 as target. (Hubert's top)<br />
<br />
2. Expose the ManagementBindingProvider to annotated class (ability to get EPR, etc.) (Hubert's other top)<br />
<br />
3. Work out the Delegation/Composition Model. Needs to be able to specify implementations and support defaults (existing muse)<br />
<br />
4. Create 'standard' interfaces for default capabilities. (OperationalStatus, etc.).<br />
<br />
5. Add a notion of 'default instance' to support Balan's hack. We'll probably provide an annotation to designate a static factory method as the 'default instance' provider. (Mark's top - to support CMDBf)<br />
<br />
6. Add annotation for ServiceGroups.</div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=COSMOSAnnotationsRoadmapPage&diff=60064COSMOSAnnotationsRoadmapPage2007-11-08T18:29:25Z<p>Joel.hawkins.compuware.com: /* Requirements */</p>
<hr />
<div>== Requirements ==<br />
#Support J2EE environment<br />
#Need a way to access resource manager from resource class<br />
#Ability to control which standard capabilities to include in the resource<br />
#mgmt.wsdm and mgmt.common bundles should not depend on other cosmos bundles.<br />
#Need to have an easy client story<br />
#Need to have the ability to take a "generic" web services call. For example, the CMDBf web services calls will not have the addressing context.<br />
#Must be able to support service groups<br />
<br />
http://wiki.eclipse.org/WSDMProgrammingModel<br />
<br />
TODOs:<br />
1. Compare JAX-WS annotations processing with how we do annotations processing<br />
<br />
2. Get current annotations support working in J2EE environment<br />
<br />
3.<br />
<br />
ERs:<br />
<br />
1. Get J2ee support working. Tomcat with Axis2 as target. (Hubert's top)<br />
<br />
2. Expose the ManagementBindingProvider to annotated class (ability to get EPR, etc.) (Hubert's other top)<br />
<br />
3. Work out the Delegation/Composition Model. Needs to be able to specify implementations and support defaults (existing muse)<br />
<br />
4. Create 'standard' interfaces for default capabilities. (OperationalStatus, etc.).<br />
<br />
5. Add a notion of 'default instance' to support Balan's hack. We'll probably provide an annotation to designate a static factory method as the 'default instance' provider. (Mark's top - to support CMDBf)<br />
<br />
6. Add annotation for ServiceGroups.</div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=COSMOSAnnotationsRoadmapPage&diff=60062COSMOSAnnotationsRoadmapPage2007-11-08T18:25:43Z<p>Joel.hawkins.compuware.com: /* Requirements */</p>
<hr />
<div>== Requirements ==<br />
#Support J2EE environment<br />
#Need a way to access resource manager from resource class<br />
#Ability to control which standard capabilities to include in the resource<br />
#mgmt.wsdm and mgmt.common bundles should not depend on other cosmos bundles.<br />
#Need to have an easy client story<br />
#Need to have the ability to take a "generic" web services call. For example, the CMDBf web services calls will not have the addressing context.<br />
#Must be able to support service groups<br />
<br />
http://wiki.eclipse.org/WSDMProgrammingModel<br />
<br />
TODOs:<br />
1. Compare JAX-WS annotations processing with how we do annotations processing<br />
<br />
2. Get current annotations support working in J2EE environment<br />
<br />
3.<br />
<br />
ERs:<br />
<br />
1. Get J2ee support working. Tomcat with Axis2 as target. <br />
<br />
2. Expose the ManagementBindingProvider to annotated class (ability to get EPR, etc.)<br />
<br />
3. Work out the Delegation/Composition Model. Needs to be able to specify implementations and support defaults (existing muse)<br />
<br />
4. Create 'standard' interfaces for default capabilities. (OperationalStatus, etc.).<br />
<br />
5. Add a notion of 'default instance' to support Balan's hack. We'll probably provide an annotation to designate a static factory method as the 'default instance' provider.<br />
<br />
6. Add annotation for ServiceGroups.</div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=COSMOSAnnotationsRoadmapPage&diff=60061COSMOSAnnotationsRoadmapPage2007-11-08T18:21:30Z<p>Joel.hawkins.compuware.com: /* Requirements */</p>
<hr />
<div>== Requirements ==<br />
#Support J2EE environment<br />
#Need a way to access resource manager from resource class<br />
#Ability to control which standard capabilities to include in the resource<br />
#mgmt.wsdm and mgmt.common bundles should not depend on other cosmos bundles.<br />
#Need to have an easy client story<br />
#Need to have the ability to take a "generic" web services call. For example, the CMDBf web services calls will not have the addressing context.<br />
#Must be able to support service groups<br />
<br />
http://wiki.eclipse.org/WSDMProgrammingModel<br />
<br />
TODOs:<br />
1. Compare JAX-WS annotations processing with how we do annotations processing<br />
<br />
2. Get current annotations support working in J2EE environment<br />
<br />
3.<br />
<br />
ERs:<br />
<br />
1. Get J2ee support working. Tomcat with Axis2 as target. <br />
<br />
2. Expose the ManagementBindingProvider to annotated class (ability to get EPR, etc.)<br />
<br />
3. Work out the Delegation/Composition Model. Needs to be able to specify implementations and support defaults (existing muse)<br />
<br />
4. Create 'standard' interfaces for default capabilities. (OperationalStatus, etc.).<br />
<br />
5. Add a notion of 'default instance' to support Balan's hack. We'll probably provide an annotation to designate a static factory method as the 'default instance' provider.</div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=COSMOSAnnotationsRoadmapPage&diff=60060COSMOSAnnotationsRoadmapPage2007-11-08T18:10:52Z<p>Joel.hawkins.compuware.com: /* Requirements */</p>
<hr />
<div>== Requirements ==<br />
#Support J2EE environment<br />
#Need a way to access resource manager from resource class<br />
#Ability to control which standard capabilities to include in the resource<br />
#mgmt.wsdm and mgmt.common bundles should not depend on other cosmos bundles.<br />
#Need to have an easy client story<br />
#Need to have the ability to take a "generic" web services call. For example, the CMDBf web services calls will not have the addressing context.<br />
#Must be able to support service groups<br />
<br />
http://wiki.eclipse.org/WSDMProgrammingModel<br />
<br />
TODOs:<br />
1. Compare JAX-WS annotations processing with how we do annotations processing<br />
<br />
2. Get current annotations support working in J2EE environment<br />
<br />
3.<br />
<br />
ERs:<br />
<br />
1. Get J2ee support working. Tomcat with Axis2 as target. <br />
<br />
2. Expose the ManagementBindingProvider to annotated class (ability to get EPR, etc.)<br />
<br />
3. Work out the Delegation/Composition Model. Needs to be able to specify implementations and support defaults (existing muse)<br />
<br />
4. Create 'standard' interfaces for default capabilities. (OperationalStatus, etc.).</div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=COSMOSF2F-08-Nov-07&diff=60012COSMOSF2F-08-Nov-072007-11-08T15:09:58Z<p>Joel.hawkins.compuware.com: /* Preliminary Agenda - Please feel free to make improvements */</p>
<hr />
<div>== Logistics ==<br />
<br />
:Anyone who wants to have a scheduled conference call for a particular time slot, please add a note in that portion of the agenda. We will use the same number as the weekly Data Collection call.<br />
<br />
:Toll-free Dial-in number: +1 (866) 213.1962 <br />
:Primary International Dial-in: +1.609.454.9912 <br />
:Passcode: 2025533# <br />
<br />
:If you need to contact the group at a time when the confrence call is not active, call the main Compuware number (313) 227-7300 and ask for conference room 14W-4216.<br />
<br />
:Location<br />
::Compuware Corp<br />
::One Campus Martius<br />
::Detroit, MI, USA 48226: Nov 7-9<br />
::Main phone 313 227-7300<br />
::Our meeting room 14W-4216 313.227.7300 x79742<br />
::<br />
::Visitor passes are issued at the Concierge desk near the main entrance.<br />
::Security will direct you to the Visitor Center on the eighth floor of the Woodward wing.<br />
::<br />
::Parking is available in the Compuware ramp. Take a ticket at the public entrance on Farmer street. Tickets can be validated at the Visitor Center for free exit from the parking ramp.<br />
:<br />
::Nearest hotel - easy walking distance - two blocks from Compuware<br />
:::Hilton Garden Inn Detroit Downtown<br />
:::351 Gratiot Avenue, Detroit, Michigan, USA 48226 <br />
:::Tel: +1-313-967-0900 Fax: +1-313-967-0908 <br />
:::[[http://www.hiltongardeninn.com/en/gi/hotels/index.jhtml?ctyhocn=DETDHGI map]]<br />
:<br />
::Nearest airport - DTW (see map for driving directions to Compuware) and locations of HQ and parking ramp.[[http://wiki.eclipse.org/images/5/50/CPWR_DTW_Map.pdf link]]<br />
:<br />
:Proposed schedule 10AM-6PM daily.<br />
::Non-critical items will be scheduled after 3PM Friday for the convenience of those who must leave early.<br />
<br />
:Anyone who wants to have a scheduled conference call for a particular time slot, please add a note in that portion of the agenda. We will use the same number as the weekly Data Collection call.<br />
:If you need to contact the group, call the main Compuware number (313) 227-7300 and ask for conference room 14W-4216.<br />
<br />
<br />
[[Talk:COSMOSF2F-08-Nov-07|Minutes are on the Talk Page]]<br />
<br />
== Preliminary Agenda - Please feel free to make improvements ==<br />
<br />
1. Collection of data--northbound interfaces - Wednesday 8:00 AM<br />
* What resources should we target?<br />
* How to monitor COSMOS itself?<br />
** [[COSMOS internal logging use cases]]<br />
<br />
<br />
<br />
2. Ensure that all the designs for i7 / i8 / i9 are in order - Wednesday 10:00 AM<br />
* Ensure that we agree on the delineation between the MDRs and the Broker; and the exact role of the Management Domain.<br />
<br />
'''Note:''' [[Image:Icon_checkmark.gif#file]] indicates the item has been discussed<br />
* [[COSMOS_Design_205658]] Extend the initial design and implementation of COSMOS DC Management Domain [[Image:Icon_checkmark.gif#file]]<br />
* [[COSMOS_Design_204921]] Extend the initial design and implementation of COSMOS DC Broker [[Image:Icon_checkmark.gif#file]]<br />
* https://bugs.eclipse.org/bugs/show_bug.cgi?id=188390 Support for Nagios agents in data collection [[Image:Icon_checkmark.gif#file]]<br />
* https://bugs.eclipse.org/bugs/show_bug.cgi?id=208100 Create a transformation engine that is able to process CMDBf queries based on a reconciliation taxonomy scheme [[Image:Icon_checkmark.gif#file]]<br />
* [[COSMOS_Design_208274]] Create an MDR toolkit that will allow adopters to easily register and use a data provider inside COSMOS framework [[Image:Icon_checkmark.gif#file]]<br />
* https://bugs.eclipse.org/bugs/show_bug.cgi?id=205826 Update DataCenter model based on latest SML changes [[Image:Icon_checkmark.gif#file]]<br />
* https://bugs.eclipse.org/bugs/show_bug.cgi?id=205956 SML validator should provide API for accessing the model [[Image:Icon_checkmark.gif#file]]<br />
* https://bugs.eclipse.org/bugs/show_bug.cgi?id=205960 SML Data Center repository should be dynamically populated [[Image:Icon_checkmark.gif#file]]<br />
* https://bugs.eclipse.org/bugs/show_bug.cgi?id=205825 Update SML validator implementation based on changes to the SML latest draft [[Image:Icon_checkmark.gif#file]]<br />
* https://bugs.eclipse.org/bugs/show_bug.cgi?id=208584 Update CMDBf query and registration service implementations to 1.0 spec level [[Image:Icon_checkmark.gif#file]]<br />
* https://bugs.eclipse.org/bugs/show_bug.cgi?id=208976 Data Manager and MDR framework [[Image:Icon_checkmark.gif#file]]<br />
* https://bugs.eclipse.org/bugs/show_bug.cgi?id=208592 Error Handling - improve programming model [[Image:Icon_checkmark.gif#file]]<br />
* https://bugs.eclipse.org/bugs/show_bug.cgi?id=208593 Internationalization Support - programming model [[Image:Icon_checkmark.gif#file]]<br />
* https://bugs.eclipse.org/bugs/show_bug.cgi?id=208595 Register Queries with Visualization - programming model<br />
* https://bugs.eclipse.org/bugs/show_bug.cgi?id=208603 Register Visualzations with a Query Response - programming model<br />
* https://bugs.eclipse.org/bugs/show_bug.cgi?id=208604 Data Visualization Test Harness<br />
<br />
<br />
3. M2 / Leveraging CMDBf Use Case - Wednesday 1:00 PM<br />
* Reiterate / refine our goals.<br />
* How will we push it forward to enable adoption of the CMDBf Use Case?<br />
* Talk about a potential target domain.<br />
* What is the UI approach for M2? Where / how will the COSMOS GUI framework be used?<br />
* Where do we go after this use case?<br />
* Define COSMOS "MDR Toolkit", what tooling we need, etc... see the programming model<br />
* Coordination of efforts with CMDBf.org group<br />
** Schedule call in with Mark J. and Marv W. 3:30pm Eastern 11/8/2007<br />
<br />
<br />
4. COSMOS Programming Model Thursday 8:00 AM<br />
<pre><br />
1) Join the conference up to 20 minutes prior to 8:00 PM at 11/8/2007<br />
2) Direct your web browser to the following URL: http://www.ibm.com/collaboration/webconferences/center/meetingdetails.jsp?meetingId=C7D04A399AEBC7A484D958655C16983D<br />
3) When prompted, enter the web conference password: cosmosf2f<br />
<br />
WEB CONFERENCE DETAILS: <br />
<br />
Conference URL: http://www.ibm.com/collaboration/webconferences/center/meetingdetails.jsp?meetingId=C7D04A399AEBC7A484D958655C16983D<br />
Password: cosmosf2f<br />
Conference name: COSMOS F2F<br />
Start time: 11/8/2007 8:00 PM (GMT -5)<br />
Duration: 0d 2h 00m<br />
Meeting creator: Hubert Leung (hkyleung@ca.ibm.com)<br />
Moderator: Hubert Leung (hkyleung@ca.ibm.com)<br />
</pre><br />
<br />
* [[COSMOS_Programming_Model_Discussions|discussion page]]<br />
* What are the use cases for extending/adopting the COSMOS code<br />
* Adoption patterns<br />
* What do we need in terms of "SDKs". This will impact how we structure our deliverables<br />
* [[Provisional API Guidelines]] (we are currently not following these guidelines)<br />
* Joel's annotation roadmap page [[COSMOSAnnotationsRoadmapPage|here]]<br />
<br />
<br />
<br />
5. Facilitation of Adoption Thursday 1:00 PM<br />
* How do we publish our packaging for the CMDBf Use Case?<br />
* Identify and publish the tech stack for the CMDBf Use Case.<br />
* Identify the range of adopters for the Leveraging CMDBf use case.<br />
* Documentation<br />
* Useability<br />
* Support<br />
* What can we do to ensure that adopters of ALL types derive immediate value?<br />
<br />
<br />
6. Divvy up the work for i8 / i9 (M2) Thursday 11:00 AM<br />
* Try to assign areas of focus for each company across the COSMOS community for the i8 / i9 ERs<br />
** Management Domain design & implementation: CA<br />
** Broker design & implementation: CA<br />
** Logging design & implementation: CA<br />
** SQA methodology / manual / automated testing: CA + ?<br />
** MDR design & implementation: IBM + Compuware + ?<br />
** GUI design & implementation: IBM + Compuware + ?<br />
** Cross-company demo enablement: IBM + Compuware + CA ?<br />
* Review the M2 release plan and establish that it is realistic<br />
* Define plan / timeframe for synchronizing all COSMOS DC codebases<br />
<br />
<br />
7. SQA considerations for the COSMOS DC M2 Friday 8:00 AM<br />
* Define the SQA strategy for M2<br />
* Talk about SQA resourcing<br />
* Talk about the exact function of the SQA resources for the COSMOS DC<br />
* Define QA metrics & release closure criteria for i8 / i9 (i.e. M2)<br />
<br />
<br />
8. Security considerations for the COSMOS DC M2 Friday 10:00 AM<br />
* Define the scope of Security<br />
* What is our Security model?<br />
* How will we publish this capability & area of concern to the outside world?<br />
<br />
<br />
9. Eclipse con presentations/demos [[COSMOSEclipseCon2008Presentations|here]] Friday 1:00 PM<br />
<br />
<br />
10. Wrapup and Action items 2:30 PM</div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=COSMOS_Design_205658&diff=54186COSMOS Design 2056582007-10-09T19:58:42Z<p>Joel.hawkins.compuware.com: </p>
<hr />
<div>This is to be filled in with the Security design.<br />
<br />
<br />
----<br />
See also:<br />
* [[Talk:COSMOS Design 205658]]<br />
<br />
----<br />
[[Category:COSMOS_Bugzilla_Designs]]</div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=CosmosDataCollectionComponent&diff=54185CosmosDataCollectionComponent2007-10-09T19:56:34Z<p>Joel.hawkins.compuware.com: /* Design Documents & Discussions In Progress */</p>
<hr />
<div>[[COSMOS|COSMOS Main Page]] > <br />
= Data Collection and Normalization =<br />
<br />
== Scope and Mission ==<br />
<br />
The Data Collection and Normalization component will implement a data collection framework as described on pages 20 and 21 of the COSMOS project creation review pdf [http://www.eclipse.org/proposals/cosmos/COSMOS%20Project%20Creation%20Review-v1.0a.pdf here].<br />
<br />
The initial scope of the Data Collection and Normalization component supports the <br />
[[COSMOS Use Cases|Use Cases]]<br />
that the COSMOS project is defining to demonstrate the value of SML throughout the application lifecycle. It will accept managent data from the instrumentation produced by the COSMOS [[CosmosBuildToManageComponent| Build to manage]] <br />
component and provide data normalization and persistance and a query API to support its consumption by the COSMOS [[CosmosDataReportingComponent| Data Reporting]] <br />
component.<br />
<br />
== Tactical Plan == <br />
Much of the initial work of the data collection component will be done in cooperation with the TPTP project. To facilitate the timely creation of a demonstrable implementation, the data collection component will leverage key TPTP technologies such as the Common Base Event (CBE) format, TPTP agents such as JMX and the Generic Log Adapter (GLA), and the Agent Controller.<br />
<br />
See also the prototype proposal in the Resources section below.<br />
<br />
== Architectural Vision ==<br />
<br />
=== Persistence API ===<br />
<br />
The framework will provide an extension point for data persistance. Each supported data type will be consumed by a persistor that supports persisting a particular data format into its own database table or other data store.<br />
<br />
Initially, persistors will be provided for the EMF models that TPTP currently supports.<br />
<br />
<br />
=== Data Collection Control API ===<br />
<br />
A WSDM interface will be provided for the purpose of configuring the data collection agents.<br />
<br />
In the longer term, this interface will be usable to manage the monitored infrastructure components.<br />
<br />
=== Adapters for Data Collection agents into Persistence API ===<br />
<br />
The framework will provide an extension point for data collection agent adapters. One possible approach is to provide a service that connects agent adaptors to an appropriate data persistor based on the data type supported by the adaptor such as CBE or WEF. A provision to specify these connections declaratively is required, but they could also be constructed dynamically via a WSDM interface.<br />
<br />
The connection service should specifically support the ability to inject interceptors between the agent adapters and the data persistors.<br />
<br />
Initial adapters will include log, statistical, and perhaps trace adapters but the framework will be generalized so it can be extended to support any additional models as required.<br />
<br />
=== Query API ===<br />
<br />
The query API will provide a web service interface to the data store(s). <br />
<br />
Its binding will be constructed in a manner analogous to the Data Collection adapters where extensions can be created to implement any desired query mechanism without requiring dependence on the type or location of the underlying data store.<br />
<br />
Multiple web services will be provided to allow the consumer to select appropriate query semantics.<br />
<br />
The initial targets are SQL and / or XPath.<br />
<br />
[[COSMOSTPTPQuereryIntrfaceNotes]]<br />
<br />
[[COSMOSQueryInterfaceInitialDesign]]<br />
<br />
=== Database Schema ===<br />
<br />
Each data collection adapter will define the schema for its datastore. A reasonable minimum expectation is that each database will be keyed by timestamp and the unique ID of the managed resource.<br />
<br />
The initial target is [http://en.wikipedia.org/wiki/Apache_Derby Derby], with support for MySQL and proprietary databases later. An attempt will be made to avoid proprietary SQL to permit a wide choice of database engines.<br />
<br />
=== Proposed Technology Stack ===<br />
This diagram shows one possible implementation technology stack for COSMOS data collection<br />
<br />
The data collector will be extended with bundle fragments that implement data collection adapters, persistors and query interfaces. <br />
<br />
Data Collection Adaptors adapt an information source into a common format supported by a persistor.<br />
<br />
Persistors accept information of a particular type such as CBE and provide a persistance service for this data type.<br />
<br />
Query Adaptors adapt queries in a language such as SQL or XPATH to the persistent data store.<br />
<br />
{| border="1"<br />
| || WSDM (Muse)<br />
|-<br />
| || SOAP (Axis)<br />
|-<br />
| || Data Collection Bundle<br />
|-<br />
| DC Adaptor || Persistor || Query <br />
|-<br />
| || OSGi (Equinox)<br />
|}<br />
<br />
<br />
== Common Agent Infrastructure ==<br />
Discussion on Common Agent Infrastructure<br />
<br />
* No formal agent infrastructure currently in scope<br />
** Root level question: Do we want this in COSMOS?<br />
<br />
* COSMOS needs to have some of this to be self hosting<br />
* Tie in BtM<br />
<br />
*<br />
<br />
== Open Issues == <br />
* Which components require alternative implementations in support of embedded devices<br />
* Which components must support Java 1.4<br />
<br />
== Resources ==<br />
<br />
TPTP [[TPTPModel|model]] and [[TPTP_data_persistence_layer|data persistence ]] ([http://dev.eclipse.org/viewcvs/index.cgi/platform/org.eclipse.tptp.platform.models/src-dms/?root=TPTP_Project TPTP DMS CVS link])<br />
<br />
Initial prototype [[COSMOSInitalPrototype|proposal]]<br />
<br />
DataCollector [[DCInitalPrototype|prototype]]<br />
<br />
[[COSMOSPersisteceFrameworks|Persistence Frameworks Discussion]]<br />
<br />
[[COSMOSDataCollectorEnvironment|How to set up your Eclipse for working on DataCollection]]<br />
<br />
[[COSMOSDataCollectionEnd2End|Setting up a tomcat instance to working with the COSMOS End to End example]]<br />
<br />
[[COSMOS_CBE_RDB | Running the Data Collection w/CBEs]]<br />
<br />
[[Data Collection Q&A]]<br />
<br />
[[COSMOSEnd2EndSample | Instructions for running the end-to-end sample ]]<br />
<br />
<br />
[[ COSMOS#Architecture | back to home]]<br />
<br />
<br />
== Design Documents & Discussions In Progress ==<br />
<br />
[[COSMOS_DC_Design_Discussions|DC Design Improvements]]<br />
<br />
[[Data_Manager|Discussions around the Data Manager Design]]<br />
<br />
[[COSMOS_Design_193420|193420: Create simple stand alone example of the data collection framework]]<br />
[https://bugs.eclipse.org/bugs/show_bug.cgi?id=193420 193420]<br />
<br />
[[COSMOS_Design_197867|197867: Need to design and implement the COSMOS DC Data Broker]]<br />
[https://bugs.eclipse.org/bugs/show_bug.cgi?id=197867 197867]<br />
<br />
[[COSMOS_Design_197868|197868: Need to design and implement the COSMOS DC Management Domain]]<br />
[https://bugs.eclipse.org/bugs/show_bug.cgi?id=197868 197868]<br />
<br />
[[COSMOS_Design_197869|197869: Need to design and implement the COSMOS DC Service Broker]]<br />
[https://bugs.eclipse.org/bugs/show_bug.cgi?id=197869 197869]<br />
<br />
[[COSMOS_Design_197870|197870: Need to design and implement the COSMOS DC Client APIs]]<br />
[https://bugs.eclipse.org/bugs/show_bug.cgi?id=197870 197870]<br />
<br />
[[COSMOS_Design_197521|197521: Component implementation - separating framework vs. extension code]]<br />
[https://bugs.eclipse.org/bugs/show_bug.cgi?id=197521 197521]<br />
<br />
[[COSMOS_Design_197525|197525: Buffering data in the data assembly pipeline]]<br />
[https://bugs.eclipse.org/bugs/show_bug.cgi?id=197521 197521]<br />
<br />
[[COSMOS_Design_197833|197833: Need an XML schema for the assembly XML]]<br />
[https://bugs.eclipse.org/bugs/show_bug.cgi?id=197833 197833]<br />
<br />
[[COSMOS_Design_205658|205658: Security Framework/Muse Security Integration]]<br />
[https://bugs.eclipse.org/bugs/show_bug.cgi?id=205658 205658]</div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=Talk:COSMOS_i6_dependencies&diff=49507Talk:COSMOS i6 dependencies2007-09-06T20:43:02Z<p>Joel.hawkins.compuware.com: New page: Mark, you can probably fill this in by checking our IP logs. One glaring ommision from DC's point of view is Apache Muse.</p>
<hr />
<div>Mark, you can probably fill this in by checking our IP logs. One glaring ommision from DC's point of view is Apache Muse.</div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=COSMOS_Design_197521&diff=49484COSMOS Design 1975212007-09-06T20:01:09Z<p>Joel.hawkins.compuware.com: /* '''Framework Implementation Details''' */</p>
<hr />
<div>'''Design Discussion for [https://bugs.eclipse.org/bugs/show_bug.cgi?id=197521 197521]: component implementation - separating framework vs. extension code '''<br />
<br />
== '''Separation of Concerns for COSMOS DC framework''' ==<br />
<br />
This design document addresses COSMOS Bugzilla enhancement request [https://bugs.eclipse.org/bugs/show_bug.cgi?id=197521 197521]. <br />
<br />
<br />
Change History:<br />
<br />
Joel Hawkins 9/05/2007 Initial version<br />
<br />
== '''Overview''' ==<br />
<br />
Currently, the DC framework uses the java stack. Threading issues related to query response management delegated to response components.<br />
Proposed approach constructs call-graph trees during loading/compilation phase. Proper tree chosen by framework for execution. Root components responsible for dispatching to framework only. No knowledge required of other components (no more wiring within the component). <br />
<br />
== ''' Implementation Stages and Corporate Use Cases ''' ==<br />
<br />
Initial implementation and conversion of existing components/assemblies for iteration 6.<br />
<br />
== '''Terminologies/Acronyms''' ==<br />
<br />
The terminologies/acronyms below are commonly used throughout this document. The list below defines each term:<br />
<br />
ASSEMBLY: A collection of components that are used by the framework to either route data for storage or perform queries on stored data. <br />
<br />
ASSEMBLY DEFINITION: An XML document that describes an ASSEMBLY.<br />
<br />
ASSEMBLY DESCRIPTOR: The in memory representation of an assembly declaration.<br />
<br />
COMPONENT: A discrete element in an assembly. Components are external to the framework. <br />
<br />
ASSEMBLY COMPILER: A utility class that converts an assembly descriptor into an executable entity. <br />
<br />
CONTEXT: The runtime representation of an assembly.<br />
<br />
COMPONENT: A discrete element in an assembly. Components are external to the framework. Components come in five flavors - Sources, Sinks, Transforms, Filters, and Responses.<br />
<br />
RESPONSE COMPONENT: A tagging component that enables the framework to manage query response sets that have been filtered and/or transformed by the framework. The response component has very little processing content in terms of implementation, but plays a crucial role in enabling the framework to process query requests. <br />
<br />
RUNTIME: The host environment for assemblies.<br />
<br />
OPTIMIZATION PROXY: A dynamic component inserted by the framework to allow components to be bypassed in certain scenarios.<br />
<br />
VECTOR PROXY: A dynamic component inserted by the framework to allow components that match in type but not in cardinality to interact. See LINK to 197525 for a discussion of how buffering is supported in the framework.<br />
<br />
DYNAMIC PROGRAMMING: An optimization technique useful for computing optimal paths through acyclic directed graphs based on a 'cost' concept.<br />
<br />
<br />
==Use Cases==<br />
<br />
Direct component access.<br />
<br />
Branched query<br />
<br />
Branched collection<br />
<br />
<br />
== '''External Interfaces''' ==<br />
<br />
'''Framework Interface'''<br />
<br />
<pre><br />
@ManagedResourceCapability(namespace=IDataCollectionContext.NAMESPACE)<br />
public abstract interface IDataCollectionContext {<br />
<br />
public static final String NAMESPACE = "http://www.eclipse.org/xmlns/cosmos/1.0/Context";<br />
<br />
public static final String COSMOS_NAMESPACE = "http://www.eclipse.org/xmlns/cosmos/1.0";<br />
<br />
public static QName CONTEXT_QNAME = new QName(COSMOS_NAMESPACE,"context");<br />
public static QName NAME_QNAME = new QName(COSMOS_NAMESPACE,"name");<br />
public static QName DIRECTION_QNAME = new QName(COSMOS_NAMESPACE,"direction");<br />
public static QName OPTIMIZABLE_QNAME = new QName(COSMOS_NAMESPACE,"optimizable");<br />
<br />
@ManagedPropertyGetter<br />
String getName();<br />
<br />
@ManagedOperation<br />
void materialize() throws Exception;<br />
<br />
@ManagedOperation<br />
boolean isQueryContext();<br />
<br />
@ManagedOperation<br />
boolean isCollectionContext();<br />
<br />
@ManagedOperation<br />
void flush();<br />
<br />
@ManagedOperation<br />
public IDataSourceService getDataSource();<br />
<br />
@ManagedOperation<br />
public IDataQueryService getDataQuery();<br />
<br />
void dispatch(Object obj, IDataSourceService dispatcher) throws RuntimeException;<br />
void dispatch(Object obj, String response, IDataQueryService dispatcher) throws RuntimeException;<br />
<br />
IDataQueryResult getQueryResult();<br />
<br />
boolean isSupportedQueryResponse(String response);<br />
void addQueryResponseType(String type);<br />
String[] getQueryResponseTypes();<br />
void addQueryResult(Object obj);<br />
<br />
}<br />
</pre><br />
<br />
<br />
'''Component Interfaces'''<br />
<br />
Intermediate component interfaces reduced to tagging interfaces. <br />
<br />
<pre><br />
public interface IDataFilterService {<br />
static QName FILTER_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"filter");<br />
}<br />
</pre><br />
<br />
<pre><br />
public interface IDataTransformService {<br />
public static QName TRANSFORM_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"transform");<br />
}<br />
</pre><br />
<br />
Source, Query and Sink interfaces reduced to capability declarations and context access methods. <br />
<br />
<pre><br />
@ManagedResourceCapability(namespace="http://cosmos.eclipse.org/capabilities/query")<br />
public interface IDataQueryService {<br />
<br />
public static QName QUERY_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"query");<br />
public static String PREFIX = "query";<br />
public static String NAMESPACE_URI = "http://cosmos.eclipse.org/capabilities/query";<br />
public static String SUPPORTED_DIALECTS_URI = NAMESPACE_URI+"/getSupportedDialects";<br />
public static String SUPPORTED_RESPONSES_URI = NAMESPACE_URI+"/getSupportedResponses";<br />
public static String SUPPORTED_QUERY_URI = NAMESPACE_URI+"/supportedQuery";<br />
public static String QUERY_URI = NAMESPACE_URI+"/query";<br />
public static String PAGE_QUERY_URI = NAMESPACE_URI+"/pageQuery";<br />
<br />
public static final QName DIALECTS_QNAME = <br />
new QName(NAMESPACE_URI, "getSupportedDialects", PREFIX);<br />
<br />
<br />
@ManagedOperation(namespace=NAMESPACE_URI)<br />
String[] getSupportedDialects();<br />
<br />
@ManagedOperation(namespace=NAMESPACE_URI)<br />
String[] getSupportedResponses();<br />
<br />
@ManagedOperation(namespace=NAMESPACE_URI)<br />
boolean supportedQuery(String dialect, String response); <br />
<br />
@ManagedOperation(namespace=NAMESPACE_URI)<br />
IDataQueryResult query(String dialect, String response, String queryString, String dataSource) throws Exception;<br />
<br />
@ManagedOperation(namespace=NAMESPACE_URI)<br />
IDataQueryResult pageQuery(String dialect, String response, String queryString, String dataSource, int max, int start) throws Exception;<br />
<br />
void setContext(IDataCollectionContext context);<br />
<br />
}<br />
<br />
</pre><br />
<br />
<br />
<pre><br />
public interface IDataSinkService {<br />
<br />
public static QName SINK_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"sink");<br />
static QName DATA_FLOW_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"dataflow");<br />
static QName DATA_SOURCE_TYPE_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"type");<br />
static QName DATA_KEY_SET_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"keyset");<br />
static QName DATA_KEY_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"key");<br />
<br />
public DimensionSet getDimensionSet(); //Needs revisting based on DataBroker interaction requirements<br />
public void setDataSet(DataSet ds); //Needs revisting based on DataBroker interaction requirements<br />
<br />
}<br />
</pre><br />
<br />
<pre><br />
public interface IDataSourceService {<br />
<br />
static QName SOURCE_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"source");<br />
static QName FACTORY_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"factory");<br />
static QName DATA_SOURCE_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"datasource");<br />
<br />
/*<br />
* The following 6 methods are exposed as management capabilities <br />
* by the abstract implementation of this interface. See <br />
* org.eclipse.cosmos.dc.common.api.impl.AbstractDataSource<br />
*/<br />
boolean connect() throws Exception;<br />
boolean run() throws Exception;<br />
boolean disconnect() throws Exception;<br />
boolean cancel() throws Exception;<br />
boolean pause() throws Exception;<br />
boolean resume() throws Exception;<br />
<br />
DataSource getDataSource(); //Needs revisting based on DataBroker interaction requirements<br />
<br />
void setContext(IDataCollectionContext context);<br />
<br />
}<br />
</pre><br />
<br />
Response service provides static information to framework to allow management of response collections, removing that responsibility from the component level.<br />
<br />
<pre><br />
public interface IDataResponseService {<br />
<br />
public static QName RESPONSE_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"response");<br />
<br />
public String[] getResponseTypes();<br />
<br />
public Class getClassForType(String type);<br />
<br />
void setContext(IDataCollectionContext context);<br />
<br />
}<br />
</pre><br />
<br />
'''Conventions'''<br />
<br />
Naming conventions used by reflection during compilation.<br />
<br />
"public void dispatch*(type)" for root components (query and source). - invoked by the component to dispatch data into the assembly. Introspected by the assembly to construct callgraphs.<br />
<br />
"public type filter*(type)" for filter components<br />
<br />
"public type transform*(type)" for transform components<br />
<br />
"public void store*(type)" for sink components<br />
<br />
"public void response*(type)" for response components<br />
<br />
Methods must be declared by component class. <br />
<br />
For array types and collections, the types are matched by the base type. Collections be declared using generics in order to support type-safe handling. See LINK TO 197525 for a discussion of how collections and arrays are handled by the framework.<br />
<br />
== '''Framework Implementation Details''' ==<br />
<br />
Assumptions:<br />
*Assemblies are singletons. <br />
*Components are thread safe. <br />
<br />
Discussion of compilation steps:<br />
<br />
*Runtime loads assembly: parses assembly documentation.<br />
<br />
*Runtime verifies that assembly with same identifier is not active<br />
*Runtime materializes assembly<br />
**creates context instance for assembly<br />
**compiles context using ContextCompiler<br />
<br />
*Compiler creates component tree<br />
<br />
*Compiler extracts dispatch methods from root component<br />
<br />
*Compiler computes possible call graphs through assembly based on method signatures and conventions. Computation includes insertion of proxies where appropriate (either for vector considerations or optimzation possibilities).<br />
<br />
*If root is query, compiler duplicates root call graphs for each supported response type, adjusting costs of responses to allow optimisation step to compute best path for each supported response type.<br />
<br />
*Compiler computes optimum path for each root dispatch method, culling suboptimal paths using a top-down dynamic programming algorithm. Culling is performed across all child components, choosing only the best path. <br />
<br />
*If root is query, remove all duplicated paths that did not fathom. <br />
<br />
Discussion of runtime steps<br />
<br />
ThreadLocal<br />
<br />
*localMethod<br />
*localQueryResult<br />
*localQueryCollection<br />
*localQueryCollectionClass<br />
<br />
Query <br />
<br />
* ThreadLocal usage<br />
** localMethod <br />
** local QueryResult<br />
** localQueryCollection<br />
** localQueryCollectionClass<br />
<br />
* Response managment<br />
** Native response type<br />
** Assembled response types<br />
<br />
Source<br />
<br />
* ThreadLocal usage<br />
** localMethod<br />
<br />
* Sink management<br />
* Native sink<br />
* Assembled sink<br />
<br />
General<br />
Depth-first traversal of call graph<br />
Dispatch to framework using context<br />
Abstract class wrappers<br />
<br />
== '''Notes''' ==<br />
Declarative support for culling within component vs global culling across all components for non-query case.<br />
Management control over buffer size?<br />
Configurable optimization controls? (Vary costing of vectorization/optimzation proxy/component types)<br />
Debugging of compilation process<br />
Error reporting - operational status based on 'wiring'.<br />
<br />
Sink methods - support for dataset registration... need to flesh out databroker interaction here (back to instance data again)<br />
Source methods - support for datasource registration... need to flesh out databroker interaction here (back to instance data again)<br />
----<br />
[[Category:COSMOS_Bugzilla_Designs]]</div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=COSMOS_Design_197521&diff=49480COSMOS Design 1975212007-09-06T19:56:12Z<p>Joel.hawkins.compuware.com: /* '''Framework Implementation Details''' */</p>
<hr />
<div>'''Design Discussion for [https://bugs.eclipse.org/bugs/show_bug.cgi?id=197521 197521]: component implementation - separating framework vs. extension code '''<br />
<br />
== '''Separation of Concerns for COSMOS DC framework''' ==<br />
<br />
This design document addresses COSMOS Bugzilla enhancement request [https://bugs.eclipse.org/bugs/show_bug.cgi?id=197521 197521]. <br />
<br />
<br />
Change History:<br />
<br />
Joel Hawkins 9/05/2007 Initial version<br />
<br />
== '''Overview''' ==<br />
<br />
Currently, the DC framework uses the java stack. Threading issues related to query response management delegated to response components.<br />
Proposed approach constructs call-graph trees during loading/compilation phase. Proper tree chosen by framework for execution. Root components responsible for dispatching to framework only. No knowledge required of other components (no more wiring within the component). <br />
<br />
== ''' Implementation Stages and Corporate Use Cases ''' ==<br />
<br />
Initial implementation and conversion of existing components/assemblies for iteration 6.<br />
<br />
== '''Terminologies/Acronyms''' ==<br />
<br />
The terminologies/acronyms below are commonly used throughout this document. The list below defines each term:<br />
<br />
ASSEMBLY: A collection of components that are used by the framework to either route data for storage or perform queries on stored data. <br />
<br />
ASSEMBLY DEFINITION: An XML document that describes an ASSEMBLY.<br />
<br />
ASSEMBLY DESCRIPTOR: The in memory representation of an assembly declaration.<br />
<br />
COMPONENT: A discrete element in an assembly. Components are external to the framework. <br />
<br />
ASSEMBLY COMPILER: A utility class that converts an assembly descriptor into an executable entity. <br />
<br />
CONTEXT: The runtime representation of an assembly.<br />
<br />
COMPONENT: A discrete element in an assembly. Components are external to the framework. Components come in five flavors - Sources, Sinks, Transforms, Filters, and Responses.<br />
<br />
RESPONSE COMPONENT: A tagging component that enables the framework to manage query response sets that have been filtered and/or transformed by the framework. The response component has very little processing content in terms of implementation, but plays a crucial role in enabling the framework to process query requests. <br />
<br />
RUNTIME: The host environment for assemblies.<br />
<br />
OPTIMIZATION PROXY: A dynamic component inserted by the framework to allow components to be bypassed in certain scenarios.<br />
<br />
VECTOR PROXY: A dynamic component inserted by the framework to allow components that match in type but not in cardinality to interact. See LINK to 197525 for a discussion of how buffering is supported in the framework.<br />
<br />
DYNAMIC PROGRAMMING: An optimization technique useful for computing optimal paths through acyclic directed graphs based on a 'cost' concept.<br />
<br />
<br />
==Use Cases==<br />
<br />
Direct component access.<br />
<br />
Branched query<br />
<br />
Branched collection<br />
<br />
<br />
== '''External Interfaces''' ==<br />
<br />
'''Framework Interface'''<br />
<br />
<pre><br />
@ManagedResourceCapability(namespace=IDataCollectionContext.NAMESPACE)<br />
public abstract interface IDataCollectionContext {<br />
<br />
public static final String NAMESPACE = "http://www.eclipse.org/xmlns/cosmos/1.0/Context";<br />
<br />
public static final String COSMOS_NAMESPACE = "http://www.eclipse.org/xmlns/cosmos/1.0";<br />
<br />
public static QName CONTEXT_QNAME = new QName(COSMOS_NAMESPACE,"context");<br />
public static QName NAME_QNAME = new QName(COSMOS_NAMESPACE,"name");<br />
public static QName DIRECTION_QNAME = new QName(COSMOS_NAMESPACE,"direction");<br />
public static QName OPTIMIZABLE_QNAME = new QName(COSMOS_NAMESPACE,"optimizable");<br />
<br />
@ManagedPropertyGetter<br />
String getName();<br />
<br />
@ManagedOperation<br />
void materialize() throws Exception;<br />
<br />
@ManagedOperation<br />
boolean isQueryContext();<br />
<br />
@ManagedOperation<br />
boolean isCollectionContext();<br />
<br />
@ManagedOperation<br />
void flush();<br />
<br />
@ManagedOperation<br />
public IDataSourceService getDataSource();<br />
<br />
@ManagedOperation<br />
public IDataQueryService getDataQuery();<br />
<br />
void dispatch(Object obj, IDataSourceService dispatcher) throws RuntimeException;<br />
void dispatch(Object obj, String response, IDataQueryService dispatcher) throws RuntimeException;<br />
<br />
IDataQueryResult getQueryResult();<br />
<br />
boolean isSupportedQueryResponse(String response);<br />
void addQueryResponseType(String type);<br />
String[] getQueryResponseTypes();<br />
void addQueryResult(Object obj);<br />
<br />
}<br />
</pre><br />
<br />
<br />
'''Component Interfaces'''<br />
<br />
Intermediate component interfaces reduced to tagging interfaces. <br />
<br />
<pre><br />
public interface IDataFilterService {<br />
static QName FILTER_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"filter");<br />
}<br />
</pre><br />
<br />
<pre><br />
public interface IDataTransformService {<br />
public static QName TRANSFORM_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"transform");<br />
}<br />
</pre><br />
<br />
Source, Query and Sink interfaces reduced to capability declarations and context access methods. <br />
<br />
<pre><br />
@ManagedResourceCapability(namespace="http://cosmos.eclipse.org/capabilities/query")<br />
public interface IDataQueryService {<br />
<br />
public static QName QUERY_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"query");<br />
public static String PREFIX = "query";<br />
public static String NAMESPACE_URI = "http://cosmos.eclipse.org/capabilities/query";<br />
public static String SUPPORTED_DIALECTS_URI = NAMESPACE_URI+"/getSupportedDialects";<br />
public static String SUPPORTED_RESPONSES_URI = NAMESPACE_URI+"/getSupportedResponses";<br />
public static String SUPPORTED_QUERY_URI = NAMESPACE_URI+"/supportedQuery";<br />
public static String QUERY_URI = NAMESPACE_URI+"/query";<br />
public static String PAGE_QUERY_URI = NAMESPACE_URI+"/pageQuery";<br />
<br />
public static final QName DIALECTS_QNAME = <br />
new QName(NAMESPACE_URI, "getSupportedDialects", PREFIX);<br />
<br />
<br />
@ManagedOperation(namespace=NAMESPACE_URI)<br />
String[] getSupportedDialects();<br />
<br />
@ManagedOperation(namespace=NAMESPACE_URI)<br />
String[] getSupportedResponses();<br />
<br />
@ManagedOperation(namespace=NAMESPACE_URI)<br />
boolean supportedQuery(String dialect, String response); <br />
<br />
@ManagedOperation(namespace=NAMESPACE_URI)<br />
IDataQueryResult query(String dialect, String response, String queryString, String dataSource) throws Exception;<br />
<br />
@ManagedOperation(namespace=NAMESPACE_URI)<br />
IDataQueryResult pageQuery(String dialect, String response, String queryString, String dataSource, int max, int start) throws Exception;<br />
<br />
void setContext(IDataCollectionContext context);<br />
<br />
}<br />
<br />
</pre><br />
<br />
<br />
<pre><br />
public interface IDataSinkService {<br />
<br />
public static QName SINK_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"sink");<br />
static QName DATA_FLOW_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"dataflow");<br />
static QName DATA_SOURCE_TYPE_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"type");<br />
static QName DATA_KEY_SET_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"keyset");<br />
static QName DATA_KEY_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"key");<br />
<br />
public DimensionSet getDimensionSet(); //Needs revisting based on DataBroker interaction requirements<br />
public void setDataSet(DataSet ds); //Needs revisting based on DataBroker interaction requirements<br />
<br />
}<br />
</pre><br />
<br />
<pre><br />
public interface IDataSourceService {<br />
<br />
static QName SOURCE_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"source");<br />
static QName FACTORY_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"factory");<br />
static QName DATA_SOURCE_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"datasource");<br />
<br />
/*<br />
* The following 6 methods are exposed as management capabilities <br />
* by the abstract implementation of this interface. See <br />
* org.eclipse.cosmos.dc.common.api.impl.AbstractDataSource<br />
*/<br />
boolean connect() throws Exception;<br />
boolean run() throws Exception;<br />
boolean disconnect() throws Exception;<br />
boolean cancel() throws Exception;<br />
boolean pause() throws Exception;<br />
boolean resume() throws Exception;<br />
<br />
DataSource getDataSource(); //Needs revisting based on DataBroker interaction requirements<br />
<br />
void setContext(IDataCollectionContext context);<br />
<br />
}<br />
</pre><br />
<br />
Response service provides static information to framework to allow management of response collections, removing that responsibility from the component level.<br />
<br />
<pre><br />
public interface IDataResponseService {<br />
<br />
public static QName RESPONSE_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"response");<br />
<br />
public String[] getResponseTypes();<br />
<br />
public Class getClassForType(String type);<br />
<br />
void setContext(IDataCollectionContext context);<br />
<br />
}<br />
</pre><br />
<br />
'''Conventions'''<br />
<br />
Naming conventions used by reflection during compilation.<br />
<br />
"public void dispatch*(type)" for root components (query and source). - invoked by the component to dispatch data into the assembly. Introspected by the assembly to construct callgraphs.<br />
<br />
"public type filter*(type)" for filter components<br />
<br />
"public type transform*(type)" for transform components<br />
<br />
"public void store*(type)" for sink components<br />
<br />
"public void response*(type)" for response components<br />
<br />
Methods must be declared by component class. <br />
<br />
For array types and collections, the types are matched by the base type. Collections be declared using generics in order to support type-safe handling. See LINK TO 197525 for a discussion of how collections and arrays are handled by the framework.<br />
<br />
== '''Framework Implementation Details''' ==<br />
<br />
Assumptions:<br />
*Assemblies are singletons. <br />
*Components are thread safe. <br />
<br />
Discussion of compilation steps:<br />
<br />
*Runtime loads assembly: parses assembly documentation.<br />
<br />
*Runtime verifies that assembly with same identifier is not active<br />
*Runtime materializes assembly<br />
**creates context instance for assembly<br />
**compiles context using ContextCompiler<br />
<br />
*Compiler creates component tree<br />
<br />
*Compiler extracts dispatch methods from root component<br />
<br />
*Compiler computes possible call graphs through assembly based on method signatures and conventions. Computation includes insertion of proxies where appropriate (either for vector considerations or optimzation possibilities).<br />
<br />
*If root is query, compiler duplicates root call graphs for each supported response type, adjusting costs of responses to allow optimisation step to compute best path for each supported response type.<br />
<br />
*Compiler computes optimum path for each root dispatch method, culling suboptimal paths using a top-down dynamic programming algorithm. Culling is performed across all child components, choosing only the best path. <br />
<br />
*If root is query, remove all duplicated paths that did not fathom. <br />
<br />
Discussion of runtime steps<br />
<br />
ThreadLocal<br />
<br />
private ThreadLocal localMethod = new ThreadLocal(); <br />
private ThreadLocal localQueryResult = new ThreadLocal(); <br />
private ThreadLocal localQueryCollection = new ThreadLocal(); <br />
private ThreadLocal localQueryCollectionClass = new ThreadLocal(); <br />
<br />
Query <br />
<br />
* ThreadLocal usage<br />
** localMethod <br />
** local QueryResult<br />
** localQueryCollection<br />
** localQueryCollectionClass<br />
<br />
* Response managment<br />
** Native response type<br />
** Assembled response types<br />
<br />
Source<br />
<br />
* ThreadLocal usage<br />
** localMethod<br />
<br />
* Sink management<br />
* Native sink<br />
* Assembled sink<br />
<br />
General<br />
Depth-first traversal of call graph<br />
Dispatch to framework using context<br />
Abstract class wrappers<br />
<br />
== '''Notes''' ==<br />
Declarative support for culling within component vs global culling across all components for non-query case.<br />
Management control over buffer size?<br />
Configurable optimization controls? (Vary costing of vectorization/optimzation proxy/component types)<br />
Debugging of compilation process<br />
Error reporting - operational status based on 'wiring'.<br />
<br />
Sink methods - support for dataset registration... need to flesh out databroker interaction here (back to instance data again)<br />
Source methods - support for datasource registration... need to flesh out databroker interaction here (back to instance data again)<br />
----<br />
[[Category:COSMOS_Bugzilla_Designs]]</div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=COSMOS_Design_197521&diff=49471COSMOS Design 1975212007-09-06T19:44:31Z<p>Joel.hawkins.compuware.com: /* '''Framework Implementation Details''' */</p>
<hr />
<div>'''Design Discussion for [https://bugs.eclipse.org/bugs/show_bug.cgi?id=197521 197521]: component implementation - separating framework vs. extension code '''<br />
<br />
== '''Separation of Concerns for COSMOS DC framework''' ==<br />
<br />
This design document addresses COSMOS Bugzilla enhancement request [https://bugs.eclipse.org/bugs/show_bug.cgi?id=197521 197521]. <br />
<br />
<br />
Change History:<br />
<br />
Joel Hawkins 9/05/2007 Initial version<br />
<br />
== '''Overview''' ==<br />
<br />
Currently, the DC framework uses the java stack. Threading issues related to query response management delegated to response components.<br />
Proposed approach constructs call-graph trees during loading/compilation phase. Proper tree chosen by framework for execution. Root components responsible for dispatching to framework only. No knowledge required of other components (no more wiring within the component). <br />
<br />
== ''' Implementation Stages and Corporate Use Cases ''' ==<br />
<br />
Initial implementation and conversion of existing components/assemblies for iteration 6.<br />
<br />
== '''Terminologies/Acronyms''' ==<br />
<br />
The terminologies/acronyms below are commonly used throughout this document. The list below defines each term:<br />
<br />
ASSEMBLY: A collection of components that are used by the framework to either route data for storage or perform queries on stored data. <br />
<br />
ASSEMBLY DEFINITION: An XML document that describes an ASSEMBLY.<br />
<br />
ASSEMBLY DESCRIPTOR: The in memory representation of an assembly declaration.<br />
<br />
COMPONENT: A discrete element in an assembly. Components are external to the framework. <br />
<br />
ASSEMBLY COMPILER: A utility class that converts an assembly descriptor into an executable entity. <br />
<br />
CONTEXT: The runtime representation of an assembly.<br />
<br />
COMPONENT: A discrete element in an assembly. Components are external to the framework. Components come in five flavors - Sources, Sinks, Transforms, Filters, and Responses.<br />
<br />
RESPONSE COMPONENT: A tagging component that enables the framework to manage query response sets that have been filtered and/or transformed by the framework. The response component has very little processing content in terms of implementation, but plays a crucial role in enabling the framework to process query requests. <br />
<br />
RUNTIME: The host environment for assemblies.<br />
<br />
OPTIMIZATION PROXY: A dynamic component inserted by the framework to allow components to be bypassed in certain scenarios.<br />
<br />
VECTOR PROXY: A dynamic component inserted by the framework to allow components that match in type but not in cardinality to interact. See LINK to 197525 for a discussion of how buffering is supported in the framework.<br />
<br />
DYNAMIC PROGRAMMING: An optimization technique useful for computing optimal paths through acyclic directed graphs based on a 'cost' concept.<br />
<br />
<br />
==Use Cases==<br />
<br />
Direct component access.<br />
<br />
Branched query<br />
<br />
Branched collection<br />
<br />
<br />
== '''External Interfaces''' ==<br />
<br />
'''Framework Interface'''<br />
<br />
<pre><br />
@ManagedResourceCapability(namespace=IDataCollectionContext.NAMESPACE)<br />
public abstract interface IDataCollectionContext {<br />
<br />
public static final String NAMESPACE = "http://www.eclipse.org/xmlns/cosmos/1.0/Context";<br />
<br />
public static final String COSMOS_NAMESPACE = "http://www.eclipse.org/xmlns/cosmos/1.0";<br />
<br />
public static QName CONTEXT_QNAME = new QName(COSMOS_NAMESPACE,"context");<br />
public static QName NAME_QNAME = new QName(COSMOS_NAMESPACE,"name");<br />
public static QName DIRECTION_QNAME = new QName(COSMOS_NAMESPACE,"direction");<br />
public static QName OPTIMIZABLE_QNAME = new QName(COSMOS_NAMESPACE,"optimizable");<br />
<br />
@ManagedPropertyGetter<br />
String getName();<br />
<br />
@ManagedOperation<br />
void materialize() throws Exception;<br />
<br />
@ManagedOperation<br />
boolean isQueryContext();<br />
<br />
@ManagedOperation<br />
boolean isCollectionContext();<br />
<br />
@ManagedOperation<br />
void flush();<br />
<br />
@ManagedOperation<br />
public IDataSourceService getDataSource();<br />
<br />
@ManagedOperation<br />
public IDataQueryService getDataQuery();<br />
<br />
void dispatch(Object obj, IDataSourceService dispatcher) throws RuntimeException;<br />
void dispatch(Object obj, String response, IDataQueryService dispatcher) throws RuntimeException;<br />
<br />
IDataQueryResult getQueryResult();<br />
<br />
boolean isSupportedQueryResponse(String response);<br />
void addQueryResponseType(String type);<br />
String[] getQueryResponseTypes();<br />
void addQueryResult(Object obj);<br />
<br />
}<br />
</pre><br />
<br />
<br />
'''Component Interfaces'''<br />
<br />
Intermediate component interfaces reduced to tagging interfaces. <br />
<br />
<pre><br />
public interface IDataFilterService {<br />
static QName FILTER_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"filter");<br />
}<br />
</pre><br />
<br />
<pre><br />
public interface IDataTransformService {<br />
public static QName TRANSFORM_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"transform");<br />
}<br />
</pre><br />
<br />
Source, Query and Sink interfaces reduced to capability declarations and context access methods. <br />
<br />
<pre><br />
@ManagedResourceCapability(namespace="http://cosmos.eclipse.org/capabilities/query")<br />
public interface IDataQueryService {<br />
<br />
public static QName QUERY_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"query");<br />
public static String PREFIX = "query";<br />
public static String NAMESPACE_URI = "http://cosmos.eclipse.org/capabilities/query";<br />
public static String SUPPORTED_DIALECTS_URI = NAMESPACE_URI+"/getSupportedDialects";<br />
public static String SUPPORTED_RESPONSES_URI = NAMESPACE_URI+"/getSupportedResponses";<br />
public static String SUPPORTED_QUERY_URI = NAMESPACE_URI+"/supportedQuery";<br />
public static String QUERY_URI = NAMESPACE_URI+"/query";<br />
public static String PAGE_QUERY_URI = NAMESPACE_URI+"/pageQuery";<br />
<br />
public static final QName DIALECTS_QNAME = <br />
new QName(NAMESPACE_URI, "getSupportedDialects", PREFIX);<br />
<br />
<br />
@ManagedOperation(namespace=NAMESPACE_URI)<br />
String[] getSupportedDialects();<br />
<br />
@ManagedOperation(namespace=NAMESPACE_URI)<br />
String[] getSupportedResponses();<br />
<br />
@ManagedOperation(namespace=NAMESPACE_URI)<br />
boolean supportedQuery(String dialect, String response); <br />
<br />
@ManagedOperation(namespace=NAMESPACE_URI)<br />
IDataQueryResult query(String dialect, String response, String queryString, String dataSource) throws Exception;<br />
<br />
@ManagedOperation(namespace=NAMESPACE_URI)<br />
IDataQueryResult pageQuery(String dialect, String response, String queryString, String dataSource, int max, int start) throws Exception;<br />
<br />
void setContext(IDataCollectionContext context);<br />
<br />
}<br />
<br />
</pre><br />
<br />
<br />
<pre><br />
public interface IDataSinkService {<br />
<br />
public static QName SINK_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"sink");<br />
static QName DATA_FLOW_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"dataflow");<br />
static QName DATA_SOURCE_TYPE_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"type");<br />
static QName DATA_KEY_SET_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"keyset");<br />
static QName DATA_KEY_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"key");<br />
<br />
public DimensionSet getDimensionSet(); //Needs revisting based on DataBroker interaction requirements<br />
public void setDataSet(DataSet ds); //Needs revisting based on DataBroker interaction requirements<br />
<br />
}<br />
</pre><br />
<br />
<pre><br />
public interface IDataSourceService {<br />
<br />
static QName SOURCE_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"source");<br />
static QName FACTORY_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"factory");<br />
static QName DATA_SOURCE_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"datasource");<br />
<br />
/*<br />
* The following 6 methods are exposed as management capabilities <br />
* by the abstract implementation of this interface. See <br />
* org.eclipse.cosmos.dc.common.api.impl.AbstractDataSource<br />
*/<br />
boolean connect() throws Exception;<br />
boolean run() throws Exception;<br />
boolean disconnect() throws Exception;<br />
boolean cancel() throws Exception;<br />
boolean pause() throws Exception;<br />
boolean resume() throws Exception;<br />
<br />
DataSource getDataSource(); //Needs revisting based on DataBroker interaction requirements<br />
<br />
void setContext(IDataCollectionContext context);<br />
<br />
}<br />
</pre><br />
<br />
Response service provides static information to framework to allow management of response collections, removing that responsibility from the component level.<br />
<br />
<pre><br />
public interface IDataResponseService {<br />
<br />
public static QName RESPONSE_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"response");<br />
<br />
public String[] getResponseTypes();<br />
<br />
public Class getClassForType(String type);<br />
<br />
void setContext(IDataCollectionContext context);<br />
<br />
}<br />
</pre><br />
<br />
'''Conventions'''<br />
<br />
Naming conventions used by reflection during compilation.<br />
<br />
"public void dispatch*(type)" for root components (query and source). - invoked by the component to dispatch data into the assembly. Introspected by the assembly to construct callgraphs.<br />
<br />
"public type filter*(type)" for filter components<br />
<br />
"public type transform*(type)" for transform components<br />
<br />
"public void store*(type)" for sink components<br />
<br />
"public void response*(type)" for response components<br />
<br />
Methods must be declared by component class. <br />
<br />
For array types and collections, the types are matched by the base type. Collections be declared using generics in order to support type-safe handling. See LINK TO 197525 for a discussion of how collections and arrays are handled by the framework.<br />
<br />
== '''Framework Implementation Details''' ==<br />
<br />
Assumptions:<br />
*Assemblies are singletons. <br />
*Components are thread safe. <br />
<br />
Discussion of compilation steps:<br />
<br />
runtime loads assembly: parses assembly documentation.<br />
<br />
runtime verifies that assembly with same identifier is not active<br />
runtime materializes assembly<br />
creates context instance for assembly<br />
compiles context using ContextCompiler<br />
<br />
compiler creates component tree<br />
<br />
compiler extracts dispatch methods from root component<br />
<br />
compiler computes possible call graphs through assembly based on method signatures and conventions. Computation includes insertion of proxies where appropriate (either for vector considerations or optimzation possibilities).<br />
<br />
If root is query, compiler duplicates root call graphs for each supported response type, adjusting costs of responses to allow optimisation step to compute best path for each supported response type.<br />
<br />
Compiler computes optimum path for each root dispatch method, culling suboptimal paths using a top-down dynamic programming algorithm. Culling is performed across all child components, choosing only the best path. <br />
<br />
If root is query, remove all duplicated paths that did not fathom. <br />
<br />
Discussion of runtime steps<br />
<br />
Query <br />
Usage of ThreadLocal in data management<br />
<br />
General<br />
Depth-first traversal of call graph<br />
Dispatch to framework using context<br />
Abstract class wrappers<br />
<br />
== '''Notes''' ==<br />
Declarative support for culling within component vs global culling across all components for non-query case.<br />
Management control over buffer size?<br />
Configurable optimization controls? (Vary costing of vectorization/optimzation proxy/component types)<br />
Debugging of compilation process<br />
Error reporting - operational status based on 'wiring'.<br />
<br />
Sink methods - support for dataset registration... need to flesh out databroker interaction here (back to instance data again)<br />
Source methods - support for datasource registration... need to flesh out databroker interaction here (back to instance data again)<br />
----<br />
[[Category:COSMOS_Bugzilla_Designs]]</div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=COSMOS_Design_197521&diff=49470COSMOS Design 1975212007-09-06T19:42:19Z<p>Joel.hawkins.compuware.com: </p>
<hr />
<div>'''Design Discussion for [https://bugs.eclipse.org/bugs/show_bug.cgi?id=197521 197521]: component implementation - separating framework vs. extension code '''<br />
<br />
== '''Separation of Concerns for COSMOS DC framework''' ==<br />
<br />
This design document addresses COSMOS Bugzilla enhancement request [https://bugs.eclipse.org/bugs/show_bug.cgi?id=197521 197521]. <br />
<br />
<br />
Change History:<br />
<br />
Joel Hawkins 9/05/2007 Initial version<br />
<br />
== '''Overview''' ==<br />
<br />
Currently, the DC framework uses the java stack. Threading issues related to query response management delegated to response components.<br />
Proposed approach constructs call-graph trees during loading/compilation phase. Proper tree chosen by framework for execution. Root components responsible for dispatching to framework only. No knowledge required of other components (no more wiring within the component). <br />
<br />
== ''' Implementation Stages and Corporate Use Cases ''' ==<br />
<br />
Initial implementation and conversion of existing components/assemblies for iteration 6.<br />
<br />
== '''Terminologies/Acronyms''' ==<br />
<br />
The terminologies/acronyms below are commonly used throughout this document. The list below defines each term:<br />
<br />
ASSEMBLY: A collection of components that are used by the framework to either route data for storage or perform queries on stored data. <br />
<br />
ASSEMBLY DEFINITION: An XML document that describes an ASSEMBLY.<br />
<br />
ASSEMBLY DESCRIPTOR: The in memory representation of an assembly declaration.<br />
<br />
COMPONENT: A discrete element in an assembly. Components are external to the framework. <br />
<br />
ASSEMBLY COMPILER: A utility class that converts an assembly descriptor into an executable entity. <br />
<br />
CONTEXT: The runtime representation of an assembly.<br />
<br />
COMPONENT: A discrete element in an assembly. Components are external to the framework. Components come in five flavors - Sources, Sinks, Transforms, Filters, and Responses.<br />
<br />
RESPONSE COMPONENT: A tagging component that enables the framework to manage query response sets that have been filtered and/or transformed by the framework. The response component has very little processing content in terms of implementation, but plays a crucial role in enabling the framework to process query requests. <br />
<br />
RUNTIME: The host environment for assemblies.<br />
<br />
OPTIMIZATION PROXY: A dynamic component inserted by the framework to allow components to be bypassed in certain scenarios.<br />
<br />
VECTOR PROXY: A dynamic component inserted by the framework to allow components that match in type but not in cardinality to interact. See LINK to 197525 for a discussion of how buffering is supported in the framework.<br />
<br />
DYNAMIC PROGRAMMING: An optimization technique useful for computing optimal paths through acyclic directed graphs based on a 'cost' concept.<br />
<br />
<br />
==Use Cases==<br />
<br />
Direct component access.<br />
<br />
Branched query<br />
<br />
Branched collection<br />
<br />
<br />
== '''External Interfaces''' ==<br />
<br />
'''Framework Interface'''<br />
<br />
<pre><br />
@ManagedResourceCapability(namespace=IDataCollectionContext.NAMESPACE)<br />
public abstract interface IDataCollectionContext {<br />
<br />
public static final String NAMESPACE = "http://www.eclipse.org/xmlns/cosmos/1.0/Context";<br />
<br />
public static final String COSMOS_NAMESPACE = "http://www.eclipse.org/xmlns/cosmos/1.0";<br />
<br />
public static QName CONTEXT_QNAME = new QName(COSMOS_NAMESPACE,"context");<br />
public static QName NAME_QNAME = new QName(COSMOS_NAMESPACE,"name");<br />
public static QName DIRECTION_QNAME = new QName(COSMOS_NAMESPACE,"direction");<br />
public static QName OPTIMIZABLE_QNAME = new QName(COSMOS_NAMESPACE,"optimizable");<br />
<br />
@ManagedPropertyGetter<br />
String getName();<br />
<br />
@ManagedOperation<br />
void materialize() throws Exception;<br />
<br />
@ManagedOperation<br />
boolean isQueryContext();<br />
<br />
@ManagedOperation<br />
boolean isCollectionContext();<br />
<br />
@ManagedOperation<br />
void flush();<br />
<br />
@ManagedOperation<br />
public IDataSourceService getDataSource();<br />
<br />
@ManagedOperation<br />
public IDataQueryService getDataQuery();<br />
<br />
void dispatch(Object obj, IDataSourceService dispatcher) throws RuntimeException;<br />
void dispatch(Object obj, String response, IDataQueryService dispatcher) throws RuntimeException;<br />
<br />
IDataQueryResult getQueryResult();<br />
<br />
boolean isSupportedQueryResponse(String response);<br />
void addQueryResponseType(String type);<br />
String[] getQueryResponseTypes();<br />
void addQueryResult(Object obj);<br />
<br />
}<br />
</pre><br />
<br />
<br />
'''Component Interfaces'''<br />
<br />
Intermediate component interfaces reduced to tagging interfaces. <br />
<br />
<pre><br />
public interface IDataFilterService {<br />
static QName FILTER_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"filter");<br />
}<br />
</pre><br />
<br />
<pre><br />
public interface IDataTransformService {<br />
public static QName TRANSFORM_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"transform");<br />
}<br />
</pre><br />
<br />
Source, Query and Sink interfaces reduced to capability declarations and context access methods. <br />
<br />
<pre><br />
@ManagedResourceCapability(namespace="http://cosmos.eclipse.org/capabilities/query")<br />
public interface IDataQueryService {<br />
<br />
public static QName QUERY_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"query");<br />
public static String PREFIX = "query";<br />
public static String NAMESPACE_URI = "http://cosmos.eclipse.org/capabilities/query";<br />
public static String SUPPORTED_DIALECTS_URI = NAMESPACE_URI+"/getSupportedDialects";<br />
public static String SUPPORTED_RESPONSES_URI = NAMESPACE_URI+"/getSupportedResponses";<br />
public static String SUPPORTED_QUERY_URI = NAMESPACE_URI+"/supportedQuery";<br />
public static String QUERY_URI = NAMESPACE_URI+"/query";<br />
public static String PAGE_QUERY_URI = NAMESPACE_URI+"/pageQuery";<br />
<br />
public static final QName DIALECTS_QNAME = <br />
new QName(NAMESPACE_URI, "getSupportedDialects", PREFIX);<br />
<br />
<br />
@ManagedOperation(namespace=NAMESPACE_URI)<br />
String[] getSupportedDialects();<br />
<br />
@ManagedOperation(namespace=NAMESPACE_URI)<br />
String[] getSupportedResponses();<br />
<br />
@ManagedOperation(namespace=NAMESPACE_URI)<br />
boolean supportedQuery(String dialect, String response); <br />
<br />
@ManagedOperation(namespace=NAMESPACE_URI)<br />
IDataQueryResult query(String dialect, String response, String queryString, String dataSource) throws Exception;<br />
<br />
@ManagedOperation(namespace=NAMESPACE_URI)<br />
IDataQueryResult pageQuery(String dialect, String response, String queryString, String dataSource, int max, int start) throws Exception;<br />
<br />
void setContext(IDataCollectionContext context);<br />
<br />
}<br />
<br />
</pre><br />
<br />
<br />
<pre><br />
public interface IDataSinkService {<br />
<br />
public static QName SINK_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"sink");<br />
static QName DATA_FLOW_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"dataflow");<br />
static QName DATA_SOURCE_TYPE_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"type");<br />
static QName DATA_KEY_SET_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"keyset");<br />
static QName DATA_KEY_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"key");<br />
<br />
public DimensionSet getDimensionSet(); //Needs revisting based on DataBroker interaction requirements<br />
public void setDataSet(DataSet ds); //Needs revisting based on DataBroker interaction requirements<br />
<br />
}<br />
</pre><br />
<br />
<pre><br />
public interface IDataSourceService {<br />
<br />
static QName SOURCE_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"source");<br />
static QName FACTORY_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"factory");<br />
static QName DATA_SOURCE_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"datasource");<br />
<br />
/*<br />
* The following 6 methods are exposed as management capabilities <br />
* by the abstract implementation of this interface. See <br />
* org.eclipse.cosmos.dc.common.api.impl.AbstractDataSource<br />
*/<br />
boolean connect() throws Exception;<br />
boolean run() throws Exception;<br />
boolean disconnect() throws Exception;<br />
boolean cancel() throws Exception;<br />
boolean pause() throws Exception;<br />
boolean resume() throws Exception;<br />
<br />
DataSource getDataSource(); //Needs revisting based on DataBroker interaction requirements<br />
<br />
void setContext(IDataCollectionContext context);<br />
<br />
}<br />
</pre><br />
<br />
Response service provides static information to framework to allow management of response collections, removing that responsibility from the component level.<br />
<br />
<pre><br />
public interface IDataResponseService {<br />
<br />
public static QName RESPONSE_QNAME = new QName(IDataCollectionContext.COSMOS_NAMESPACE,"response");<br />
<br />
public String[] getResponseTypes();<br />
<br />
public Class getClassForType(String type);<br />
<br />
void setContext(IDataCollectionContext context);<br />
<br />
}<br />
</pre><br />
<br />
'''Conventions'''<br />
<br />
Naming conventions used by reflection during compilation.<br />
<br />
"public void dispatch*(type)" for root components (query and source). - invoked by the component to dispatch data into the assembly. Introspected by the assembly to construct callgraphs.<br />
<br />
"public type filter*(type)" for filter components<br />
<br />
"public type transform*(type)" for transform components<br />
<br />
"public void store*(type)" for sink components<br />
<br />
"public void response*(type)" for response components<br />
<br />
Methods must be declared by component class. <br />
<br />
For array types and collections, the types are matched by the base type. Collections be declared using generics in order to support type-safe handling. See LINK TO 197525 for a discussion of how collections and arrays are handled by the framework.<br />
<br />
== '''Framework Implementation Details''' ==<br />
<br />
Assumptions:<br />
*Assemblies are singletons. <br />
*Components are thread safe. <br />
<br />
Discussion of compilation steps:<br />
<br />
runtime loads assembly: parses assembly documentation.<br />
<br />
runtime verifies that assembly with same identifier is not active<br />
runtime materializes assembly<br />
creates context instance for assembly<br />
compiles context using ContextCompiler<br />
<br />
compiler creates component tree<br />
compiler extracts dispatch methods from root component<br />
compiler computes possible call graphs through assembly based on method signatures and conventions. Computation includes insertion of proxies where appropriate (either for vector considerations or optimzation possibilities).<br />
if root is query, compiler duplicates root call graphs for each supported response type, adjusting costs of responses to allow optimisation step to compute best path for each supported response type.<br />
compiler computes optimum path for each root dispatch method, culling suboptimal paths using a top-down dynamic programming algorithm. Culling is performed across all child components, choosing only the best path. <br />
if root is query, remove all duplicated paths that did not fathom. <br />
<br />
Discussion of runtime steps<br />
<br />
Query <br />
Usage of ThreadLocal in data management<br />
<br />
General<br />
Depth-first traversal of call graph<br />
Dispatch to framework using context<br />
Abstract class wrappers<br />
<br />
== '''Notes''' ==<br />
Declarative support for culling within component vs global culling across all components for non-query case.<br />
Management control over buffer size?<br />
Configurable optimization controls? (Vary costing of vectorization/optimzation proxy/component types)<br />
Debugging of compilation process<br />
Error reporting - operational status based on 'wiring'.<br />
<br />
Sink methods - support for dataset registration... need to flesh out databroker interaction here (back to instance data again)<br />
Source methods - support for datasource registration... need to flesh out databroker interaction here (back to instance data again)<br />
----<br />
[[Category:COSMOS_Bugzilla_Designs]]</div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=COSMOS_Design_197525&diff=49403COSMOS Design 1975252007-09-06T14:56:05Z<p>Joel.hawkins.compuware.com: </p>
<hr />
<div>'''Design Discussion for [https://bugs.eclipse.org/bugs/show_bug.cgi?id=197525 197525]: Buffering data in the data assembly pipeline '''<br />
<br />
== '''Data Buffering in COSMOS DC ''' ==<br />
<br />
This design document addresses COSMOS Bugzilla enhancement request [https://bugs.eclipse.org/bugs/show_bug.cgi?id=197525 197525]. <br />
<br />
<br />
Change History:<br />
<br />
Joel Hawkins 9/05/2007 Initial version<br />
<br />
== '''Overview''' ==<br />
<br />
<br />
For import scenarios like Log Shredding, it is natural to take batch-oriented approach for managing data assemblies. Currently, there is no support in the framework for handling data in batches. The framework must support, and indeed prefer, to handle data in bulk where possible. Furthermore, the size of any internal buffers used to implement batch behaviors should be tunable on an assembly level, and a facility must be provided to ensure that no data is left stranded in any internal buffers. <br />
<br />
== ''' Related Issues ''' ==<br />
Link to 521 - insertion of proxy nodes (vectorization vs optimization)<br />
Link to 833 - schema - attribute on context (buffersize)<br />
<br />
== ''' Implementation Stages and Corporate Use Cases ''' ==<br />
<br />
Support for buffering will be delivered in iteration 6.<br />
Timer-based flushing of collecting assemblies will be added in iteration 7 (unless I get enough free time to implement it for iteration 6).<br />
<br />
== '''Terminologies/Acronyms''' ==<br />
<br />
The terminologies/acronyms below are commonly used throughout this document. The list below defines each term:<br />
<br />
ASSEMBLY: A collection of components that are used by the framework to either route data for storage or perform queries on stored data.<br />
<br />
COMPONENT: A discrete element in an assembly. Components are external to the framework.<br />
<br />
VECTOR: In this case, a general term to describe data provided either as an array or as some implementation of a java Collection.<br />
<br />
VECTOR PROXY: A "component" injected by the framework in order to support converting to and from a VECTOR or to and from mismatched VECTOR implementations.<br />
<br />
==Use Cases==<br />
<br />
'''Use Case 1. Batch Insertion '''''<br />
<br />
The current End 2 End demo of COSMOS involves a component that reads Apache Tomcat logs and converts them into CBEs. The CBEs are then persisted into a Derby database. These CBEs. The CBE source component produces a single CBE at a time. The CBE sink component is modified to consume a collection of CBEs, in addition to a single CBE at a time. The Assembly specifies that optimization for the CBESink component is allowed, and the framework creates the assembly such that CBEs are collected into batches, and the collection-based store method on the CBESink is invoked.<br />
<br />
'''Use Case 2. Batch results'''<br />
<br />
Query responses are inherently batch-oriented. However, when intervening filters and/or transformations are involed that may not support batch invocation semantics, the framework will create an assembly such that the batch results are passed serially through the intervening components and re-batched for return. The pipeline will be flushed prior to return to ensure that any remaining objects that weren't flushed due to buffersize restrictions reach the final response.<br />
<br />
== '''External Interfaces''' ==<br />
<br />
The 'flush()' method will be added to the DataCollection interface. This method will be exposed externally as an operation on the DataCollection capability, and will be available internally to any component within the assembly that has access to the context.<br />
<br />
<pre><br />
@ManagedResourceCapability(namespace=IDataCollectionContext.NAMESPACE)<br />
public abstract interface IDataCollectionContext {<br />
<br />
... code removed for clarity <br />
<br />
@ManagedOperation<br />
void flush();<br />
<br />
... code removed for clarity <br />
<br />
}<br />
<br />
</pre><br />
<br />
The "buffersize" attribute will be added to the "context " assembly element. This attribute will override the default buffer size for the assembly. The default buffersize can be set by the System property org.eclipse.cosmos.dc.buffersize, and will default to 20.<br />
<br />
<pre><br />
<complexType name="ContextType"><br />
<choice><br />
<element ref="tns:query"></element><br />
<element ref="tns:source"></element><br />
<element ref="tns:channel"></element><br />
<element ref="tns:multiplex"></element><br />
</choice><br />
<attribute name="name" type="string" use="required"></attribute><br />
<attribute name="id" type="anyURI" use="required"></attribute><br />
<attribute name="buffersize" type="int"></attribute><br />
</complexType><br />
<br />
</pre><br />
<br />
Here is a sample assembly descriptor with buffersize specified.<br />
<br />
<pre><br />
<?xml version="1.0" encoding="UTF-8"?><br />
<!--<br />
* Test configuration for outbound pipeline<br />
--><br />
<cosmos:context xmlns:cosmos="http://www.eclipse.org/xmlns/cosmos/1.0"<br />
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <br />
xmlns:test="http://www.eclipse.org/xmlns/cosmos/test/1.0 org/eclipse/cosmos/dc/tests/xml/configs/CosmosTestBinding.xsd " <br />
xsi:schemaLocation="http://www.eclipse.org/xmlns/cosmos/1.0 CosmosDataCollectionAssembly.xsd " <br />
name="TestSource" id="http://MySpecialURI/TestSource" buffersize="100"><br />
<cosmos:source factory="TestSourceFactory" optimizable="true"><br />
<test:binding/><br />
<cosmos:transform factory="TestTransformFactory" optimizable="false"><br />
<test:binding/><br />
</cosmos:transform><br />
</cosmos:source> <br />
</cosmos:context><br />
</pre><br />
<br />
'''Conventions'''<br />
<br />
<br />
== '''Framework Implementation Details''' ==<br />
<br />
Vector Proxy insertion rules:<br />
* vector(array or collection) to scalar <br />
* scalar to vector(array or collection) <br />
* array to collection <br />
* collection to array <br />
<br />
Costing of proxies during assembly compilation<br />
* vector(array or collection) to scalar - cost=2 (discourage)<br />
* scalar to vector(array or collection) - cost=-1 (prefer)<br />
* array to collection - cost=1<br />
* collection to array - cost=1<br />
<br />
Batch trigger size<br />
* default to 20<br />
* global override as system property org.eclipse.cosmos.dc.buffersize<br />
* specified in context element of schema<br />
<br />
Flushing the pipeline<br />
* for inbound cases, the pipeline is flushed when the batch limit is hit<br />
* for outbound cases, the pipeline is flushed once the page size has been hit or the result set has been exhausted<br />
* programatic control of pipeline flushing is exposed in the context interface. Annotated as manageable.<br />
<br />
== '''Notes''' ==<br />
<br />
<br />
----<br />
[[Category:COSMOS_Bugzilla_Designs]]</div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=COSMOS_Design_197833&diff=49382COSMOS Design 1978332007-09-06T13:30:50Z<p>Joel.hawkins.compuware.com: New page: '''Design Discussion for [https://bugs.eclipse.org/bugs/show_bug.cgi?id=197833 197833]: Need an XML schema for the assembly XML ''' == '''XML Schema for COSMOS DC framework''' == This de...</p>
<hr />
<div>'''Design Discussion for [https://bugs.eclipse.org/bugs/show_bug.cgi?id=197833 197833]: Need an XML schema for the assembly XML '''<br />
<br />
== '''XML Schema for COSMOS DC framework''' ==<br />
<br />
This design document addresses COSMOS Bugzilla enhancement request [https://bugs.eclipse.org/bugs/show_bug.cgi?id=197833 197833]. <br />
<br />
<br />
Change History:<br />
<br />
Joel Hawkins 9/05/2007 Initial version<br />
<br />
== '''Overview''' ==<br />
<br />
The COSMOS Data Collection component needs an XML Schema definition for constructing and validating Assembly specifications. The creation of such a schema well enable tooling as well as providing an additional mechanism to ensure that only correctly specified assemblies are deployed. <br />
<br />
Some concern has been raised over the complexity of the implicit assembly construction, namely the fact that component relationships are specified using a nesting structure. While this nested structure allows for very general specification of component relationships, for many cases a simpler - more linear model is appropriate. COSMOS should support both models in order to ease adoption without sacrificing power and flexibility.<br />
<br />
== ''' Implementation Stages and Corporate Use Cases ''' ==<br />
<br />
Convert to the new Schema in iteration 6.<br />
Implement tooling under the Management Enablement project at some point in the future.<br />
<br />
== '''Terminologies/Acronyms''' ==<br />
<br />
The terminologies/acronyms below are commonly used throughout this document. The list below defines each term:<br />
<br />
PIPELINED ASSEMBLY: An assembly specified by a root component and a linear sequence of components forming one single straight path through the assembly<br />
<br />
MULTIPLEXED PIPELINED ASSEMBLY: An assembly specified by a root component and a set channels, each comprised of linear sequence of components forming single straight paths through the assembly<br />
<br />
NESTED ASSEMBLY: An assembly specified by a root component which an arbitrary number of child components, each of which may contain an arbitrary number of child components, ad nauseum. <br />
<br />
==Use Cases==<br />
<br />
'''Use Case 1. Nested Descriptors'''''<br />
<br />
<pre><br />
<?xml version="1.0" encoding="UTF-8"?><br />
<!--<br />
* Test configuration for outbound pipeline<br />
--><br />
<cosmos:context xmlns:cosmos="http://www.eclipse.org/xmlns/cosmos/1.0"<br />
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <br />
xmlns:test="http://www.eclipse.org/xmlns/cosmos/test/1.0 org/eclipse/cosmos/dc/tests/xml/configs/CosmosTestBinding.xsd " <br />
xsi:schemaLocation="http://www.eclipse.org/xmlns/cosmos/1.0 CosmosDataCollectionAssembly.xsd " <br />
name="TestNestedQuery" id="http://MySpecialURI/TestNestedQuery"><br />
<query cosmos:factory="TestQuery" cosmos:optimizable="true"><br />
<filter cosmos:factory="TestFilter" cosmos:optimizable="false"><br />
<test:binding/><br />
<transform cosmos:factory="TestTransform" cosmos:optimizable="false"><br />
<test:binding/><br />
<response cosmos:factory="TestResponse" cosmos:optimizable="true"><br />
<test:binding/><br />
</response><br />
</transform><br />
<transform cosmos:factory="TestTransformBranch" cosmos:optimizable="false"><br />
<test:binding/><br />
<response cosmos:factory="TestResponse" cosmos:optimizable="true"><br />
<test:binding/><br />
</response><br />
</transform><br />
</filter><br />
</query> <br />
</context><br />
</pre><br />
<br />
'''Use Case 2. PipeLine Descriptors'''<br />
<br />
Link to Hubert's discussion of pipelines.<br />
<br />
<pre><br />
<?xml version="1.0" encoding="UTF-8"?><br />
<!--<br />
* Test configuration for outbound pipeline<br />
--><br />
<cosmos:context xmlns:cosmos="http://www.eclipse.org/xmlns/cosmos/1.0"<br />
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <br />
xmlns:test="http://www.eclipse.org/xmlns/cosmos/test/1.0 org/eclipse/cosmos/dc/tests/xml/configs/CosmosTestBinding.xsd " <br />
xsi:schemaLocation="http://www.eclipse.org/xmlns/cosmos/1.0 CosmosDataCollectionAssembly.xsd " <br />
name="TestChannel" id="http://MySpecialURI/TestChannel"><br />
<cosmos:channel><br />
<cosmos:query factory="TestQueryFactory" optimizable="true"><br />
<test:binding/><br />
</cosmos:query><br />
<cosmos:transform factory="TestTransformFactory" optimizable="false"><br />
<test:binding/><br />
</cosmos:transform><br />
<cosmos:response factory="TestResponseFactory" optimizable="true"><br />
<test:binding/><br />
</cosmos:response><br />
</cosmos:channel> <br />
</cosmos:context><br />
</pre><br />
<br />
<pre><br />
<?xml version="1.0" encoding="UTF-8"?><br />
<!--<br />
* Test configuration for outbound pipeline<br />
--><br />
<cosmos:context xmlns:cosmos="http://www.eclipse.org/xmlns/cosmos/1.0"<br />
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" <br />
xmlns:test="http://www.eclipse.org/xmlns/cosmos/test/1.0 org/eclipse/cosmos/dc/tests/xml/configs/CosmosTestBinding.xsd " <br />
xsi:schemaLocation="http://www.eclipse.org/xmlns/cosmos/1.0 CosmosDataCollectionAssembly.xsd " <br />
name="TestMultiplex" id="http://MySpecialURI/TestMultiplex"><br />
<cosmos:multiplex><br />
<cosmos:source factory="TestSourceFactory" optimizable="true"><br />
<test:binding/><br />
</cosmos:source><br />
<cosmos:channel><br />
<cosmos:transform factory="TestTransformFactory" optimizable="false"><br />
<test:binding/><br />
</cosmos:transform><br />
<cosmos:sink factory="TestSinkFactory" optimizable="true"><br />
<test:binding/><br />
</cosmos:sink><br />
</cosmos:channel><br />
<cosmos:channel><br />
<cosmos:filter factory="TestFilterFactory" optimizable="false"><br />
<test:binding/><br />
</cosmos:filter><br />
<cosmos:sink factory="TestSinkFactory" optimizable="true"><br />
<test:binding/><br />
</cosmos:sink><br />
</cosmos:channel><br />
</cosmos:multiplex> <br />
</cosmos:context><br />
</pre><br />
<br />
== '''External Interfaces''' ==<br />
<br />
The following is the proposed Schema:<br />
<br />
<pre><br />
<?xml version="1.0" encoding="UTF-8"?><br />
<schema xmlns="http://www.w3.org/2001/XMLSchema"<br />
targetNamespace="http://www.eclipse.org/xmlns/cosmos/1.0"<br />
xmlns:tns="http://www.eclipse.org/xmlns/cosmos/1.0"<br />
elementFormDefault="qualified"><br />
<br />
<!-- The base type must specify a binding. Sadly, XML Schema does not allow us to place <br />
restrictions on the 'any' element, therefore we can't enforce the inclusion of a binding<br />
element from an arbitrary schema. <br />
--><br />
<include schemaLocation="CosmosDataCollectionTypes.xsd"></include><br />
<br />
<complexType name="ComponentBaseType" abstract="true"><br />
<sequence><br />
<any minOccurs="1" maxOccurs="1" namespace="##other"<br />
processContents="lax"><br />
</any><br />
<element ref="tns:ComponentBase" maxOccurs="unbounded"<br />
minOccurs="0"><br />
</element><br />
</sequence><br />
<attribute name="factory" use="required" type="string"></attribute><br />
<attribute name="optimizable" type="string" default="true"></attribute><br />
</complexType><br />
<br />
<complexType name="SourceType"><br />
<complexContent><br />
<extension base="tns:ComponentBaseType"><br />
<br />
<choice><br />
<element ref="tns:dataSource"></element><br />
<element ref="tns:dataSourceRef"></element><br />
</choice><br />
</extension><br />
</complexContent><br />
</complexType><br />
<br />
<complexType name="FilterType"><br />
<complexContent><br />
<extension base="tns:ComponentBaseType"></extension><br />
</complexContent><br />
</complexType><br />
<br />
<complexType name="SinkType"><br />
<complexContent><br />
<restriction base="tns:ComponentBaseType"><br />
<sequence><br />
<any minOccurs="1" maxOccurs="1" namespace="##other"<br />
processContents="lax"><br />
</any><br />
<br />
<choice><br />
<element ref="tns:keySet"></element><br />
<element ref="tns:keySetRef"></element><br />
</choice><br />
</sequence><br />
<attribute name="factory" type="string"<br />
use="required"><br />
</attribute><br />
</restriction><br />
</complexContent><br />
</complexType><br />
<br />
<complexType name="TransformType"><br />
<complexContent><br />
<extension base="tns:ComponentBaseType"></extension><br />
</complexContent><br />
</complexType><br />
<br />
<complexType name="ResponseType"><br />
<complexContent><br />
<restriction base="tns:ComponentBaseType"><br />
<sequence><br />
<any minOccurs="1" maxOccurs="1" namespace="##other"<br />
processContents="lax"><br />
</any><br />
</sequence><br />
<attribute name="factory" type="string"<br />
use="required"><br />
</attribute><br />
</restriction><br />
</complexContent><br />
</complexType><br />
<br />
<complexType name="QueryType"><br />
<complexContent><br />
<extension base="tns:ComponentBaseType"></extension><br />
</complexContent><br />
</complexType><br />
<br />
<complexType name="ContextType"><br />
<choice><br />
<element ref="tns:query"></element><br />
<element ref="tns:source"></element><br />
<element ref="tns:channel"></element><br />
<element ref="tns:multiplex"></element><br />
</choice><br />
<attribute name="name" type="string" use="required"></attribute><br />
<attribute name="id" type="anyURI" use="required"></attribute><br />
<attribute name="buffersize" type="int"></attribute><br />
</complexType><br />
<br />
<br />
<complexType name="MutliplexType"><br />
<choice><br />
<sequence><br />
<element ref="tns:source" /><br />
<element name="channel"<br />
type="tns:MultiplexSourceChannelType" minOccurs="1"<br />
maxOccurs="unbounded" /><br />
</sequence><br />
<sequence><br />
<element ref="tns:query" /><br />
<element name="channel"<br />
type="tns:MultiplexQueryChannelType" minOccurs="1"<br />
maxOccurs="unbounded" /><br />
</sequence><br />
</choice><br />
</complexType><br />
<br />
<complexType name="MultiplexSourceChannelType"><br />
<sequence><br />
<element ref="tns:transform" maxOccurs="1" minOccurs="0"></element><br />
<element ref="tns:filter" maxOccurs="1" minOccurs="0"></element><br />
<element ref="tns:transform" maxOccurs="1" minOccurs="0"></element><br />
<element ref="tns:sink" maxOccurs="1" minOccurs="0"></element><br />
</sequence><br />
</complexType><br />
<br />
<complexType name="MultiplexQueryChannelType"><br />
<sequence><br />
<element ref="tns:transform" maxOccurs="1" minOccurs="0"></element><br />
<element ref="tns:filter" maxOccurs="1" minOccurs="0"></element><br />
<element ref="tns:transform" maxOccurs="1" minOccurs="0"></element><br />
<element ref="tns:response" maxOccurs="1" minOccurs="1"></element><br />
</sequence><br />
</complexType><br />
<br />
<complexType name="ChannelType"><br />
<sequence><br />
<choice><br />
<sequence><br />
<element ref="tns:source" maxOccurs="1"<br />
minOccurs="1"><br />
</element><br />
<element ref="tns:transform" maxOccurs="1"<br />
minOccurs="0"><br />
</element><br />
<element ref="tns:filter" maxOccurs="1"<br />
minOccurs="0"><br />
</element><br />
<element ref="tns:transform" maxOccurs="1"<br />
minOccurs="0"><br />
</element><br />
<element ref="tns:sink" maxOccurs="1"<br />
minOccurs="0"><br />
</element><br />
</sequence><br />
<sequence><br />
<element ref="tns:query" maxOccurs="1"<br />
minOccurs="1"><br />
</element><br />
<element ref="tns:transform" maxOccurs="1"<br />
minOccurs="0"><br />
</element><br />
<element ref="tns:filter" maxOccurs="1"<br />
minOccurs="0"><br />
</element><br />
<element ref="tns:transform" maxOccurs="1"<br />
minOccurs="0"><br />
</element><br />
<element ref="tns:response" maxOccurs="1"<br />
minOccurs="0"><br />
</element><br />
</sequence><br />
</choice><br />
</sequence><br />
</complexType><br />
<br />
<element name="filter" type="tns:FilterType"<br />
substitutionGroup="tns:ComponentBase"><br />
</element><br />
<br />
<element name="query" type="tns:QueryType"></element><br />
<br />
<element name="response" type="tns:ResponseType"<br />
substitutionGroup="tns:ComponentBase"><br />
</element><br />
<br />
<element name="sink" type="tns:SinkType"<br />
substitutionGroup="tns:ComponentBase"><br />
</element><br />
<br />
<element name="source" type="tns:SourceType"></element><br />
<br />
<element name="transform" type="tns:TransformType"<br />
substitutionGroup="tns:ComponentBase"><br />
</element><br />
<br />
<element name="context" type="tns:ContextType"></element><br />
<br />
<element name="ComponentBase" type="tns:ComponentBaseType"></element><br />
<br />
<element name="channel" type="tns:ChannelType"></element><br />
<br />
<element name="multiplex" type="tns:MutliplexType"></element><br />
<br />
</schema><br />
</pre><br />
<br />
== '''Framework Implementation Details''' ==<br />
<br />
Assembly parsing is handled by the runtime, and uses the XmlUtils.createDocument(InputStream stream) method. This method does not do schema validation. The runtime should support a configuration options to do schema validation on loading, which may be defaulted to 'false' initially.<br />
<br />
Assembly loading is handled in the AbstractContext.load(Document doc) method. This method will be extended to handle conversion of the Pipelined and Multiplex Pipelined specifications into the same internal format that is used by the existing Nested assembly type, as both cases are just special forms of a generic tree structure.<br />
<br />
== '''Notes''' ==<br />
<br />
Support for declarative registration? <br />
How to handle registration of data sets/etc. - use SML fragments? <br />
Interaction with DataBroker design<br />
Default setting for schema validation.<br />
<br />
----<br />
[[Category:COSMOS_Bugzilla_Designs]]</div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=CosmosDataCollectionComponent&diff=49381CosmosDataCollectionComponent2007-09-06T13:30:06Z<p>Joel.hawkins.compuware.com: </p>
<hr />
<div>[[COSMOS|COSMOS Main Page]] > <br />
= Data Collection and Normalization =<br />
<br />
== Scope and Mission ==<br />
<br />
The Data Collection and Normalization component will implement a data collection framework as described on pages 20 and 21 of the COSMOS project creation review pdf [http://www.eclipse.org/proposals/cosmos/COSMOS%20Project%20Creation%20Review-v1.0a.pdf here].<br />
<br />
The initial scope of the Data Collection and Normalization component supports the <br />
[[COSMOS Use Cases|Use Cases]]<br />
that the COSMOS project is defining to demonstrate the value of SML throughout the application lifecycle. It will accept managent data from the instrumentation produced by the COSMOS [[CosmosBuildToManageComponent| Build to manage]] <br />
component and provide data normalization and persistance and a query API to support its consumption by the COSMOS [[CosmosDataReportingComponent| Data Reporting]] <br />
component.<br />
<br />
== Tactical Plan == <br />
Much of the initial work of the data collection component will be done in cooperation with the TPTP project. To facilitate the timely creation of a demonstrable implementation, the data collection component will leverage key TPTP technologies such as the Common Base Event (CBE) format, TPTP agents such as JMX and the Generic Log Adapter (GLA), and the Agent Controller.<br />
<br />
See also the prototype proposal in the Resources section below.<br />
<br />
== Architectural Vision ==<br />
<br />
=== Persistence API ===<br />
<br />
The framework will provide an extension point for data persistance. Each supported data type will be consumed by a persistor that supports persisting a particular data format into its own database table or other data store.<br />
<br />
Initially, persistors will be provided for the EMF models that TPTP currently supports.<br />
<br />
<br />
=== Data Collection Control API ===<br />
<br />
A WSDM interface will be provided for the purpose of configuring the data collection agents.<br />
<br />
In the longer term, this interface will be usable to manage the monitored infrastructure components.<br />
<br />
=== Adapters for Data Collection agents into Persistence API ===<br />
<br />
The framework will provide an extension point for data collection agent adapters. One possible approach is to provide a service that connects agent adaptors to an appropriate data persistor based on the data type supported by the adaptor such as CBE or WEF. A provision to specify these connections declaratively is required, but they could also be constructed dynamically via a WSDM interface.<br />
<br />
The connection service should specifically support the ability to inject interceptors between the agent adapters and the data persistors.<br />
<br />
Initial adapters will include log, statistical, and perhaps trace adapters but the framework will be generalized so it can be extended to support any additional models as required.<br />
<br />
=== Query API ===<br />
<br />
The query API will provide a web service interface to the data store(s). <br />
<br />
Its binding will be constructed in a manner analogous to the Data Collection adapters where extensions can be created to implement any desired query mechanism without requiring dependence on the type or location of the underlying data store.<br />
<br />
Multiple web services will be provided to allow the consumer to select appropriate query semantics.<br />
<br />
The initial targets are SQL and / or XPath.<br />
<br />
[[COSMOSTPTPQuereryIntrfaceNotes]]<br />
<br />
[[COSMOSQueryInterfaceInitialDesign]]<br />
<br />
=== Database Schema ===<br />
<br />
Each data collection adapter will define the schema for its datastore. A reasonable minimum expectation is that each database will be keyed by timestamp and the unique ID of the managed resource.<br />
<br />
The initial target is [http://en.wikipedia.org/wiki/Apache_Derby Derby], with support for MySQL and proprietary databases later. An attempt will be made to avoid proprietary SQL to permit a wide choice of database engines.<br />
<br />
=== Proposed Technology Stack ===<br />
This diagram shows one possible implementation technology stack for COSMOS data collection<br />
<br />
The data collector will be extended with bundle fragments that implement data collection adapters, persistors and query interfaces. <br />
<br />
Data Collection Adaptors adapt an information source into a common format supported by a persistor.<br />
<br />
Persistors accept information of a particular type such as CBE and provide a persistance service for this data type.<br />
<br />
Query Adaptors adapt queries in a language such as SQL or XPATH to the persistent data store.<br />
<br />
{| border="1"<br />
| || WSDM (Muse)<br />
|-<br />
| || SOAP (Axis)<br />
|-<br />
| || Data Collection Bundle<br />
|-<br />
| DC Adaptor || Persistor || Query <br />
|-<br />
| || OSGi (Equinox)<br />
|}<br />
<br />
<br />
== Common Agent Infrastructure ==<br />
Discussion on Common Agent Infrastructure<br />
<br />
* No formal agent infrastructure currently in scope<br />
** Root level question: Do we want this in COSMOS?<br />
<br />
* COSMOS needs to have some of this to be self hosting<br />
* Tie in BtM<br />
<br />
*<br />
<br />
== Open Issues == <br />
* Which components require alternative implementations in support of embedded devices<br />
* Which components must support Java 1.4<br />
<br />
== Resources ==<br />
<br />
TPTP [[TPTPModel|model]] and [[TPTP_data_persistence_layer|data persistence ]] ([http://dev.eclipse.org/viewcvs/index.cgi/platform/org.eclipse.tptp.platform.models/src-dms/?root=TPTP_Project TPTP DMS CVS link])<br />
<br />
Initial prototype [[COSMOSInitalPrototype|proposal]]<br />
<br />
DataCollector [[DCInitalPrototype|prototype]]<br />
<br />
[[COSMOSPersisteceFrameworks|Persistence Frameworks Discussion]]<br />
<br />
[[COSMOSDataCollectorEnvironment|How to set up your Eclipse for working on DataCollection]]<br />
<br />
[[COSMOSDataCollectionEnd2End|Setting up a tomcat instance to working with the COSMOS End to End example]]<br />
<br />
[[COSMOS_CBE_RDB | Running the Data Collection w/CBEs]]<br />
<br />
[[Data Collection Q&A]]<br />
<br />
[[COSMOSEnd2EndSample | Instructions for running the end-to-end sample ]]<br />
<br />
<br />
[[ COSMOS#Architecture | back to home]]<br />
<br />
<br />
== Design Documents & Discussions In Progress ==<br />
<br />
[[COSMOS_DC_Design_Discussions|DC Design Improvements]]<br />
<br />
[[Data_Manager|Discussions around the Data Manager Design]]<br />
<br />
[[COSMOS_Design_193420|193420: Create simple stand alone example of the data collection framework]]<br />
[https://bugs.eclipse.org/bugs/show_bug.cgi?id=193420 193420]<br />
<br />
[[COSMOS_Design_197867|197867: Need to design and implement the COSMOS DC Data Broker]]<br />
[https://bugs.eclipse.org/bugs/show_bug.cgi?id=197867 197867]<br />
<br />
[[COSMOS_Design_197868|197868: Need to design and implement the COSMOS DC Management Domain]]<br />
[https://bugs.eclipse.org/bugs/show_bug.cgi?id=197868 197868]<br />
<br />
[[COSMOS_Design_197869|197869: Need to design and implement the COSMOS DC Service Broker]]<br />
[https://bugs.eclipse.org/bugs/show_bug.cgi?id=197869 197869]<br />
<br />
[[COSMOS_Design_197870|197870: Need to design and implement the COSMOS DC Client APIs]]<br />
[https://bugs.eclipse.org/bugs/show_bug.cgi?id=197870 197870]<br />
<br />
[[COSMOS_Design_197521|197521: Component implementation - separating framework vs. extension code]]<br />
[https://bugs.eclipse.org/bugs/show_bug.cgi?id=197521 197521]<br />
<br />
[[COSMOS_Design_197525|197525: Buffering data in the data assembly pipeline]]<br />
[https://bugs.eclipse.org/bugs/show_bug.cgi?id=197521 197521]<br />
<br />
[[COSMOS_Design_197833|197833: Need an XML schema for the assembly XML]]<br />
[https://bugs.eclipse.org/bugs/show_bug.cgi?id=197833 197833]</div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=COSMOS_Design_197525&diff=49292COSMOS Design 1975252007-09-05T18:41:52Z<p>Joel.hawkins.compuware.com: </p>
<hr />
<div>'''Design Discussion for [https://bugs.eclipse.org/bugs/show_bug.cgi?id=197525 197525]: Buffering data in the data assembly pipeline '''<br />
<br />
== '''Data Buffering in COSMOS DC ''' ==<br />
<br />
This design document addresses COSMOS Bugzilla enhancement request [https://bugs.eclipse.org/bugs/show_bug.cgi?id=197525 197525]. <br />
<br />
<br />
Change History:<br />
<br />
Joel Hawkins 9/05/2007 Initial version<br />
<br />
== '''Overview''' ==<br />
<br />
No support for buffering by framework. All buffering must be done and supported by components. <br />
<br />
== ''' Related Issues ''' ==<br />
Link to 521<br />
<br />
== ''' Implementation Stages and Corporate Use Cases ''' ==<br />
<br />
== '''Terminologies/Acronyms''' ==<br />
<br />
The terminologies/acronyms below are commonly used throughout this document. The list below defines each term:<br />
<br />
COMPONENT: component definition<br />
<br />
BINDING SERVICE: binding service definition<br />
<br />
CONTEXT: context definition<br />
<br />
VECTOR PROXY: Vector proxy definition<br />
<br />
==Use Cases==<br />
<br />
'''Use Case 1. Batch Insertion '''''<br />
<br />
A Broker invokes the "registration" operation of the Management Domain, providing the following information: <br />
<br />
* EPR for the Broker<br />
* Name of the Broker <br />
* Classification or Type of the Broker (Data or Service)<br />
<br />
Management Domain populates its internal registry with the information about the Broker <br />
<br />
Management Domain changes the state of the Broker to online and updates the timestamp <br />
<br />
If the Broker is already registered with the Management Domain, the Broker invokes the "ping" operation, which updates the timestamp in the Management Domain registry <br />
<br />
<br />
'''Use Case 2. Batch results'''<br />
<br />
* A Broker invokes the deregister operation of the Management Domain, providing the Broker name as a parameter.<br />
* the Management Domain removes the registration entry for the Broker from its internal registry.<br />
<br />
<br />
== '''External Interfaces''' ==<br />
<br />
'''Framework Interface'''<br />
<br />
Include code snippet<br />
<br />
<br />
'''Component Interfaces'''<br />
<br />
Include code snippets<br />
<br />
'''Conventions'''<br />
<br />
Naming expectations used by reflection during compilation.<br />
<br />
== '''Framework Implementation Details''' ==<br />
<br />
Discussion of compilation steps and runtime interactions<br />
<br />
== '''Notes''' ==<br />
<br />
<br />
----<br />
[[Category:COSMOS_Bugzilla_Designs]]</div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=COSMOS_Design_197525&diff=49291COSMOS Design 1975252007-09-05T18:40:44Z<p>Joel.hawkins.compuware.com: New page: '''Design Discussion for [https://bugs.eclipse.org/bugs/show_bug.cgi?id=197525 197525]: Buffering data in the data assembly pipeline ''' == '''Separation of Concerns for COSMOS DC framewo...</p>
<hr />
<div>'''Design Discussion for [https://bugs.eclipse.org/bugs/show_bug.cgi?id=197525 197525]: Buffering data in the data assembly pipeline '''<br />
<br />
== '''Separation of Concerns for COSMOS DC framework''' ==<br />
<br />
This design document addresses COSMOS Bugzilla enhancement request [https://bugs.eclipse.org/bugs/show_bug.cgi?id=197525 197525]. <br />
<br />
<br />
Change History:<br />
<br />
Joel Hawkins 9/05/2007 Initial version<br />
<br />
== '''Overview''' ==<br />
<br />
No support for buffering by framework. All buffering must be done and supported by components. <br />
<br />
== ''' Related Issues ''' ==<br />
Link to 521<br />
<br />
== ''' Implementation Stages and Corporate Use Cases ''' ==<br />
<br />
== '''Terminologies/Acronyms''' ==<br />
<br />
The terminologies/acronyms below are commonly used throughout this document. The list below defines each term:<br />
<br />
COMPONENT: component definition<br />
<br />
BINDING SERVICE: binding service definition<br />
<br />
CONTEXT: context definition<br />
<br />
VECTOR PROXY: Vector proxy definition<br />
<br />
==Use Cases==<br />
<br />
'''Use Case 1. Batch Insertion '''''<br />
<br />
A Broker invokes the "registration" operation of the Management Domain, providing the following information: <br />
<br />
* EPR for the Broker<br />
* Name of the Broker <br />
* Classification or Type of the Broker (Data or Service)<br />
<br />
Management Domain populates its internal registry with the information about the Broker <br />
<br />
Management Domain changes the state of the Broker to online and updates the timestamp <br />
<br />
If the Broker is already registered with the Management Domain, the Broker invokes the "ping" operation, which updates the timestamp in the Management Domain registry <br />
<br />
<br />
'''Use Case 2. Batch results'''<br />
<br />
* A Broker invokes the deregister operation of the Management Domain, providing the Broker name as a parameter.<br />
* the Management Domain removes the registration entry for the Broker from its internal registry.<br />
<br />
<br />
== '''External Interfaces''' ==<br />
<br />
'''Framework Interface'''<br />
<br />
Include code snippet<br />
<br />
<br />
'''Component Interfaces'''<br />
<br />
Include code snippets<br />
<br />
'''Conventions'''<br />
<br />
Naming expectations used by reflection during compilation.<br />
<br />
== '''Framework Implementation Details''' ==<br />
<br />
Discussion of compilation steps and runtime interactions<br />
<br />
== '''Notes''' ==<br />
<br />
<br />
----<br />
[[Category:COSMOS_Bugzilla_Designs]]</div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=COSMOS_Design_197521&diff=49287COSMOS Design 1975212007-09-05T18:13:34Z<p>Joel.hawkins.compuware.com: New page: '''Design Discussion for [https://bugs.eclipse.org/bugs/show_bug.cgi?id=197521 197521]: component implementation - separating framework vs. extension code ''' == '''Separation of Concerns...</p>
<hr />
<div>'''Design Discussion for [https://bugs.eclipse.org/bugs/show_bug.cgi?id=197521 197521]: component implementation - separating framework vs. extension code '''<br />
<br />
== '''Separation of Concerns for COSMOS DC framework''' ==<br />
<br />
This design document addresses COSMOS Bugzilla enhancement request [https://bugs.eclipse.org/bugs/show_bug.cgi?id=197521 197521]. <br />
<br />
<br />
Change History:<br />
<br />
Joel Hawkins 9/05/2007 Initial version<br />
<br />
== '''Overview''' ==<br />
<br />
Current situation - using java stack as mechanism for managing component invocation.<br />
Threading issues delegated to components.<br />
<br />
== ''' Implementation Stages and Corporate Use Cases ''' ==<br />
<br />
== '''Terminologies/Acronyms''' ==<br />
<br />
The terminologies/acronyms below are commonly used throughout this document. The list below defines each term:<br />
<br />
COMPONENT: component definition<br />
<br />
BINDING SERVICE: binding service definition<br />
<br />
CONTEXT: context definition<br />
<br />
==Use Cases==<br />
<br />
'''Use Case 1. Simple Collection Scenario'''''<br />
<br />
A Broker invokes the "registration" operation of the Management Domain, providing the following information: <br />
<br />
* EPR for the Broker<br />
* Name of the Broker <br />
* Classification or Type of the Broker (Data or Service)<br />
<br />
Management Domain populates its internal registry with the information about the Broker <br />
<br />
Management Domain changes the state of the Broker to online and updates the timestamp <br />
<br />
If the Broker is already registered with the Management Domain, the Broker invokes the "ping" operation, which updates the timestamp in the Management Domain registry <br />
<br />
<br />
'''Use Case 2. Simple Query Scenario'''<br />
<br />
* A Broker invokes the deregister operation of the Management Domain, providing the Broker name as a parameter.<br />
* the Management Domain removes the registration entry for the Broker from its internal registry.<br />
<br />
<br />
== '''External Interfaces''' ==<br />
<br />
'''Framework Interface'''<br />
<br />
Include code snippet<br />
<br />
<br />
'''Component Interfaces'''<br />
<br />
Include code snippets<br />
<br />
'''Conventions'''<br />
<br />
Naming expectations used by reflection during compilation.<br />
<br />
== '''Framework Implementation Details''' ==<br />
<br />
Discussion of compilation steps and runtime interactions<br />
<br />
== '''Notes''' ==<br />
<br />
<br />
----<br />
[[Category:COSMOS_Bugzilla_Designs]]</div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=CosmosDataCollectionComponent&diff=49286CosmosDataCollectionComponent2007-09-05T18:02:19Z<p>Joel.hawkins.compuware.com: /* Design Documents & Discussions In Progress */</p>
<hr />
<div>[[COSMOS|COSMOS Main Page]] > <br />
= Data Collection and Normalization =<br />
<br />
== Scope and Mission ==<br />
<br />
The Data Collection and Normalization component will implement a data collection framework as described on pages 20 and 21 of the COSMOS project creation review pdf [http://www.eclipse.org/proposals/cosmos/COSMOS%20Project%20Creation%20Review-v1.0a.pdf here].<br />
<br />
The initial scope of the Data Collection and Normalization component supports the <br />
[[COSMOS Use Cases|Use Cases]]<br />
that the COSMOS project is defining to demonstrate the value of SML throughout the application lifecycle. It will accept managent data from the instrumentation produced by the COSMOS [[CosmosBuildToManageComponent| Build to manage]] <br />
component and provide data normalization and persistance and a query API to support its consumption by the COSMOS [[CosmosDataReportingComponent| Data Reporting]] <br />
component.<br />
<br />
== Tactical Plan == <br />
Much of the initial work of the data collection component will be done in cooperation with the TPTP project. To facilitate the timely creation of a demonstrable implementation, the data collection component will leverage key TPTP technologies such as the Common Base Event (CBE) format, TPTP agents such as JMX and the Generic Log Adapter (GLA), and the Agent Controller.<br />
<br />
See also the prototype proposal in the Resources section below.<br />
<br />
== Architectural Vision ==<br />
<br />
=== Persistence API ===<br />
<br />
The framework will provide an extension point for data persistance. Each supported data type will be consumed by a persistor that supports persisting a particular data format into its own database table or other data store.<br />
<br />
Initially, persistors will be provided for the EMF models that TPTP currently supports.<br />
<br />
<br />
=== Data Collection Control API ===<br />
<br />
A WSDM interface will be provided for the purpose of configuring the data collection agents.<br />
<br />
In the longer term, this interface will be usable to manage the monitored infrastructure components.<br />
<br />
=== Adapters for Data Collection agents into Persistence API ===<br />
<br />
The framework will provide an extension point for data collection agent adapters. One possible approach is to provide a service that connects agent adaptors to an appropriate data persistor based on the data type supported by the adaptor such as CBE or WEF. A provision to specify these connections declaratively is required, but they could also be constructed dynamically via a WSDM interface.<br />
<br />
The connection service should specifically support the ability to inject interceptors between the agent adapters and the data persistors.<br />
<br />
Initial adapters will include log, statistical, and perhaps trace adapters but the framework will be generalized so it can be extended to support any additional models as required.<br />
<br />
=== Query API ===<br />
<br />
The query API will provide a web service interface to the data store(s). <br />
<br />
Its binding will be constructed in a manner analogous to the Data Collection adapters where extensions can be created to implement any desired query mechanism without requiring dependence on the type or location of the underlying data store.<br />
<br />
Multiple web services will be provided to allow the consumer to select appropriate query semantics.<br />
<br />
The initial targets are SQL and / or XPath.<br />
<br />
[[COSMOSTPTPQuereryIntrfaceNotes]]<br />
<br />
[[COSMOSQueryInterfaceInitialDesign]]<br />
<br />
=== Database Schema ===<br />
<br />
Each data collection adapter will define the schema for its datastore. A reasonable minimum expectation is that each database will be keyed by timestamp and the unique ID of the managed resource.<br />
<br />
The initial target is [http://en.wikipedia.org/wiki/Apache_Derby Derby], with support for MySQL and proprietary databases later. An attempt will be made to avoid proprietary SQL to permit a wide choice of database engines.<br />
<br />
=== Proposed Technology Stack ===<br />
This diagram shows one possible implementation technology stack for COSMOS data collection<br />
<br />
The data collector will be extended with bundle fragments that implement data collection adapters, persistors and query interfaces. <br />
<br />
Data Collection Adaptors adapt an information source into a common format supported by a persistor.<br />
<br />
Persistors accept information of a particular type such as CBE and provide a persistance service for this data type.<br />
<br />
Query Adaptors adapt queries in a language such as SQL or XPATH to the persistent data store.<br />
<br />
{| border="1"<br />
| || WSDM (Muse)<br />
|-<br />
| || SOAP (Axis)<br />
|-<br />
| || Data Collection Bundle<br />
|-<br />
| DC Adaptor || Persistor || Query <br />
|-<br />
| || OSGi (Equinox)<br />
|}<br />
<br />
<br />
== Common Agent Infrastructure ==<br />
Discussion on Common Agent Infrastructure<br />
<br />
* No formal agent infrastructure currently in scope<br />
** Root level question: Do we want this in COSMOS?<br />
<br />
* COSMOS needs to have some of this to be self hosting<br />
* Tie in BtM<br />
<br />
*<br />
<br />
== Open Issues == <br />
* Which components require alternative implementations in support of embedded devices<br />
* Which components must support Java 1.4<br />
<br />
== Resources ==<br />
<br />
TPTP [[TPTPModel|model]] and [[TPTP_data_persistence_layer|data persistence ]] ([http://dev.eclipse.org/viewcvs/index.cgi/platform/org.eclipse.tptp.platform.models/src-dms/?root=TPTP_Project TPTP DMS CVS link])<br />
<br />
Initial prototype [[COSMOSInitalPrototype|proposal]]<br />
<br />
DataCollector [[DCInitalPrototype|prototype]]<br />
<br />
[[COSMOSPersisteceFrameworks|Persistence Frameworks Discussion]]<br />
<br />
[[COSMOSDataCollectorEnvironment|How to set up your Eclipse for working on DataCollection]]<br />
<br />
[[COSMOSDataCollectionEnd2End|Setting up a tomcat instance to working with the COSMOS End to End example]]<br />
<br />
[[COSMOS_CBE_RDB | Running the Data Collection w/CBEs]]<br />
<br />
[[Data Collection Q&A]]<br />
<br />
[[COSMOSEnd2EndSample | Instructions for running the end-to-end sample ]]<br />
<br />
<br />
[[ COSMOS#Architecture | back to home]]<br />
<br />
<br />
== Design Documents & Discussions In Progress ==<br />
<br />
[[COSMOS_DC_Design_Discussions|DC Design Improvements]]<br />
<br />
[[Data_Manager|Discussions around the Data Manager Design]]<br />
<br />
[[COSMOS_Design_193420|193420: Create simple stand alone example of the data collection framework]]<br />
[https://bugs.eclipse.org/bugs/show_bug.cgi?id=193420 193420]<br />
<br />
[[COSMOS_Design_197867|197867: Need to design and implement the COSMOS DC Data Broker]]<br />
[https://bugs.eclipse.org/bugs/show_bug.cgi?id=197867 197867]<br />
<br />
[[COSMOS_Design_197868|197868: Need to design and implement the COSMOS DC Management Domain]]<br />
[https://bugs.eclipse.org/bugs/show_bug.cgi?id=197868 197868]<br />
<br />
[[COSMOS_Design_197869|197869: Need to design and implement the COSMOS DC Service Broker]]<br />
[https://bugs.eclipse.org/bugs/show_bug.cgi?id=197869 197869]<br />
<br />
[[COSMOS_Design_197870|197870: Need to design and implement the COSMOS DC Client APIs]]<br />
[https://bugs.eclipse.org/bugs/show_bug.cgi?id=197870 197870]<br />
<br />
[[COSMOS_Design_197521|197521: Component implementation - separating framework vs. extension code]]<br />
[https://bugs.eclipse.org/bugs/show_bug.cgi?id=197521 197521]<br />
<br />
[[COSMOS_Design_197525|197525: Buffering data in the data assembly pipeline]]<br />
[https://bugs.eclipse.org/bugs/show_bug.cgi?id=197521 197521]</div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=Talk:COSMOS_Design_200222&diff=48844Talk:COSMOS Design 2002222007-08-31T17:12:47Z<p>Joel.hawkins.compuware.com: </p>
<hr />
<div>This page includes all the discussion for [[COSMOS Design 200222]].<br />
<br />
<hr><br />
<br />
[Valentina Popescu comments]<br />
<br />
# Re: [[COSMOS Design 200222#Terminologies.2FAcronyms|SML Repository term]]: Shouldn't this be called COSMOS SML Repository to differentiate between this specific SML rep and a generic one ?<br />
# Re: [[COSMOS Design 200222#Terminologies.2FAcronyms|Service description term]]: How exactly are supported record types defined? Is there a configuration file where SML record types to be used by the Query Service are logged ? Or every SML type defined by the Data Center is required to be supported?<br />
# Re:[[COSMOS Design 200222#Purpose|'The output of the query will also be in XML format, which the client is expected to understand.']] I had a discussion with Ali today and went over what a client can and should understand from a CMDBf query. In summary : a CMDBf query is defined using the CMDBf query language ( the query set, containing one or more templates, etc ). This is part of the CMDBf spec and yes, it is straight forward that it is expected to be understood by the client initiating the query. But this is not enough to create a query. Aside of the CMDBf query language, which allows the user to format a query request, the actual 'content' of the query should use some sort of contract or understanding between the client and the Query Service implementor. So, for example, if a client defines a CMDBf query containing a template (I forgot the exact CMDBf naming for this.. ) asking for a 'user' element, the QueryService implementation should be able to map this 'user' with a type in the MDR's data source. It should know that when the query asks for a 'user', the MDR should actually get back all records with type = 'employee' ( user would map to an employee in this specific MDR. I think the way to achieve this is by having a common set of types at the federating CMDB level, and have all MDR's/QueryServices know about these types and know how to map their specific data to/from this generic types. We can start by defining this common types as being a subset of the current COSMOS SML Data Center Repository ( we can choose for example only machine, vm and os ); we should aim to have the common types be the CML library, once one is made available. Ali can probably explain all this in more detail.<br />
# Re: [[COSMOS Design 200222#Purpose|SML repository convenience APIs]]: I don't think keeping the existing API's as an alternative to the QueryService will be a long lasting option; it should stay until COSMOS moves to CML. Once the COSMOS Data Center types will be replaced by a CML library type, these API's will cease to be as useful as they are now; the scope of the data will be extended to more than just machines, os, etc; it may be hard for the API to satisfy this extended spec<br />
# Re: [[COSMOS Design 200222#Requirements|Requirements]]: It is implied from the usecases section that the clients will be only able to query the COSMOS Data Center repository. We should make this clear here; I understand this is how much will be delivered in i6 and I am okay with this but we need to clearly state it so we don't loose track of the fact that we address only this part of the puzzle. The implications for this restriction: <br />
##the user will have to understand the Data Center data types, or at least the ones that are made available for query<br />
##if not all the DataCenter types are planned to be made available for query, the MDR/Query Service will need a mechanism for registering the types it wants to make available; the user must know about this registration and must understand the content of the registry to the point where he can create a query using those types.<br />
<br />
What needs to be done post i6:<br />
* build a generic, common set of types a client can use to define a CMDBf query. This common type can be registered at the federation level; the common type should ideally be a subset of CML or the Data Center types<br />
* every MDR/Query Service will know how to map its data to/from these common types<br />
* a client will know how to create a query to address to the CMDB federation using these types; will know how to read the result, again containing common type-based information<br />
<br />
[Joel Hawkins comments]<br />
The Architecture diagram doesn't show the Property Subset directive implementation - it might be nice to pencil it in.<br />
<br />
<hr><br />
<br />
[Replies to comments]<br />
<br />
* Re: comment #1, I changed the text preceding the list of terms to indicate that this is regarding how the terms are used in this document. I.e. when we refer to SML repository in this document, we mean the COSMOS one.<br />
* Re: comment #2, I deleted the term from the list, since it really was outside the scope of this design<br />
* Re: comment #3, this is something that should be considered down the road after i6. It doesn't fall under the scope of 200222. COSMOS does not intend to provide an implementation of a federating CMDB within i6.<br />
* Re: comment #4, the convenience APIs are just an alternative way of querying for data. I do agree that they will likely be deprecated when CML comes out but I have no intention of removing or deprecating them at this point.<br />
* Re: comment #5, it is true that the COSMOS client will be tied to the data center examples; however the query service does not make any assumptions about the type of data stored in the SML repository. I don't agree with adding a description that would imply a tight coupling between the implementation of 200222 and the data center example.</div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=COSMOSBrokerSpecification&diff=47297COSMOSBrokerSpecification2007-08-21T15:35:57Z<p>Joel.hawkins.compuware.com: /* Client queries broker for MDRs */</p>
<hr />
<div>==Overview==<br />
The broker is the component in the COSMOS data collection framework that holds a registry of management data repositories (MDRs). The registry stores the addresses of the MDRs in the form of end point references, indexed according to the data classification and the data source type of the data. Each MDR provides the data classification and data source type information upon registration with the broker and maintains the relevant registry data over its life cycle. The broker provides interfaces for clients to make queries for the classifications and data source types available in the registry and for addresses of MDRs based on classifications and/or data source types. The interfaces are provided in the form of WSDM capabilities and Java interfaces. <br />
<br />
The “broker” component is a logically centralized component in the COSMOS data collection framework. In practice, there can be multiple brokers, each responsible for a different group of management resources, for example, the distinction between data brokers and service brokers. However, the role and responsibilities of different kinds of brokers are the same. In the case where there are multiple brokers, there is a higher level lookup registry (the management domain) to find the address of the brokers. <br />
<br />
==Broker Registry Indexes==<br />
The registry is a lookup table of the addresses of MDRs that have registered with the broker. The addresses are indexed with two pieces of information:<br />
#Data Type Classification: <br />
#*Data type classification (or simply “classification”) is a well-known identifier that represents data with a predefined structure and meaning. It is analogous to a Java class definition. <br />
#*Examples:<br />
#**Common Base Events (CBE): CBE is an OASIS standard of event data which has a predetermined structure. <br />
#**Hardware asset data: The attributes of hardware asset data (such as CPU speed, machine model number, hard drive space, etc) can be defined in standards like CML. <br />
#**The classification does not have to be a public standard. A classification can be defined for a specific system, as long as the definition is a common knowledge among all MDRs. The definition must be available globally with the COSMOS data collection system, and there is a way to introspect the data structure of the classification. For example, we can define “statistical data” as the tuple (HeapMemoryUsed, NonHeapMemoryUsed). The definition of the classification can be represented by using the SML facet concept. <br />
#Data source type:<br />
#*The data source type value specifies the type of hardware or software that generated the data. <br />
#*The data source of CBE data can be a web server or a network router. <br />
#*Data source type identifies the type of data source, but not the instance of the data source. <br />
Notes:<br />
*Data classified by the same data type classification can originate from different data source types. (For example, CBE event data can be generated by web applications and network routers.)<br />
*Each MDR can provide one or more combinations of classification and data source type values to identify the data it can provide.<br />
<br />
==Broker Registry Structure==<br />
The registry can be composed of 3 database tables:<br />
<br />
#Classification(cid, name)<br />
#DataSourceType(did, name)<br />
#MDR(epr, cid, did, state)<br />
<br />
<br />
===Example data===<br />
{|border="1" <br />
|+'''Classification'''<br />
!width="50"|cid<br />
!width="225"|name<br />
|-<br />
| 1<br />
| CBE<br />
|-<br />
| 2<br />
| SDMX<br />
|-<br />
| 3<br />
| SML<br />
|}<br />
<br />
<br />
{|border="1" <br />
|+'''DataSourceType'''<br />
!width="50"|did<br />
!width="225"|name<br />
|-<br />
| 10<br />
| Tomcat Server<br />
|-<br />
| 20<br />
| Cisco router<br />
|-<br />
| 30<br />
| SML Repository<br />
|}<br />
<br />
<br />
{|border="1" <br />
|+'''MDR''' (values in brackets are referenced values)<br />
!width="50"|epr<br />
!width="50"|cid<br />
!width="50"|mid<br />
!width="50"|state<br />
|-<br />
| EPR 1<br />
| 1 (CBE)<br />
|10 (Tomcat Server)<br />
| online<br />
|-<br />
| EPR 2<br />
|1 (CBE)<br />
|20 (Cisco Router)<br />
| online<br />
|-<br />
| EPR 3<br />
|2 (SDMX)<br />
|10 (Tomcat Server)<br />
| online<br />
|-<br />
| EPR 4<br />
|3 (SML)<br />
|30 (SML Repository)<br />
| online<br />
|-<br />
| EPR 5<br />
| 1 (CBE)<br />
| 10 (Tomcat Server)<br />
| online<br />
|-<br />
| EPR 6<br />
| 1 (CBE)<br />
| 10 (Tomcat Server)<br />
| offline<br />
|}<br />
<br />
==User Cases==<br />
<br />
====Broker initialization====<br />
*Broker wakes up. <br />
*Broker undergoes initialization: Loops through the rows in the MDR table, ping each MDR for their status. If an MDR is reachable, set its state to "online"; otherwise, set it to "offline".<br />
*Broker waits for requests from client or MDR. <br />
<br />
====MDR registers with broker====<br />
*MDR contacts broker via well-known (pre-configured) EPR. MDR may also get broker address from management domain. <br />
*MDR invokes the "registration" capability of the broker. Provide the following information during registration:<br />
**EPR for the MDR<br />
**a pair of classification and data source type identifiers for each data source instance it is managing. <br />
*Broker populates tables in registry database with the information about the MDR. <br />
<br />
====Data manager deregisters with broker====<br />
*Data manager invokes the deregister capability of the broker, providing ID as a parameter.<br />
*Broker updates removes the entry that corresponds to this data manager from the registry<br />
<br />
====Client queries broker for MDRs====<br />
*Client invokes an API of the broker, providing a classification keyword (e.g. hardware configuration)<br />
*Broker retrieves EPRs of data managers from the registry that are under the desired category and returns the EPRs to the client<br />
*'''Example queries:'''<br />
*#"Give me MDRs that provide daa from SML Repositories." Using the example data above, the broker will return EPR4.<br />
*#"Give me MDRs that provide CBE data for Tomcat Servers." Using the example data above, the broker will return EPR1 and EPR5. EPR6 is not included because it is offline. <br />
*#"Give me MDRs that provide data about Tomcat Servers." EPR1, EPR3 and EPR5 are returned. Since classification is not specified, EPRs that provide CBE or statistical data (SDMX) are returned. <br />
*#"Give me MDRs that provide CBE data." EPR1, EPR2 and EPR5 are returned. Since data source type is not specified, CBE can orginate from either Tomcat Server or Cisco Router.<br />
<br />
<br />
<Joel comment> What about the case where my MDRs are organized around a business-oriented topology? This current simplification of datasource type/ keset type doesn't allow for any instance-oriented organization. Are you sure that's what you want? </Joel comment><br />
<br />
====Register new classification or data source type====<br />
<br />
====Query for existing classifications and data source types available at the broker====<br />
<br />
<br />
==Notes==<br />
#The current registry design uses two keys (classification and data source type) to index the EPRs of MDRs. Note that the SDMX data model is not used in the broker registry. The classification and data source type concepts can be mapped roughly to the key family and data source type of SDMX. We try to keep the semantics of separating data structure from the source of data. <br />
#The broker registry design is not standards-based. However, the design and implementation should allow the registry to be evolved to support CMDBf query and registration, and potentially use an implementation of WS-RC to store the registry data. <br />
#Use of iBatis: iBatis was initially introduced into the codebase as a means to access relational data via Java API. It was part of an investigation effort on query languages for heterogeneous data sources. I suggest that we review the use of iBatis in COSMOS. If it is only used to access data in the registry database, I don’t think it will bring much value. Using JDBC may be sufficient for our purpose. We should reduce dependency of 3rd party program as much as possible.</div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=Talk:COSMOS_Design_197867&diff=46439Talk:COSMOS Design 1978672007-08-15T15:21:19Z<p>Joel.hawkins.compuware.com: /* Client queries broker for data managers */</p>
<hr />
<div>==Joel's comments== <br />
(Hubert's comments are within the <Hubert's comment>...</Hubert's comment> markers)<br />
<br />
First, some general comments. One of the nice things that SDMX does is make a distinction between the structure of a set of data and the source of the set of data. If you take a look at the SDMX DataFlow structure, you'll see that it breaks down into two distinct concerns. The first is the type of data (the keyset/dimension concern), and the second is the type of entity that created the data (the source concern). It makes tons of sense to me to see information related to the first concern being pushed up from DC into CMDB land, and the information related to the second concern being pushed down from CMDB into DC land. <br />
The nice thing about supporting this type of symmetry is that you can use the results of a CMDBf graph query as input to a DataBroker graph query.<br />
<br />
<Hubert's comment><br />
Joel, can you explain why data structure specification flows from DC to CMDB? The data direction of the two concerns are not very intuitive to me. To me, all metadata information come from data managers or MDRs. The first concern (data structure) is provided to the broker (federating CMDB) by data managers (MDRs) when they register. <br />
<br />
<Joel's response>Sure. The Data Broker is the real 'owner' of the DC keyset information. If the DataBroker acts as an MDR for the purpose of supporting CMDB federation, it makes sense to me that the bit of metadata that's being federated out of the DataBroker MDR is this keyset information. The CMDB shouldn't have to know about all of the DataManagers - let the DataBroker act as the aggregator.</Joel's response><br />
</Hubert's comment><br />
<br />
</Hubert's comment><br />
<br />
* How does the query work? Need better example of how to query for data. <br />
<br />
* Need example of how to map existing data to SDMX structure.<br />
** SDMX DataSet definition - DataFlow URI+ DataSource URI+ Time period<br />
** SDMX DataFlow definition - DataSource URI + Keyset URI<br />
** SDMX DataSource definition - DataSourceURI + DataSourceTypeURI<br />
** SDMX DataSourceType definition - DataSourceTypeURI<br />
** SDMX Keyset definition - Keyset URI + a list of DimensionURIs<br />
** SDMX Dimension definition - DimensionURI + Type enumeration. SDMX restricts the type of information that a dimension may hold to enumerations and simple scalar types.<br />
*** We've completely ignored the SDMX concepts um... concept, as it has a high degree of overlap with our intended use of SML/CML. <br />
<br />
<Hubert's comment><br />
Regarding mapping existing data to SDMX, we need to take care of the usecase where I have an existing database of system management data (stat data, log data, or hardware config data). The data is collected by existing applications, such as TPTP or IBM Tivoli products like ITM. In these cases, we need to a generic way to map the data models of these existing databases to the SDMX data model. In many cases, the mapping is non-trivial. We will also need to have extension code written to process SDMX queries into native query languages, and transformers to convert native data structures to the SDMX data formats (e.g. from jdbc result set to ket family and key concepts). These extra mapping and processing logic will become a performance issue. <br />
<br />
<Joel's Response>This is only an issue if we make it one. If the existing dataset just provides a description of it's record format in 'SDMX' form, then there's nothing to map. Also, our assemblies support Transformers, so we can always deal with this issue at the component level. </Joel's Response><br />
</Hubert's comment><br />
<br />
I think that most of our mapping issues can be solved by deciding what time periods we want to support (for a lot of cases it may be 'for all time' as a means of effectively saying that there is only one dataset), and at what level we want the URIs to actually point to more granular definitions. For example, if we say that a WEF event's URI is a Keyset URI instance, and that the WEF event's URI is terminating (in other words, doesn't have a correpsonding set of Dimensions), then we can effectively map our type information into SDMX by truncation. All that's required it to relax the schema requirements on the higher level constructs in SDMX to be 'could have' instead of 'must have'.<br />
<br />
<Hubert's comment><br />
I don't like the idea of truncating the SDMX model at a point beyond which it can't be used efficiently. For example, represent WEF events up to the keyset, and don't map attribute of WEF events to keys. We are simply saying SDMX is not suitable for all data types. It won't be very meaningful to just map a WEF event to a keyset because we can't use form an SDMX query with the contents of the event attribute values, which are very important in forming the search criteria in a query. (e.g. get all events with high severity)<br />
<br />
<Joel's Response><br />
So map the bits of WEF that make sense into a keyset, and truncate the rest. There's no reason to take an extremist stance here. Of course, you could also (once you've determined the fact that the data format is WEF) use the convinience API that would be surfaced as a MUSE capability on the DataManager endpoint to do your more granular query. Remember, we have the capability model to exploit - there's no reason to force fit anything here.<br />
</Joel's Response><br />
</Hubert's comment><br />
<br />
* Have we agreed that SDMX is the default model we support? Are we talking about query models? If so, then no - I don't think that SDMX is appropriate as our default, or at least given the proposed mapping solution outlined above, we won't be able to support the full SDMX query interface. Of course, providing limited support for SDMX queries as a WSDM capability on the DataBroker should be feasible. <br />
<br />
* What about other models, e.g. SQL? <br />
<br />
* Does the user NEED to understand SDMX to use this? It would be helpful to understand the spirit of SDMX, at least enough to know what an <br />
appropriate mapping would be.<br />
<br />
<Hubert's comment><br />
I would suggest that we do not mention the term "SDMX" in any of the COSMOS documentation, even if we are borrowing some concepts from it. Here are the reasons:<br />
*The SDMX concepts can be hidden behind some easy-to-use APIs. <br />
*It's a partial implementation (in fact a very small subset). People who really know about SDMX will say we are not using SDMX. <br />
*Most people have not seen the term "SDMX" in their lives, and let's not say they need to learn something new to use COSMOS. It will affect adoption acceptance. <br />
</Hubert's comment><br />
<br />
* How does the design support other things than SDMX. I've vote for using the WSDM capability model, so you can always support additional requirements through composition.<br />
<br />
* How do we reconcile the CMDBf query structure? This is where we can start to do some interesting things. For example, CMDBf has the concept of a 'Graph Query', which allows you to do pattern-oriented queries against the CMDB structure. This is really handy, because what we have in DC (and SDMX, for that matter) is pretty much unaware of structural implications - particularly at the instance level. So imagine that we use a CMDBf query against a compliant CMDB to identify things that are "close to" the problem we're trying to track down (and we can imagine one or more definitions of 'close to' based on puggable heuristics or norms). If we've done a proper job of mapping our SDMX-like URIs, then we are well set up to support a DataBroker query that can provide a set of EPRs that have information "close to" what's needed for problem resolution. So if we implement the DataBroker as an MDR (which means supporting the CMDBf Query API), we can use the implementation to return the set of DataManager EPRs as Target Items in the GraphQueryResponse structure. I think that's pretty cool!<br />
<br />
==Hubert's comments==<br />
<br />
In order to close on the broker design, we need more clarity in the broker design on the following area:<br />
#Content of the registry: How the data manager EPRs are indexed in the registry.<br />
#How will the data broker expose the registry contents to the clients (Broker API for clients)<br />
#How do data manager register with the data broker (Broker API for data managers)<br />
<br />
Please see my comments at [[Talk:COSMOS_Design_197870]] on broker APIs. Please include the broker API in the design doc of 197867 because I think they are part of the broker design.<br />
<br />
If we are looking at a simpler broker registry design for i6 that doesn't take into account of CMDBf and other standards, I have the following proposal for consideration. (When we come up with a broker implementation that support CMDBf query and a more elaborate index system for data manager or managed resources, we can replace the broker component with the newer design.)<br />
<br />
The registry will be a simple lookup table of EPRs indexed by keywords. <br />
{| border="1"<br />
|-<br />
| keyword1<br />
<br />
| EPR1<br />
EPR2<br />
|-<br />
<br />
| keyword2<br />
| EPR3<br />
|}<br />
<br />
The client will look up data managers by keywords. The broker will return all EPRs assoicated with the keyword the client provided in the request. Data managers will provide a keyword that describes the data that it is providing during registration. This design will make the EPR query and data manager registration APIs very simple. <br />
<br />
This approach does not use SDMX data model at all. While I don't oppose the use of SDMX data model in the broker, SDMX will make the API and process for data manager registration and EPR queries a lot more complicated. I just want to show a very simple design here for consideration, which I think is in line with the proposed API in design doc of 197870. <br />
<br />
<br />
===Use cases related to the broker===<br />
(These uses cases are taken from a [http://wiki.eclipse.org/Image:Dcframework2.zip presentation] I prepared for last Friday's meeting. We didn't get to this part of the presentation in that meeting. I have further simplied the use case below.)<br />
====Broker initialization====<br />
*Broker wakes up. <br />
*Broker undergoes initialization: Loops through the entries in the registry, ping each data manager for their status. If a data manager is not reachable, remove the entry from the registry<br />
*Broker waits for requests from client or data managers<br />
<br />
====Data manager registers with broker====<br />
*Data manager wakes up.<br />
*Data manager contacts broker via well-known (pre-configured) EPR. <br />
*Data manager invokes the “registration” capability of the broker. Provide the following information (parameters) during registration:<br />
**an identifier (ID) that identifies the data manager<br />
**an EPR for clients to contact the data manager<br />
**a classification keyword(e.g. hardware configuration, statistical data, etc.) It is a keyword for identifying the type of data that the data manager can provide. It will be used by the client when querying the broker for relevant data managers. (The broker keeps a dictionary of classification keywords and API for clients and data brokers to lookup. It’s analogous to "topics" in the pub/sub paradigm.) <br />
*Broker adds an entry in the registry for the new data manager.<br />
<br />
====Data manager deregisters with broker====<br />
*Data manager invokes the deregister capability of the broker, providing ID as a parameter.<br />
*Broker updates removes the entry that corresponds to this data manager from the registry<br />
<br />
====Client queries broker for data managers====<br />
*Client invokes an API of the broker, providing a classification keyword (e.g. hardware configuration)<br />
*Broker retrieves EPRs of data managers from the registry that are under the desired category and returns the EPRs to the client<br />
<br />
<Joel's Comments><br />
I've tried to flesh out these interactions a bit with some options:<br />
<pre><br />
Case 1: Given a reported error on a resource, resolve a relevent set of DataManagers for that resource.<br />
<br />
Step 1: Determine what additional resources are relevent to the reporting resource<br />
<br />
Client -------------------------------> CMDB (CMDB Query capability)<br />
Graph<CMDB Resource Identifiers><---- graphQuery()<br />
<br />
Step 2: Get a list of data brokers (using either 2A or 2B)<br />
<br />
Step 2A: Get the list of know databrokers from the Domain Manager.<br />
<br />
Client -------------------------------> Domain Manager resolution (locate the well known EPR for the domain manager. Hard code/Local config/LDAP/Whatever...)<br />
<br />
Client -------------------------------> Domain Manager (WSDM)<br />
List<Capabilties><------------------- getManagementCapabilities()<br />
<br />
Client resolves COSMOS Domain Manager capability<br />
<br />
Client -------------------------------> Domain Manager (COSMOS Domain Manager capability)<br />
List<DataBroker><------------------- getDataBrokerList()<br />
<br />
<br />
Step 2B: Get a subset of databrokers from the Domain Manager based on some sort of query.<br />
<br />
Client -------------------------------> Domain Manager resolution (locate the well known EPR for the domain manager. Hard code/Local config/LDAP/Whatever...)<br />
<br />
Client resolves Resource Catalog capabilty<br />
<br />
Client -------------------------------> Domain Manager (WSDM)<br />
List<Capabilties><------------------- getManagementCapabilities()<br />
<br />
Client resolves WS-RC capability<br />
Client resolves WS-ResourceTransfer capability<br />
<br />
Client -------------------------------> Domain Manager (WS-ResourceTransfer capability)<br />
Get response<DataBroker EPRs><------------------- get(Get message with XPath filter)<br />
<br />
Step 3: Query the DataBrokers for datasets relevent to the reported error (based on time and the contents of the CMDB graphQuery response) using either 3A or 3B.<br />
<br />
<br />
Step 3A: Query the DataBrokers for datasets relevent to the reported error using the COSMOS provider capability<br />
<br />
Client for each DataBroker<br />
<br />
Client -------------------------------> DataBroker(WSDM)<br />
List<Capabilties><------------------- getManagementCapabilities()<br />
<br />
Client resolves COSMOS provider capability<br />
<br />
Client for each CMDB Resource in the graphQuery response<br />
<br />
Client -------------------------------> DataBroker (COSMOS provider capability)<br />
List<DataSet><----------------------- getDataSetsForSource()<br />
<br />
Client -------------------------------> DataBroker (COSMOS provider capability + merged endpoint support)<br />
List<DataManager EPR><--------------- getEPRForDataSets(List<DataSet>)<br />
<br />
Step 3B: Query the DataBrokers for datasets relevent to the reported error using the CMDBf Query capability<br />
<br />
Client for each DataBroker<br />
<br />
Client -------------------------------> DataBroker(WSDM)<br />
List<Capabilties><------------------- getManagementCapabilities()<br />
<br />
Client resolves CMDB Query capability<br />
<br />
Client constructs CMDB graphQuery request based on contents of CMDB graphQuery response<br />
<br />
Client -------------------------------> DataBroker (CMDB Query capability)<br />
Graph<DataSet/EPR pairs><------------ graphQuery()<br />
</pre><br />
</Joel's Comments></div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=Talk:COSMOS_Design_197867&diff=46285Talk:COSMOS Design 1978672007-08-14T18:52:03Z<p>Joel.hawkins.compuware.com: </p>
<hr />
<div>[Joel's comments] (Hubert's comments are within the <Hubert's comment>...</Hubert's comment> markers)<br />
<br />
First, some general comments. One of the nice things that SDMX does is make a distinction between the structure of a set of data and the source of the set of data. If you take a look at the SDMX DataFlow structure, you'll see that it breaks down into two distinct concerns. The first is the type of data (the keyset/dimension concern), and the second is the type of entity that created the data (the source concern). It makes tons of sense to me to see information related to the first concern being pushed up from DC into CMDB land, and the information related to the second concern being pushed down from CMDB into DC land. <br />
The nice thing about supporting this type of symmetry is that you can use the results of a CMDBf graph query as input to a DataBroker graph query.<br />
<br />
<Hubert's comment><br />
Joel, can you explain why data structure specification flows from DC to CMDB? The data direction of the two concerns are not very intuitive to me. To me, all metadata information come from data managers or MDRs. The first concern (data structure) is provided to the broker (federating CMDB) by data managers (MDRs) when they register. <br />
<br />
<Joel's response>Sure. The Data Broker is the real 'owner' of the DC keyset information. If the DataBroker acts as an MDR for the purpose of supporting CMDB federation, it makes sense to me that the bit of metadata that's being federated out of the DataBroker MDR is this keyset information. The CMDB shouldn't have to know about all of the DataManagers - let the DataBroker act as the aggregator.</Joel's response><br />
</Hubert's comment><br />
<br />
</Hubert's comment><br />
<br />
* How does the query work? Need better example of how to query for data. <br />
<br />
* Need example of how to map existing data to SDMX structure.<br />
** SDMX DataSet definition - DataFlow URI+ DataSource URI+ Time period<br />
** SDMX DataFlow definition - DataSource URI + Keyset URI<br />
** SDMX DataSource definition - DataSourceURI + DataSourceTypeURI<br />
** SDMX DataSourceType definition - DataSourceTypeURI<br />
** SDMX Keyset definition - Keyset URI + a list of DimensionURIs<br />
** SDMX Dimension definition - DimensionURI + Type enumeration. SDMX restricts the type of information that a dimension may hold to enumerations and simple scalar types.<br />
*** We've completely ignored the SDMX concepts um... concept, as it has a high degree of overlap with our intended use of SML/CML. <br />
<br />
<Hubert's comment><br />
Regarding mapping existing data to SDMX, we need to take care of the usecase where I have an existing database of system management data (stat data, log data, or hardware config data). The data is collected by existing applications, such as TPTP or IBM Tivoli products like ITM. In these cases, we need to a generic way to map the data models of these existing databases to the SDMX data model. In many cases, the mapping is non-trivial. We will also need to have extension code written to process SDMX queries into native query languages, and transformers to convert native data structures to the SDMX data formats (e.g. from jdbc result set to ket family and key concepts). These extra mapping and processing logic will become a performance issue. <br />
<br />
<Joel's Response>This is only an issue if we make it one. If the existing dataset just provides a description of it's record format in 'SDMX' form, then there's nothing to map. Also, our assemblies support Transformers, so we can always deal with this issue at the component level. </Joel's Response><br />
</Hubert's comment><br />
<br />
I think that most of our mapping issues can be solved by deciding what time periods we want to support (for a lot of cases it may be 'for all time' as a means of effectively saying that there is only one dataset), and at what level we want the URIs to actually point to more granular definitions. For example, if we say that a WEF event's URI is a Keyset URI instance, and that the WEF event's URI is terminating (in other words, doesn't have a correpsonding set of Dimensions), then we can effectively map our type information into SDMX by truncation. All that's required it to relax the schema requirements on the higher level constructs in SDMX to be 'could have' instead of 'must have'.<br />
<br />
<Hubert's comment><br />
I don't like the idea of truncating the SDMX model at a point beyond which it can't be used efficiently. For example, represent WEF events up to the keyset, and don't map attribute of WEF events to keys. We are simply saying SDMX is not suitable for all data types. It won't be very meaningful to just map a WEF event to a keyset because we can't use form an SDMX query with the contents of the event attribute values, which are very important in forming the search criteria in a query. (e.g. get all events with high severity)<br />
<br />
<Joel's Response><br />
So map the bits of WEF that make sense into a keyset, and truncate the rest. There's no reason to take an extremist stance here. Of course, you could also (once you've determined the fact that the data format is WEF) use the convinience API that would be surfaced as a MUSE capability on the DataManager endpoint to do your more granular query. Remember, we have the capability model to exploit - there's no reason to force fit anything here.<br />
</Joel's Response><br />
</Hubert's comment><br />
<br />
* Have we agreed that SDMX is the default model we support? Are we talking about query models? If so, then no - I don't think that SDMX is appropriate as our default, or at least given the proposed mapping solution outlined above, we won't be able to support the full SDMX query interface. Of course, providing limited support for SDMX queries as a WSDM capability on the DataBroker should be feasible. <br />
<br />
* What about other models, e.g. SQL? <br />
<br />
* Does the user NEED to understand SDMX to use this? It would be helpful to understand the spirit of SDMX, at least enough to know what an <br />
appropriate mapping would be.<br />
<br />
<Hubert's comment><br />
I would suggest that we do not mention the term "SDMX" in any of the COSMOS documentation, even if we are borrowing some concepts from it. Here are the reasons:<br />
*The SDMX concepts can be hidden behind some easy-to-use APIs. <br />
*It's a partial implementation (in fact a very small subset). People who really know about SDMX will say we are not using SDMX. <br />
*Most people have not seen the term "SDMX" in their lives, and let's not say they need to learn something new to use COSMOS. It will affect adoption acceptance. <br />
</Hubert's comment><br />
<br />
* How does the design support other things than SDMX. I've vote for using the WSDM capability model, so you can always support additional requirements through composition.<br />
<br />
* How do we reconcile the CMDBf query structure? This is where we can start to do some interesting things. For example, CMDBf has the concept of a 'Graph Query', which allows you to do pattern-oriented queries against the CMDB structure. This is really handy, because what we have in DC (and SDMX, for that matter) is pretty much unaware of structural implications - particularly at the instance level. So imagine that we use a CMDBf query against a compliant CMDB to identify things that are "close to" the problem we're trying to track down (and we can imagine one or more definitions of 'close to' based on puggable heuristics or norms). If we've done a proper job of mapping our SDMX-like URIs, then we are well set up to support a DataBroker query that can provide a set of EPRs that have information "close to" what's needed for problem resolution. So if we implement the DataBroker as an MDR (which means supporting the CMDBf Query API), we can use the implementation to return the set of DataManager EPRs as Target Items in the GraphQueryResponse structure. I think that's pretty cool!</div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=Talk:COSMOS_Design_197867&diff=46112Talk:COSMOS Design 1978672007-08-13T15:21:52Z<p>Joel.hawkins.compuware.com: New page: [Joel's comments] First, some general comments. One of the nice things that SDMX does is make a distinction between the structure of a set of data and the source of the set of data. If yo...</p>
<hr />
<div>[Joel's comments]<br />
<br />
First, some general comments. One of the nice things that SDMX does is make a distinction between the structure of a set of data and the source of the set of data. If you take a look at the SDMX DataFlow structure, you'll see that it breaks down into two distinct concerns. The first is the type of data (the keyset/dimension concern), and the second is the type of entity that created the data (the source concern). It makes tons of sense to me to see information related to the first concern being pushed up from DC into CMDB land, and the information related to the second concern being pushed down from CMDB into DC land. <br />
The nice thing about supporting this type of symmetry is that you can use the results of a CMDBf graph query as input to a DataBroker graph query.<br />
<br />
* How does the query work? Need better example of how to query for data. <br />
<br />
* Need example of how to map existing data to SDMX structure.<br />
** SDMX DataSet definition - DataFlow URI+ DataSource URI+ Time period<br />
** SDMX DataFlow definition - DataSource URI + Keyset URI<br />
** SDMX DataSource definition - DataSourceURI + DataSourceTypeURI<br />
** SDMX DataSourceType definition - DataSourceTypeURI<br />
** SDMX Keyset definition - Keyset URI + a list of DimensionURIs<br />
** SDMX Dimension definition - DimensionURI + Type enumeration. SDMX restricts the type of information that a dimension may hold to enumerations and simple scalar types.<br />
*** We've completely ignored the SDMX concepts um... concept, as it has a high degree of overlap with our intended use of SML/CML. <br />
<br />
I think that most of our mapping issues can be solved by deciding what time periods we want to support (for a lot of cases it may be 'for all time' as a means of effectively saying that there is only one dataset), and at what level we want the URIs to actually point to more granular definitions. For example, if we say that a WEF event's URI is a Keyset URI instance, and that the WEF event's URI is terminating (in other words, doesn't have a correpsonding set of Dimensions), then we can effectively map our type information into SDMX by truncation. All that's required it to relax the schema requirements on the higher level constructs in SDMX to be 'could have' instead of 'must have'.<br />
<br />
<br />
* Have we agreed that SDMX is the default model we support? Are we talking about query models? If so, then no - I don't think that SDMX is appropriate as our default, or at least given the proposed mapping solution outlined above, we won't be able to support the full SDMX query interface. Of course, providing limited support for SDMX queries as a WSDM capability on the DataBroker should be feasible. <br />
<br />
* What about other models, e.g. SQL? <br />
<br />
* Does the user NEED to understand SDMX to use this? It would be helpful to understand the spirit of SDMX, at least enough to know what an appropriate mapping would be.<br />
<br />
* How does the design support other things than SDMX. I've vote for using the WSDM capability model, so you can always support additional requirements through composition.<br />
<br />
* How do we reconcile the CMDBf query structure? This is where we can start to do some interesting things. For example, CMDBf has the concept of a 'Graph Query', which allows you to do pattern-oriented queries against the CMDB structure. This is really handy, because what we have in DC (and SDMX, for that matter) is pretty much unaware of structural implications - particularly at the instance level. So imagine that we use a CMDBf query against a compliant CMDB to identify things that are "close to" the problem we're trying to track down (and we can imagine one or more definitions of 'close to' based on puggable heuristics or norms). If we've done a proper job of mapping our SDMX-like URIs, then we are well set up to support a DataBroker query that can provide a set of EPRs that have information "close to" what's needed for problem resolution. So if we implement the DataBroker as an MDR (which means supporting the CMDBf Query API), we can use the implementation to return the set of DataManager EPRs as Target Items in the GraphQueryResponse structure. I think that's pretty cool!</div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=Talk:COSMOS_Design_197870&diff=46081Talk:COSMOS Design 1978702007-08-13T13:11:33Z<p>Joel.hawkins.compuware.com: New page: [Joel's comments] Client API * provide an alternate implementations of get that takes an EndpointReference. * Why do many of the 'factory' methods return WsResourceClient? Why not an ext...</p>
<hr />
<div>[Joel's comments]<br />
Client API <br />
<br />
* provide an alternate implementations of get that takes an EndpointReference.<br />
* Why do many of the 'factory' methods return WsResourceClient? Why not an extentsion of WsRescourceClient (like DataBrokerClient)? <br />
* Why are all of the instance-oriented methods static? Making these static and limiting ourselves to WsResourceClient makes it hard to expose session-oriented information later on. I'd vote for creating client classes that extend WsResourceClient, and have the static 'get' methods return instances of these classes. That way, if the static 'get' method wants to implement singleton semantics, it can easily do so without painting the extender of these client API into a corner.</div>Joel.hawkins.compuware.comhttps://wiki.eclipse.org/index.php?title=Leveraging_CMDBf&diff=45517Leveraging CMDBf2007-08-08T19:47:28Z<p>Joel.hawkins.compuware.com: </p>
<hr />
<div>This page is the beginning of where we can begin our discussions on the CMDBf specification.<br />
<br />
== Specification ==<br />
The CMDBf specification can be found here: http://cmdbf.org/<br />
<br />
<br />
== Overview ==<br />
The COSMOS project intends to produce a reference implementation of a CMDBf Management Data Repository (MDR). The project will demonstrate how a client can use multiple MDRs through the CMDBf query interfaces and registration services to display information from multiple management systems. COSMOS will also create any additional infrastructure required to support the basic use case.<br />
<br />
== Basic Use Case ==<br />
The image below is an overview of the most basic use case. <br />
[[Image:Cosmos-cmdbf-overview.gif]]<br />
<br />
* Correct the picture: In the service broker, they both should be CMDBfQuery<br />
* Add Management Domain to picture... maybe another use case for bootstrapping<br />
* Need sequence diagram for use case<br />
<br />
== Requirements ==<br />
These are the high level requirements necessary to complete the implementation of CMDBf. We will break these down into bugzilla enhancement requests. <br />
<br />
(Needs to be expanded on during the call... this is just a start....)<br />
* Query<br />
** Implement the CMDBf as a Muse capability. Bind to the CMDBf API<br />
** Start on Binding to Ali's API<br />
** Map CMDBf query to convenience APIs for SML repo, Stat repo, and CBE repo (this is the data set issues)<br />
<br />
<br />
<br />
<br />
<br />
* Registration<br />
** How do we reconcile the registration of MDRs vs. the item relationship<br />
** Do we need registration in the first round? Start with a focus on Query.<br />
* Data Broker [https://bugs.eclipse.org/bugs/show_bug.cgi?id=197867 197867: Need to design and implement the COSMOS DC Data Broker for i6]<br />
* WS-RC [https://bugs.eclipse.org/bugs/show_bug.cgi?id=198553 198553: Provide an implementatin of WS Resource Catalog]<br />
* Client updates [https://bugs.eclipse.org/bugs/show_bug.cgi?id=197870 197870: Need to design and implement the COSMOS DC client APIs]<br />
* UI work for sheldon<br />
* Reconcilliation<br />
** Need to make sure that the IDs line up or that we have only simplistic means of aligning the different resources<br />
** This gets into a bit of the taxonomies. May need simplistic mappings. <br />
*MDRs look like Data Managers<br />
<br />
* DataBroker/ProviderRegistry as MDR<br />
<br />
Based on a discussion of the proposed DataBroker design, it appears that what is desired is a combination of an EPR registry for locating DataManagers and a repository of existing data sets that can be processed by those DataManagers. From the use case described above, it appears that the ProviderRegistry should act as an MDR to surface its knowledge of datasets and there attached metadata. If we are going to adopt the CMDBf query dialect as our lingua franca for communicating topology/metadata type information, then it makes sense to apply the CMDBf query capability to both the topology repository and the SDMX-style dataset/keyset repository of the ProviderRegistry. <br />
<br />
<br />
----<br />
[[Category:COSMOS]]</div>Joel.hawkins.compuware.com