Leveraging SML

COSMOS Project Home > COSMOS Wiki > COSMOS Documents > COSMOS architecture

This article describes how SML is leveraged throughout the lifecycle of the artifacts created in COSMOS.

Manage Resource Models

SML and Resource Modeling

The core of the COSMOS Resource Model is the Common Model Library of SML resources. The CML is a shared repository of SML-IF documents, each of which is a model of a resource. CML resources can be simple structures, such as barebones server hardware, or complex structures such as application appliance package systems, and anything in between.

These steps describe how a Common Model Library element is managed in Eclipse COSMOS:

1. Using the COSMOS Resource Model Editor, the user obtains or creates a CML resource document. This document could be:
   1. Downloaded from an open standard repository,
   2. Downloaded from a commercial repository,
   3. Created from scratch (though this would likely be an edge case),
   4. Retrieved from a local repository and tailored
2. The CML resource document is supplemented with its observability attributes. These describe what things can be measured in the resource. For example, a disk drive can have total capacity and free space measures; a computer's CPU can have percent utilization measures.
3. The CML resource document is supplemented further with its tooling attributes. These describe what Build to Manage mechanisms will be used to implement observation of the resource's measurable characteristics.

Note that a shared repository could include a CML element with one or both of the observability attributes and the tooling attributes. In the case of a CML element for an application appliance system, this would be completely practical, as the vendor of the appliance would have assembled all of the components and could specify all of the observability attributes; if the vendor chose, the tooling attributes could also be supplied, indicating a monitoring mechanism choice. For that matter, the vendor could include the Build to Manage tooling itself in the appliance.

Also note, though, that many end users would start with a CML element, such as a computer, combine it with their company's standard RAID disk array CML element, and network interface card CML element. Each of these individual components' resource models could contain observability attributes as well as tooling attributes, and be managed in a local repository.

Benefits to Eclipse Contributors

Contributors to Eclipse COSMOS benefit from this approach through the ability to leverage standard, interoperable components, from the CML model elements themselves, through the Eclipse modules that support editing, organization, and persistence of the models and their interrelationships.

Benefits to Commercial Community

Commercial community members benefit in that the separation of the core common model elements allows interoperability, while a standard extension mechanism for specifying measurable attributes allows for differentiation and specialization. The separation of observability from tooling allows for another ecosystem of differentiation and specialization among management software vendors. That is, hardware and system OEMs can specialize in their area of expertise; IT Management providers can specialize in theirs.

Benefits to Open Source Community

Contributors to open source have the ability to construct compatible infrastructure, making use of the open standard of SML, and allowing interoperability with commercial components.

Benefits to End User Community

End users benefit through the enhanced innovation that results when interoperability is achieved. Commercial and open source providers can focus on innovation in this framework, extending reach in response to their communities' requirements.

Manage Environment Models

SML and Environment Models

The SML models described above are logical elements. When a computer is delivered and installed, or when the record of its purchase is entered into a CMDB, its physical lifetime begins. When a commercial off-the-shelf software package is purchased and installed on hardware in a network, similarly, its lifetime in the customer's environment begins.

Eclipse COSMOS, using the same workbench components, is used to create instances of the logical elements that correspond to the real-world elements in computer rooms. By supplementing the CML resource document with environment attributes, the hostname, IP address, MAC address, and other attributes that identify the real-world instantiation of the logical elements can be managed.

A series of versioned, time-stamped models of portions of these environments can be managed. (Eclipse COSMOS project will manage scope by starting with a single such environment.) A planned environment, a deployed environment, and a discovered environment would be typical of the set of managed environments.

These environments can be visualized with graphical tools, as tree structures, network models, and textual representations.

Benefits to Eclipse Contributors

Separating the management of the physical environment from its logical structural elements, allows for a high degree of reuse. While the distinction between the use cases for developing and describing the logical elements and their physical application allows an application that is patterned on users' work, the Eclipse components for each set of use cases will include many common implementations.

Benefits to Commercial Community

The extension points that associate an environment model element with common model element can be augmented to support complex features. Examples include threshold notification workflows, financial accounting models, failover and disaster recover planning, file backup features.

Benefits to Open Source Community

Contributors to open source have the ability to construct compatible infrastructure, making use of the open standard of SML, and allowing interoperability with commercial components.

Benefits to End User Community

End users benefit through the enhanced innovation that results when interoperability is achieved. Commercial and open source providers can focus on innovation in this framework, extending reach in response to their communities' requirements.

Generate Tooling

SML and BtM Tooling

Eclipse COSMOS modules that generate the tooling -- that is, the software components that perform the monitoring of observable values -- interpret the logical and physical phenic documents for the environment. This build step generates the source code, assembly and packaging instructions for the agent infrastructure that was modeled in the tooling attributes for each of the environment attributes associated. The source code can be made from templates for WSDM, ARM, and other open standard monitoring and management mechanisms, or from templates provided for commercial agent infrastructures, or both.

The end of the build step can leave tooling-specific parameters that will be supplied either in the deployment step, or supplied at run-time. This capability is a characteristic of the tooling.

Benefits to Eclipse Contributors

Generating the tooling is a step in the development phase of the COSMOS lifecycle. Much of the Eclipse componentry required for this step is available in existing Eclipse projects, from TPTP to Java tools.

Benefits to Commercial Community

Commercial providers of agent infrastructure can prepare tooling packages for resource models that they produce, extending the COSMOS framework and its components with capabilities that leverage the features of their products.

Benefits to Open Source Community

Contributors to open source can prepare tooling packages that target either commercial or open source systems.

Benefits to End User Community

End users benefit because the choices among commercial and open source providers' tooling packages allow them to select components that are consistent with their needs.

Deploy Packaged Tooling

By using the core resource model and its associated observability, tooling, and environment attributes, the chore of deploying the packaged tooling into the environment is undertaken.

Should SML be applied to this step? Seems like it could, again, be used here. One approach would be to model the monitoring software (and its hardware components and environment attributes). This knowledge could be extended with description of the deployment mechanism needed by the monitor. In some cases, configuration files in the deployment package would be written in the monitor's environment; in other cases, the monitor could offer a WSDM interface, or other management service.