WSDMProgrammingModel

Currently COSMOS provides multiple ways for users to build WSDM endpoints for MDRs, resource manageability endpoints etc. They are:

1. Annotations
2. Resource manageability modeling and code generation

Resource Manageability Modeling:

This option allows visual modeling of the manageability characteristics of a resource (or any other manageable entity) and generate code and deployment descriptions. Users can import existing models from artifacts like schemas, WSDL files and Java classes and generate code from them after suitable modification. However the tooling today does not allow instrumentation of existing code directly - the user has to import the model from the existing code, generate endpoint code from it and tie the implementation of the endpoint code back to the original resource's code. The tooling does enable the user more control over composition of a resource from individual capability implementations and deployment options including creation of endpoint instances. It encourages and enables a build-deploy-test-debug cycle through Eclipse. The tooling is closely tied to Apache Muse and basically generates the artifacts that Muse needs. It also packages the Muse runtime and SOAP engine into the final package that is created - a WAR file or set of OSGi bundles.

Here are the (typical) steps in building an endpoint with the tooling and its deployment and runtime behavior:

1. Build model of capabilities. Can import from WSDL, XSD and Java classes.
2. Aggregate capabilities into a resource definition. The user can include predefined capabilities for standard WSRF, WS-N, WSDM capabilities and his/her own custom capability definitions. The tooling also contains basic "profiles" that allows user to include predefined typical capabilities for different "types" of endpoints.
3. User can define service group rules if the resource definition is for a service group endpoint. User can also define relationships.
4. Optionally build a deployment descriptor. User can group endpoint definitions together to be co-hosted in one runtime container instance, define initial instances of endpoints and control code generation. They can also specify existing implementation code for capabilities as long as it follows the interface defined in the tooling. This also allows users to override default implementations of standard capabilities.
5. Generate code for different deployment configurations (J2EE, OSGi on J2SE and OSGi on J2ME) and tie generated code to the back end resource implementation.
6. Deploy within Eclipse in J2EE/Equinox and test with Managed Agent Explorer
7. Export the endpoint either as WAR file or set of OSGi bundles.

Annotations:

The WSDM annotations support in COSMOS is a powerful mechanism to instrument existing code and enable it for manageability through WSDM. It allows users to compose endpoints using Java constructs and multiple inheritance through interface implementation. Currently the annotations can be used only when the final endpoint is expected to be deployed in an OSGi environment. Users are responsible for programmatically creating and managing the lifetime of the resources. Users must also take care of delegation to individual classes (or their object instances) when individual capabilities are implemented by independent classes. Annotations can be thought of a bottom up approach and is a quicker way to build endpoints. Underneath, the annotations support in COSMOS uses the Apache Muse runtime. Another important point is that annotations are useful only if the user will take care of the deployment, bundling and runtime instantiation .i.e. the annotations support expects that you have already built the code and you are enabling it for WSDM - it does not produce deployable bundles or artifacts that be deployed elsewhere. There is also an expectation on the structure of the classes that make up the manageable resource and their interfaces.

Here are the (typical) steps in instrumenting existing code for annotations and what happens underneath:

1. Annotate capability interface classes
2. Construct manageable resource class by implementing the interfaces corresponding to capabilities (both custom and standard)
3. Add code in the manageable resource class to delegate method calls to the corresponding capability classes
4. Create instances of the class and register with the OSGIResourceManager service using EPR
5. The OSGIResourceManager interprets the annotations and does the same thing that the code in Muse for interpreting the deployment descriptor file (muse.xml) does. It builds the resource instances (and their capability instances) using the Muse code and gets them running in the Muse container. Note that multiple resources registered with the OSGIResourceManager can run on the same Muse instance.

Design issues to be addressed:

1. Delegation
2. Persistence of EPRs
3. Exposing deployment options to the user. This could be through some service calls on the OSGIResourceManager