The concept of a service model, or referred to simply as a service, is central to CA SOI. A service typically consists of several CIs, which are grouped to represent entities like web server farms or clusters. Services can also contain subservices, which are subordinate service models. Service models typically represent high-level abstract entities like a web-based retail transaction service, an application server service, or a source control service. You can define any service type 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 through an infrastructure alert, impacts the business. Consider a managed resource such as a router, which you can accurately but narrowly define 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 the router are often compromised as well. You can associate a router to other network devices, such as switches or servers. In turn, you can associate these devices 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 to capture how one configuration item 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, and you can combine it with other configuration items 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 itself can form part of higher-level services such as email, Blackberry, and so on.
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 can select configuration items that are discovered through integration with the domain managers and can create relationships among those configuration items. Similarly, if a service model (such as a business process view in CA NSM, a service model in CA Spectrum, or a service CI from the CA CMDB) 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, providing a powerful mechanism to leverage your existing investment.
Note: For more information and procedures about working with service models, see the Service Modeling Best Practices Guide.
|
Copyright © 2013 CA.
All rights reserved.
|
|