In addition to the COSMOS 1.0 use cases, there will be a number of new use cases necessary for 1.1 development. Please refer to the [[COSMOS Use Cases 1.1]] document for these new use cases.

= COSMOS Supported Use Cases for 1.0 =

= COSMOS Supported Use Cases for 1.0 =

Line 146:

Line 150:

=== Use Case: Submit a CMDBf query to an MDR ===

=== Use Case: Submit a CMDBf query to an MDR ===

−

<b><font color="green">Complete</font></b>

+

<b><font color="red">Partially Complete</font></b>

Led by: Sheldon Lee-Loy

Led by: Sheldon Lee-Loy

Line 166:

Line 170:

A generic query builder would be useful in this use case for users familiar with the CMDBf specification. This generic cmdbf query builder will allow end users to construct queries via a user interface rather than dealing with xml syntax. Validation and correctness is improved when using a user interface catered towards the CMDBf query schema. [https://bugs.eclipse.org/bugs/show_bug.cgi?id=214794 214794(19)]

A generic query builder would be useful in this use case for users familiar with the CMDBf specification. This generic cmdbf query builder will allow end users to construct queries via a user interface rather than dealing with xml syntax. Validation and correctness is improved when using a user interface catered towards the CMDBf query schema. [https://bugs.eclipse.org/bugs/show_bug.cgi?id=214794 214794(19)]

−

----

+

Launching the COSMOS UI with a MDR query: [http://bugs.eclipse.org/236907 236907]

+

----

=== Use Case: Manage CMDBf queries for a specific MDR ===

=== Use Case: Manage CMDBf queries for a specific MDR ===

Line 691:

Line 696:

----

----

−

== Generic functionality ==

−

=== SML and SML-IF validation support ===

−

Actor: web developer, Eclipse developer, COSMOS framework

+

== New Use Cases ==

−

Description:

+

'''These use cases for Discussion at COSMOS Summit 20th June,2008'''

−

#SML validator implementation for validating SML and SML-IF documents

+

==== Use Case: Query for a list of MDR’s and their Meta Data ====

−

## A web developer builds a set of XML documents that conform with the SML specification. He needs a validator to validate the XML documents. He then goes to the COSMOS web page and downloads the package containing the SML validator. Since this validator is rather small, under 1M, and not related to the COSMOS management framework, it is important to be able to download it separately from the COSMOS framework. The user validates the files by running a set of SML validation APIs provided by COSMOS.

+

−

## An Eclipse user builds SML documents. He needs a validator to validate these documents. He then points to the Update Manager site and tries to install the SML validator feature offered by COSMOS. This user will also require Eclipse based actions that integrate with the Eclipse framework: Validate SML popup action on an SML file, list of files or folder. The user can exchange data by running Export, Import to SMLIF actions on a set of SML documents.

+

−

## The COSMOS framework will exchange SML documents, packaged or not in an SML-IF envelope. This information may need to be validated, in which case the SML validation tool will be used. Depending on the location where data is validated, the COSMOS framework may require the validator to be run in or outside of the Eclipse framework.

+

−

# SML-IF editor for importing and exporting SML documents from an SML repository

+

Description: Typically when an application makes use of COSMOS it will be looking for a certain type of data for which it has a requirement eg) asset data, performance data. Alternatively the application may require access to a Data Manager for a specific data source eg)Aperi

−

## A web developer builds an SML repository. He needs to exchange these documents with other repositories. He then goes to the COSMOS web page and downloads the package containing the SML-IF import/export APIs. Since SML-IF package is rather small, under 1M, and not related to the COSMOS management framework, it is important to be able to download it separately from the COSMOS framework. The user exports and imports SML documents by running a set of SML validation APIs provided by COSMOS. The SML-IF editor, which is Eclipse based, will not be used here.

+

−

## An Eclipse user builds an SML repository. He needs to exchange these documents with other repositories. He then points to the Update Manager site and tries to install the SML-IF feature offered by COSMOS. This user will also require the SML-IF editor.

+

−

## The COSMOS framework will exchange SML documents, packaged in an SML-IF envelope. It will use a set of APIs to import and export to SML-IF. The SML-IF editor will not be used here.

+

−

# SML representation of a simple Data Center repository

+

−

## COSMOS framework may use this to define a common taxonomy for exchanged data.

+

−

## An end user may need this to play with SML and SML-IF structures.

+

−

The following conditions need to be in place to support this use case:

+

Whereas the COSMOS Broker carries basic information regarding the Data Managers that are known to COSMOS however this does not include Meta Data.

−

# The SML and SML-IF validation needs to comply with all required and optional features of the SML specification, version 1.1.

+

−

# The Data Center definition and instances should comply with this new specification.

+

−

# Any other COSMOS framework that makes use of specific SML constructs needs to support version 1.1; SML repository API may be one target.

+

−

# The SML-IF editor should match the new SML and SML-IF specification.

+

−

Ongoing work prior to 1.0 to finish supporting this use case:

+

Currently for an application to ‘find’ a Data Manager that will serve up the correct type of data it is necessary to code a loop within the application to perform this task

−

# Review the SML validator and make sure all parts of the SML and SML-IF specification are being addressed (more testcases required to validate this)

Description: The user has an artifact (for example, a .jar file, a .dll, or an .rpm). The tooling will inspect the artifact and create as much of the SDD as possible. This is useful especially in the case of a 3rd party component, where the build information is not available.

Description: The user may have a build system beyond the popular rpm, msi, etc. The tooling will need to easily accommodate adding other build systems, so that metadata from those systems could be brought in.

−

−

# The Plug-in Developer identifies the build system.

−

# The Plug-in Developer designs plug in for the build system to the BTG.

Description: The Validation Rule Developer has additional constraints that need to be validated. He/she will add the rules to the validator before running the validation. The validator will process these new rules and throw the proper error messages when they are encountered.

==== Use Case: Package Generator will bundle referenced files within an SDD and the SDD into package ====

−

Actor: Package Creator

−

−

Description: The Package Creator wants to create a package that includes all the files referenced in the SDD. He/She will specify a reference location to find the files listed in the package descriptor. The packaging program will bundle the referenced files and the SDD into one package.

−

−

# Package Creator specifies the referenced location of the files to be packaged

−

# Package Creator invokes the Package Generator with the reference location and the SDD

==== Use Case: Package Generator will use a file list to bundle files not referenced within an SDD and the SDD into a package ====

−

Actor: Package Creator

−

−

Description: The Package Creator wants to create a package that includes files that are not listed in the SDD. He/She will create a list of the needed files and pass that information to the packaging tool. The tool will bundle the referenced files in the SDD, the additional files in the user created list, and the SDD into one package.

−

−

# Package Creator creates a list of the needed files

−

# Package Creator invokes the Package Generator with the file list, the reference location and the SDD

Description: The functionality of expandable artifact input sets is analogous to the Plugin Development Environment within the eclipse IDE. The process of adding a new artifact type definition can be thought of in the same way as adding an editor in Eclipse.

−

−

# The end user clicks the Configure menu and selects "Remove Artifact Type"

−

# The runtime configuration tool examines an XML file used to track metadata about artifact types that are known and presents the name and description of each to the user

−

# The user chooses the artifacts they no longer are concerned with inspecting for input

−

# The entries are removed from the metadata file, and the corresponding inspection components are removed from the tool's resources.

Description: The functionality of expandable artifact input sets is analogous to the Plugin Development Environment within the eclipse IDE. The process of adding a new artifact type definition can be thought of in the same way as adding an editor in Eclipse.

−

−

# The end user clicks the Configure menu and selects "Add Artifact Type"

−

# The runtime configuration tool prompts the user for the location of the inspection component (which has a well-defined structure much like an eclipse plugin). The inspection component may be located from the filesystem, a CVS repository, etc. The workflow should mirror the behviour of the Eclipse IDE when you click on "Import" from the file menu or a context menu.

−

# The entries are added to an XML file used to track metadata about artifact types that are known.

Description: The author wants to change the allowable value parameters which are used to validate SDDs.

−

−

# User clicks the Edit menu and chooses "Preferences".

−

# A "Validation Defaults" link creates a window that allows user to see a searchable list of all the predefined acceptable value ranges, etc. than can be used as values within an SDD (for example, the amount of free space required for the installation on the target filesystem).

−

# User fills in default values for any property they are interested in.

Description: The author wants to change the selectable values available when creating/editing an SDD

−

−

# User clicks the Edit menu and chooses "Preferences".

−

# A "Content Constraints" link creates a window that allows user to see a searchable list of all the predefined acceptable value ranges, etc. than can be used as values within the unit type (which is specified with a drop down menu whose values are "Installable Unit", "Configuration Unit", and "Localization Unit").

−

# User selects or deselects values which should be hidden or disabled when editing SDDs.

Description: User chooses "Validate" from the tools menu within the context of editing an SDD.

−

−

# The configuration tool performs XML validation against the SDD schema and checks that the parameters entered by the user make sense. The document validates, and the user is notified with a brief notification dialog.

−

# The configuration tool performs XML validation against the SDD schema and checks that the parameters entered by the user make sense. The document does not validate, and the user is notified with a brief notification dialog.

Description: The SDD Author wants to bundle the completed SDD and any corresponding artifacts into one deliverable package.

−

−

# User chooses "Package" from the tools menu within the context of editing an SDD. <B><I>Note: We are not creating a package in the sense of an MSI or RPM... We are simply bundling the SDD (which describes those artifacts) with the associated artifacts (which themselves might be MSIs or RPMs).</I></B>

−

# The configuration tool validates the SDD (see use case 8.4)

−

# The configuration tool creates a deployable entity by bundling together into a package structure (like a self-extracting zip file) one or more Package Descriptors, the Deployment Descriptor, and the associated artifacts specified by the user.

Overview

The purpose of this page is to articulate the function that COSMOS will provide. While enhancement requests are typically created, they tend to be very fine grained or very macro. We intend to use this page to describe from the user's point of view how they can interact with COSMOS. This page as a way to capture the high level function offered by the COSMOS framework.

The emphasis of this page is for us to focus on the value delivered to the community by COSMOS.

We would like to be able to tie back the work we are doing to a specific use case. Therefore, we will add a link to the Use Case as a comment in the enhancement request.

The current scope of this page is for the delivery of M2 function. Other parts of the project, e.g. SDD, are beginning to develop their use cases. While they are in the process of defining these, we've established a work area for them to hash out the deliverables.

COSMOS Supported Use Cases for 1.0

The existing links are, in many cases quite old. Now that we have a tangible release plan, the purpose of this page is to:

Consolidate all the existing links related to use cases onto a single page

Sunset all of the old wiki pages

Consolidate the use case information for M2 onto this page

Associate enhancement requests with Use Cases. Note: It may be difficult to retroactively add the enhancements to the use cases. However, as we open new enhancements, we should map them back to a use case in this document

Provide a blueprint for the system verification tests

These use cases typically span more than one COSMOS component. Therefore, we've come up with three "categories".

MDR Enablement

(led by Jimmy Mohsin)

Related components/technologies/standards:

CMDBf

MDR

The following document outlines COSMOS commitment to the CMDBf standard:
Leveraging CMDBf

Use Case: Create a Data Manager

Complete - Bug fixes, JUnits and contextual help in i12.

Actor: Developer

Description: Developer uses COSMOS tooling to create a Data Manager. The purpose of this tooling is to facilitate COSMOS adoption.

Developer generates a Data Manager or MDR in Eclipse using the tooling. The tooling will automate many of the manual tasks for setting up the Eclipse project. Both J2EE (Tomcat) and OSGi should be supported. If the MDR interface is selected, then the generated stubs include the MDR handlersEnhancements: 208274 (i9), 220593 (future), 220594 (i11), 237161 (future)

Use Case: Construct an MDR from a product that exposes its data via ODBC or JDBC

Complete - Bug fixes in i11.

i10

This is the Aperi discussion

Actor: Developer

Description: Developer has an existing product that merely has a ODBC / JDBC interface. This product does not have a well-formed Data Adapter or Data Manager. This is a very relevant use case since many older products are fall into this category and do not have a Data Adapter of any kind.

Developer uses an exemplar implementation of an MDR which is based on a relational database.

Use Case: Register an MDR with the COSMOS framework

Complete - Bug fixes in i11.

This use case is complete in M2

211093 will be moved into a new use case and evaluated for i10.

Actor: System Administrator

Description: This use case describes the ability of adopters to register an internal data store as an MDR. The use case will elaborate COSMOS capabilities that will make registration, service implementation, and discovery of the MDR easier.

Use Case: Register a NON-COSMOS MDR

Description: System Administrator needs to install a NON-COSMOS MDR into the COSMOS environment, including registration with the COSMOS Broker.

System Administrator installs the MDR according to its documentation

System Administrator obtains the MDR's WSDL and sends it into a COSMOS utility</br>

Enhancements: TBD

The COSMOS utility extracts the CMDBf metadata from the WSDL, locates the Broker thru the Domain, and registers the MDR with the Broker (using the information from the metadata)

At this point, the COSMOS client can locate the NON-COSMOS MDR thru the Broker and access it's CMDBf query interface. If the MDR supported a known record type, then the COSMOS visualization can display the items.</br>

Use Case: Query for a list of MDRs and their status

Not complete - Need to close on consumer requirements in this space. Mark and Paul will investigate and discuss at May 16 Summit. Tentative target: i12. Need an update here for June summit

We can query for the list, but we cannot reflect the status at this point.

We will break the status gathering into a separate use case.

Mark & Bill

Actor: System Administrator

Description:

System Administrator opens the COSMOS UI

System Administrator navigates to a view which displays all the Data Managers and the MDR's

Each MDR (and Data Manager) also denotes whether it is online or offline

Enhancements: TBD

Use Case: Take an MDR "offline" or "online"

Not complete - Need to close on consumer requirements in this space. Mark and Paul will investigate and discuss at May 16 Summit. Tentative target: i12. Need an update for June summit

Actor: System Administrator

Description: The System Administrator wants to take an MDR "offline", perhaps for maintenance or for any other reason. Alternatively, she may wish to bring the MDR back online.

System Administrator opens the COSMOS UI, which displays all the data managers and MDR's

System Administrator selects the MDR she wishes to take offline (or online)

System Administrator updates the status of the MDR

Enhancements: TBD

Use Case: Submit a CMDBf query to an MDR

Partially Complete

Led by: Sheldon Lee-Loy

Description:

End users want to answer system management questions by querying information found in an MDR. Here are some example questions:

How many users are logged into the network?

How long was user X logged into computer Y on Date Z?

What is the operational status of computer Y?

The following are the steps the end user will undergo to submit their question:

The end user opens the COSMOS UI and navigates to the MDR that has the information.

The end user will open up some form of wizard or dialog box where they would enter parameters to their query.

Enhancements:

As a result the COSMOS UI should provide hooks for adopters to contribute wizards/dialog boxes. These wizards/dialog boxes provide users a means to construct queries without understanding the query language syntax.214153 (i10)

A generic query builder would be useful in this use case for users familiar with the CMDBf specification. This generic cmdbf query builder will allow end users to construct queries via a user interface rather than dealing with xml syntax. Validation and correctness is improved when using a user interface catered towards the CMDBf query schema. 214794(19)

Use Case: Manage CMDBf queries for a specific MDR

Partial query management was done in i11. Additional work required in i12 to complete this use case.

Led by: Sheldon Lee-Loy

Description:

The COSMOS Web UI provides an interface for end users to submit CMDBf queries to a specific MDR. It is useful to save these queries so that they can be reused at a later time. The end user would not need to recreate the query a the start of their session. It would also be useful for the user to have the ability to organize these queries within the navigation tree. This will allow end users to manage their queries.

The type of operations that are required for managing queries is as follows:

Use Case: Visualizing a CMDBf graph response from an MDR

Completed basic part of this use case;

Led by: Sheldon Lee-Loy

Description:

This use case continues off from "Submit a CMDBf query to an MDR" use case. At this point the end user has submitted a query and wants to understand the response received from the query. There are countless ways to organize and visualize the data so that the the end user can make sense of the data. Furthermore, there can be multiple views of the data. For example, one view of the response may be significant for business-users while another view may be significant for system administrators. Therefore views can be user context sensitive.

Enhancements:

As a result the COSMOS UI should provide hooks for adopters to contribute custom visualizations. 214158 (i10)

A generic query response view would be useful in this use case for users familiar with the CMDBf specification. This generic CMDBf query builder will allow end users to view CMDBf graph response. 214145 (i9)

Use Case: Client subscription to events

Use Case: Using COSMOS to submit queries to a proprietary data store with operational data

Complete

Description: The COSMOS framework will allow adopters to plug-in a proprietary repository that stores operational data (e.g. performance/monitoring/statistical/etc...). An adopter can use COSMOS to provide a consolidated view for all data stores that are independent of each other.

Use Case: Report generation for logging and statistical data

Complete

Description: COSMOS includes two exemplary data managers that have a database containing logging and statistical data. This use case indicates the steps that users need to perform to generate reports based on logging and statistical data

If installed properly, the logging and statistical data managers will be displayed in COSMOS client

To generate a report, the user will need to right click a desired data manager and select one of the available reports.

Use Case: Use of notification events in a CMDBf environment

This is a valid use case; we whould consider implementing in COSMOS 1.0. CA has an adopter for this use case now and this capabilitiy will facilitate adoption by one more team at CA. If it is not containable, move to future.

Description: The CMDBf specification falls short of describing a notification mechanism for item/relationship status updates. For example, if an MDR registers an item with a federating CMDB, then events need to be generated any time data is added, updated, or deleted. See lines 1557-1570 of the CMDBf1.0 specification for examples of policies that a federating CMDB can use in case of data modifications.

The COSMOS notification mechanism can help to complement a CMDBf architecture. The following use case assumes the existence of a federating CMDB.

An MDR publishes a topic to the notification broker based on item/relationship updates

An MDR registers an item with a federating CMDB

Before accepting the registration, the federating CMDB subscribes to the topic for status updates on the MDR data

The item is accepted with a positive registration response

The federating CMDB can make any required changes based on notifications produced by the MDR. If for example the item is deleted, then the federating CMDB can choose to also delete the item.

Setup & Configuration

(led by Bill)

Note: There should at least be one use case for each one of the topics below:
* Security enhancements planned for i8
* Any SDD work planned for i8/i9
* SNMP work planned for i8/i9
* Management of data managers via WSDM

A wizard is displayed where the user will be able to specify the constraints and arguments of the query

The query is submitted and the results are returned in a tabular view

The user will be able to drag and drop a set of items/relationships from the result view to a federating CMDB. Alternatively the user can drag and drop the query tree item that appears in the left panel to register all items/relationships of the query with a federating CMDB.

The selected items/relationships are registered and a view is displayed to indicate the ones that have been approved or rejected.

Security Specific Use Cases

(led by Jimmy Mohsin)

Per http://wiki.eclipse.org/Use_case_actors, the Monitor Adminsitrator role is one of the two key kinds of actors in Eclipse COSMOS, the other being System Adminsitrator. The Monitor Administrator is an Admin who is responsible for the installation, configuration, and operation of COSMOS. Given this definition, the Monitor Administrator responsible for COSMOS Security. The System Adminstrator is viewed as the the role that utilizes and accesses the MDRs.

Related components/technologies/standards:

WS-Security

Use Case: User provides credentials for an MDR to COSMOS

Completed i11.

Actor: COSMOS User

Description:

User provides username/password to COSMOS client for specific MDR with the security mechanism

Use Case: Specify Security Model on the Data Model, i.e. determine who can see which MDRs

This is out of scope. This falls under the purview of the Federating CMDB.

I18n Specific Use Cases

As detailed in the “Internationalization Support - programming model” ER 208593 COSMOS is required to provide the capability of making itself adaptable to the requirements of different native languages, local customs and coded character sets.
The following use cases describe the requirements for functionality in the COSMOS platform to support globalization. The goal is to make it possible to support delivery of applications which work properly in multiple locales with the lowest development and maintenance cost.

Use Case: Authoring of COSMOS Components for use in Non English Environment

Actor: COSMOS Developer

Description:

A COSMOS Developer needs to author a COSMOS Components eg) MDR, COSMOS UI, in a language besides English, and possibly a character set besides ISO-8859-1. This includes the operation of the COSMOS component itself, eg. logging/error messages, handling of dates/currency/numerics, Widget labels etc. as well as communications with other COSMOS components eg. Data Broker, Client API, MDR

