The concept of a service model, or service, is central to CA SOI. A service typically consists of several CIs, which you can group to represent, for example, web server farms or clusters. Services can also contain subservices, which are subordinate service models. Subservices are previously created services that are reused as building blocks of another service. Service models typically represent high-level abstract entities like a web-based retail transaction service, an application server service, a printing service, or a routing service. You can define any type of service with CA SOI as long as one of the integrated domain managers monitors the service components.
CA SOI provides a comprehensive understanding of how a fault condition, which CA SOI represents as an infrastructure alert, impacts the business. Consider a managed resource such as a router. You can accurately, but narrowly, define it as a device that forwards data from one network to another. From a service perspective, however, a router is an indispensable component among other cooperating components that support interconnected business activities.
When router performance is compromised, the activities that depend on that router are likely compromised also. A router can be associated with other network devices such as switches or servers, which are associated with the applications or databases that they host. These relationships and dependencies comprise the logical and physical topology of the service. CA SOI lets you incorporate these relationships in the service model. These relationships help you capture how one CI relates to another and how they collectively deliver the service logic.
Service models contain policy that determines how alert conditions on one CI can impact related items and the service itself. You can modify and extend this policy to refine the model and capture the collective behavior of all associated entities.
You can reuse a service model any number of times. You can also combine it with other configuration items (CIs) and services to build higher-level service models. For example, the DNS service can be critical to several higher-level services such as Microsoft Exchange and SAP. Similarly, Exchange can itself form part of still higher-level services such as email or Blackberry.
You can define new service models, import them from domain managers, or define policies that automatically discover and create services according to specified criteria. For example, an operator working with a service owner can select configuration items that are discovered through integration with the domain managers. The operator can then create relationships among those configuration items. Similarly, if a service model is defined in a domain manager, you can import that service model and all its topographic information directly into CA SOI. You can extend or combine imported service models in the same manner as the service models defined in CA SOI. This ability provides a powerful mechanism to leverage your existing investment.
|
Copyright © 2013 CA.
All rights reserved.
|
|