End-to-End use cases

This article is a work in progress. I'm hard at work making edits from the working session held Dec 4, 2006. Cthomas-cosmos.groundworkopensource.com 11:49, 5 December 2006 (EST)

This article presents the "end-to-end" use cases for Eclipse COSMOS. This work is an attempt to collect all of the key use cases under one roof, primarily for purposes of identifying scope and release phases. This high-level view of use cases also supports analysis of the opportunities for extensions built on the Eclipse COSMOS framework by commercial and open source communities.

Work on fleshing out these use cases continues, in the context of workgroups.

• The first meeting was October 31, 2006 2-3pm EST. See the minutes for more information.
• Another meeting was held on this subject on December 4, 2006, 1:30-5pm PST. See the minutes.

Actors and Use Cases

End-to-end use cases

The diagram sketches out the end-to-end use cases. Time progresses vertically, down the diagram. Note that the Software Developer actor participates in all of the use cases. This is in recognition of the development-time tasks that Eclipse COSMOS supports. Note, also, that the production-time tasks of the Data Collection and Monitor User Interface use cases depict their actors in a swimlane to the left.

Resource Modeling Use Cases

In these use cases, the Software Architect manages Resource Models. A Resource Model could be created from scratch using a model editing framework. Or, a Resource Model could be imported, either from a local model repository, from a supplier's repository (a set of Resource Models from a hardware manufacturer, or a software vendor), or perhaps it could be provided from a discovery monitor (hey, I found one of these resources at ip address 172.28.111.123).

Build to Manage Use Cases

Here, the Software Developer creates an Instrumentation Model for a Resource Model. This is either a related SML model or an extension or decoration of the Resource Model itself. The Instrumentation Model describes the measurements that are available, relevent, or required for the elements of the Resource Model.

Next the Software Developer manages the Build to Manage Tooling Model for an Instrumented Resource Model. This, again, is either a related SML model or an extension or decoration of the Resource Model. The BTM Tooling Model describes how the Instrumented Resource Model's requirements will be fulfilled with generated tooling componentry.

Finally, the Software Developer generates the BTM components and packages them for deployment.

Data Collection Use Cases

In these use cases the BTM Tooling is installed in the managed environment, and data collection is performed.

Monitor User Interface Use Cases

In these use cases, the collected data is retrieved for use in visualization.

Use Cases in Context

Simplified Model

The Eclipse COSMOS project has 2 early release milestones, 0.5 (planned for March 2007) and 1.0 (planned for June 2007). The relationship between Eclipse COSMOS and the SML standard presents some risk to these dates -- because SML is still evolving during its public review process, it is likely that there will be some adverse effect on early software developed that depends on the standard.

One approach to manage this risk is to simplify the system that we model with SML; and further, to simplify the extent of the modeling required for this simple system.

Here is a quick sketch of the system we plan to be able to model with SML in Eclipse COSMOS at its release 1.0:

Simple application system

The green boxes indicate the type of tooling we could use to observe the properties of the resource.
In order to manage the near-term risk from changes to SML, we propose to simplify this system to this model:

Very simple application system

The green boxes indicate the type of tooling we could use to observe the properties of the resource.

In the very-simple-model, each of the host, app server, and application have one property that we will observe, operationalStatus.

Resource Modeling

In Resource Modeling, genic and phenic documents are created which:

• model the class of resources and their relationships
• model instances of these classes

The models include properties that support Management Enablement:

• Properties
  • How they are observed
    • How to take the measurement

SML and Management Enablement

The Management Enablement use case is implemented by reading the SML model for the system. In our simplistic use case, there are two types of tooling needed, WSDM for the host, and JMX for the application and the app server.

Data Collection

As far as we have analyzed, Data Collection is not directly guided by SML. Instead, the ME componentry is executed according to the requirements that have been modeled, and Data Collection persists the data.

Data Collection defines the message interface for the collected data. WS-Notification will be used for this.

In the collection tooling, built by ME, the Interchange Normalization layer performs:

• collect the raw data
• adapt to normalized form
• prepare message

The Data Collection application performs:

• Apply additional normalization or transformation rules (this hook is established as an extension point for developers who are adding features)
• persist the event (and its identifiers, time stamps, original and transformed values).

Reporting

The Reporting capabilities, like Data Collection, are not directly guided by SML. Instead, the reports make use of web service obtain data.

An example report, called "Current Operation Status" has been mocked up. (Need to add link here. Cthomas-cosmos.groundworkopensource.com 19:26, 5 December 2006 (EST))

Use Cases and Platforms

Here's a quick analysis of what use cases will make use of what platform.

Platform/ Use Case	RCP	Web Browser	Development Platform
Resource Modeling	x		x
Management Enablement			x
Data Collection		x (control interface)	x
Reporting	x	x (viewer only)	x