The activities to perform localization work should be achievable without significant changes to code or functionality. Modifications to support a given locale should be limited to resource files, message catalogs and configuration entries

Verification of non-localized strings should be part of the build process. Check to see if we have an enhancement open for this.

Use Case: Process/Document for localization of COSMOS Components.

Target i10

Actor: COSMOS Developer

Description:

The procedure required to perform localization work and the entities that contain localized entries must be documented in such a way that the scope and effort to perform the work can be quantified readily. Translations should be applicable to an identifiable set of files and modifiable by non technical resources.

Enhancements: TBD

This includes the set of work to identify all of the resources that should be translated. We don't have a way to automatically "tag" or include an externalized file for translation. It's not easy to derive this set.

If you have a set of externalized files, how do you get them included in the build.

Use Case: Operation of COSMOS Components in a mixed language environment

Future

Actor: COSMOS Developer

Description:

A Developer needs to author COSMOS Components which inter operate in multiple languages. Where a COSMOS implementation is deployed across geographical locations, components may not all be operating using the same locale. Eg) A COSMOS UI localized and operating within a German locale may communicate with an MDR localized for a doublebyte locale such as Chinese Mandarin.

New Use Cases

These use cases for Discussion at COSMOS Summit 20th June,2008

Use Case: Query for a list of MDR’s and their Meta Data

Description: Typically when an application makes use of COSMOS it will be looking for a certain type of data for which it has a requirement eg) asset data, performance data. Alternatively the application may require access to a Data Manager for a specific data source eg)Aperi

Whereas the COSMOS Broker carries basic information regarding the Data Managers that are known to COSMOS however this does not include Meta Data.

Currently for an application to ‘find’ a Data Manager that will serve up the correct type of data it is necessary to code a loop within the application to perform this task

Get Data Manager from Broker

Get Meta Data from Data Manager

Check if correct type

if not goto 2

Whilst it is possible for each adopter to implement this functionality in their code, such a common task should be provided by COSMOS out of the box.

This functionality should not require that meta data be maintained in the broker, or any additional work for the broker itself.

The COSMOS adopter would use this feature thus:-

Application requires a full list of all Data Managers known to COSMOS with Meta Data

New use case: Administrator installs the base COSMOS infrastructure -- What SDD work will be in scope for i10?

New use case: How do we allow the metadata to be updated. It is a valuable use case to facilitate the manipulation of this metadata. This should not be under the security section either. (Ali/Sheldon/Bill) (update of metadata)