COSMOS Programming Model Discussions

Overview

Programming model has two main areas of discussion:

1. The design and implementation of the COSMOS framework
2. The programming model for users of the COSMOS project to extend the framework

Design of the framework

Objectives:

• Use of WSDM Muse to expose interfaces, and use of standard web services from MUSE to manage resources
• Need a lightweight implementation
  • minimize dependencies
  • minimize footprint
  • provide basic functionalities to support required use cases
• Extensibility (for new features, and pluging in custom implementation of certain parts of the implementation)

Changes in the broker and domain implementation (proposal)

• use WSDM tooling or Muse toolkit to create the endpoints for broker and domain
  • not to use assembly as the base.
  • no reference to SDMX registry
• Clear separation of client and server
  • server code doesn't need to be packaged with the client
    • e.g. DataBroker depends on org.eclipse.cosmos.dc.remote.wsdm.spec.DataBrokerClient
• Use WSDM web services to "self-manage"
  • e.g. operational status, description, ID,
• Use service groups to manage data managers in broker
• broker registry
  • EPR: not to separate EPR into URI and resource ID, and reconstruct the EPR from them. Treat EPR is a single entity
  • classification, dialect -> replace with a list of supported operations (to confirm)
    • How to get the list of supported operations?
• Required functions:
  • get list of broker info objects search by "operation"
• Database
  • consider removing iBatis
  • derby vs. XML
  • separate databases for each component.

Programming Model for Adopters

• Provide adopters with a well defined procedure (possibly with the help with toolings) to create data managers, MDRs and CMDBf query processing logic.
• Brokers and domain: should be a complete application out of the box. Deployment involve configuration files. May provide extension point for deployers to plugin another version of data store.

There are 2 main approches to creating an MDR:

1. using WSDM Tooling / Muse Tooling
2. using annotation

WSDM Tooling

1. COSMOS provides a capability implementation for the DataManagerCapability. This capability has implementation for
   • configuration values in muse.xml
   • start() - start up capability, initialization, handshake with domain and broker to register MDR
   • stop() - notify broker of the offline status of the MDR
2. Provide WSDL of the CMDBf query service
3. Use WSDM Tooling to
   • configure MDR endpoint to include data manager and query capabilities
   • generate code for the CMDBf Query capability => deployment environment specific
4. Provide implementation of query capability
5. COSMOS can provide GUI specific for COSMOS Toolkit to make the process easier

Annotations

Programming model using annotations

Comparison

Here is a discussion of a comparison of the two approaches (written by Balan): http://wiki.eclipse.org/WSDMProgrammingModel

Here is a comparison of the two approaches:

• the annotation approach is easier to use, especially for those new to WSDM. The use of Java syntax to hide the complexity of WSDL, muse.xml, etc. The WSDM Tooling can be very useful in reducing the complexity of the WSDM. However, this tooling is still immature, and has many problems to good user experience.
• The annotation approach is also makes it easier to make changes to the endpoint definition during development. The Muse/WSDM Tooling approach require the regeneration of the stub code and merging the difference into the working project.
• A resource is represented by a Java class, which implements interfaces that are annotated as capabilities. The resource class is equivalent to the muse.xml. (programmatic approach vs. declarative approach) Annotation requires all capabilities to be implemented in the same class, or by sub-classes or super classes. Muse allows capabilities to be implemented by separate classes, and the implementation can be more easily reused. (Joel mentioned a deligation model which allows implementation of capabilities to be implemented by classes not in the same class hierarchy, but I don't have the details.)
• Selection of standard capabilities. Muse allows an endpoint to be configured to include a selection standard capabilities provided by muse, but the annotation approach doesn't allow you to do this.
• The annotation approach doesn't allow resource and capability implementation class to get the reference of the resource manager, and can't get information about the wsdm running (e.g. EPR).
• The current annotation implementation only supports OSGi running environment.

Future directions:

• WSDM Tooling can provide features to instrument Java code using annotations
• Make the two approaches interoperable
• Make the two approaches more similar in terms of features, testing and deployment
• Adopt JAX-WS (Java API for XML web services) standard

Deployment Environment

i.e. running COSMOS outside eclipse!

1. J2EE
2. OSGi
   • OSGi in server (e.g Tomcat)
   • Server in standalone OSGi container

Comments:

• Getting a correct combination of OSGi bundles to run in a standalone OSGi container is difficult.
  • Any automated way to do that?
  • Xerces vs. XML from Java 5: classloader/classpath problem?

COSMOS Toolkit/SDK

• Development environment - install a number of plugins into eclipse workbench
• Include examples and documentation on how to extend the COSMOS framework.
• Developers will create extensions to the COSMOS framework in the eclipse workbench environment.
• Testing environment: WSDM Tooling allows the launching of endpoints within eclipse
• Export the end result into deployment enviroment
  • J2EE, OSGi
  • Server component
  • Client component

Packaging

The discussion below is specific for data collection. Resource modeling deliverables follow traditional eclipse build and packing practices. The web visualization packaging will need to have a package considering like the one below.

SDK:

• package all plugins/bundles required for development (framework, examples, documentation, dependencies)
• Developers will download and install the bundles in the eclipse workbench.
• Prerequisites:
  • WTP: for testing and debugging J2EE deployment
  • WSDM Tooling: for creating endpoints

Production (Runtime):

• The runtime of the data collection framework runs outside eclipse, and can be deployed in a distributed environment.
• Unlike most eclipse projects, the runtime is not a zip file with eclipse plugins.
• Management domain and broker are components that should be able to run out-of-the-box. We can ship a war file for each application. Users deploy the war file in a web server. Update configuration file, and perhaps configure a database for registries.
• COSMOS only ships a framework for creating MDRs. MDRs are not runnable out-of-the-box. Adopters will need to provide an implementation, and create a build specific for their MDRs. The packaging and building of MDRs are mainly the responsibility of the adopter. We can provide tools or scripts to make the work easier, e.g. fetch the required OSGi bundles and generate config.ini file.