|
DMTF Tutorial
> CIM > CIM
Schema > Common Models >
Application Model
 |
CIM Schema - Application Model
|
 |
Overview | CIM Specification | CIM Schema | Extension Schema
Core Model
| Common Models
The CIM Application Management Model describes the information
commonly required to deploy and manage software products and applications.
This model is based on the need to manage the lifecycle and execution
of applications. It can describe applications with structures ranging
from standalone desktop applications to a sophisticated, multi-platform
distributed, Internet-based application. Both a single software
product and a group of interdependent software products that form
a business system can be modeled.
The schema today incorporates three major concepts:
- Structure of an application.
- Lifecycle of an application.
- The transition between states in the lifecycle of an application.
The structure of an application is defined in the following components:
-
A Software Product is a collection of software
features that can be acquired as a unit. Acquisition implies
an agreement between the consumer and supplier, which may have
implications in terms of licensing, support, or warrantee.
-
A Software Feature is a collection of software
elements that performs a particular function or role of a software
product. This level of granularity is intended to be meaningful
to a consumer or user of the application. This concept allows
software products or application systems to be decomposed into
units that have a meaning to users rather than units that reflect
how the product or application was built (i.e., software elements).
-
A Software Element is a collection of one or
more files and associated details that are individually deployed
and managed on a particular platform. It represents the next
level of granularity after software features.
-
An Application System is a collection of software
features that can be managed as an independent unit that supports
a particular business function.
The most basic aspect of managing applications is managing their
transitions through their life cycle. The life cycle can be segmented
into four activities:
- Deployment
- Installation and configuration
- Startup
- Operation including monitoring
The model captures the following states in the lifecycle of an
application (note that state information is maintained at the level
of the software elements):
-
The deployable state describes the element in its distribute-able
form (for example, in a software repository), as well as the
details and operations required to move the element to the installable
state (i.e, the next state).
-
The installable state describes the element as ready
for installation (for example, as a zip file that can be decompressed
and installed). Also, the details and operations required to
move the element to the executable state (i.e., the next state)
or back to the deployable state can be defined.
-
The executable state describes the element as ready
to start/run, as well as the details and operations required
to move the element to the running state (i.e., the next state)
or back to the installable state.
-
The running state describes the element as it is configured
and running.
Managing an application through these states requires an understanding
of the conditions that must be true in order to change state (modeled
as 'next-state' Conditions), the conditions to verify that an element
is in a certain state (modeled as 'in-state' Conditions), and the
individual operations to change the state (modeled as Actions).
Conditions describe situations in the computer system environment
(e.g. file existence or sufficient disk space). Actions are operations
that either create a new software element or remove an existing
software element. Actions are organized into two categories: next-state
actions and uninstall actions.
This can be visualized as follows:
Taken together, these concepts (and the Application Model that
defines them) allow the lifecycle of an application to be fully
described, allowing the management of the deployment and operation
of the software.
There is additional development, ongoing today within the Application
Working Group, to manage the execution of applications. This includes
models for describing the structure of complex application runtime
environments, and the monitoring and operational aspects of applications.
In addition, it is necessary to relate the Unit-of-Work metrics
(from the Metrics Model) to the structure of applications, so that
software performance can be related to the flow of work through
the application.
|
