This series of articles on integrating products that are part of the IBM SOA Foundation addresses specific challenges that arise as part of establishing a service oriented architecture. Each of the introduced scenarios starts out with a conceptual solution that is later implemented for certain products and technologies. On a conceptual level, the solution applies across several products, making it simpler to describe how it works. In this respect, all of the articles in this series follow the same basic flow.
These articles are also all based on the SOA Foundation Reference Model. This article looks at the management aspects of a service oriented solution. Management goes across many of the individual functional parts of the model, which is reinforced by the fact that the Management Services component sits to the right of the Model, as shown in Figure 1.
Figure 1. IBM SOA Foundation Reference Model
From a product perspective, this also means that the products supporting solution management will have to integrate with other products in the SOA Foundation. Later, you will see several examples of integration between IBM Tivoli Composite Application Manager for SOA and other products that are part of the platform.
The SOA Foundation lifecycle presents another perspective on the issue of solution management. The lifecycle outlines the stages that services go through and the types of activities that occur at each stage. The Manage component of the lifecycle (Figure 2) will be the focus here.
Figure 2. SOA Foundation lifecycle
Finally, to complete your collection of viewpoints to SOA, you can decompose a service oriented solution into a number of layers, resulting in what is called the SOA Solution Stack (Figure 3), which shows again how management is one aspect of the solution that applies to all of its layers.
Figure 3. SOA Solution Stack
Letâs begin by looking at how management and service orientation come together.
Managing the overall SOA environment
Services should be considered as one more resource in the management domain. Services have the usual management challenges in areas of security, availability, configuration, and performance as traditional resources, but there are differences. Services are application layer components. Whereas most systems management tools are oriented toward middleware, network, operating system, and hardware types of resources, services are an interface to a tangible entity; in other words, services tend to separate the interface from the underlying implementation. These services participate in the business process and can be reused by different business processes. The requirements for managing a service vary based on the business process in which it participates, which adds to the management challenge. To a user in a service provider environment, the service itself is the only entity that is exposed or available to help understand the service level agreement, or to assist in managing the service. The application behind the service might be out of reach for management.
There are more challenges for services than just resource management challenges. Managing dependencies of the services to each other, as well as to the underlying applications and systems, is as important as managing the services themselves. Services can be bound to specific (and multiple) service level agreements. For example, a service might be optimized for gold customers versus silver or bronze customers.
While services address many of the traditional problems of integrating disparate business processes and applications, deploying services-based environments introduces new complexities that must be managed. Some of the new complexities related to management include:
- Monitoring the Services layer for performance and availability.
- Ensuring compliance with multiple service level agreements for the same service.
- Tracking the dynamic interconnectivity of loosely-coupled components in the system to understand the performance, availability, and expense consequences.
- Root cause analysis and correcting problems in services based on errors in the infrastructure supporting the Services layer.
- Tracking the business impact of services on the business processes that the services support.
- Managing the service in context of the supporting infrastructure.
Managing the solution layers from the Services layer through the infrastructure to the base operating system can be accomplished using IBM Tivoli Composite Application Manager (ITCAM) for SOA. This platform consists of a bundle of products that includes ITCAM for SOA, ITCAM for Web Resources, OMEGAMON® XE for Messaging, and IBM Tivoli Monitoring. This solution provides a single environment for the entire stack that will be monitored and managed. This article will focus only on the services layer, and for that, the focus will be on ITCAM for SOA. You can use the SOA Solution Stack introduced above to position where SOA management applies, as shown in Figure 4.
Figure 4. SOA management added to the SOA Solution Stack
Putting ITCAM for SOA and WebSphere products together
With this conceptual background, we look to implement SOA management solutions using products within the IBM SOA Foundation. ITCAM for SOA offers management capabilities specifically geared towards managing services, embedded into an overall IT management solution based on Tivoli products. Weâll start out with an architectural overview of how ITCAM for SOA interacts with the various components of an SOA environment, and then look at the specific technologies that are applied to integrate with the core SOA-related WebSphere products.
Monitoring of the services layer is done by adding management capabilities, agents, and data collectors to the existing infrastructure. By adding agents and data collectors to the environment to manage all of the services and the Enterprise Service Bus, a complete picture of the services flow can be derived and used for management.
Each message is intercepted at client request, server enter, server leave, and client response. Records are cut for all four locations. This information is then used in the calculation of the summarized information provided to the management infrastructure.
All the individual records are used by the Web services navigator to display the individual transaction data. Figure 5 shows how the data collectors tie into each individual part involved in the flow of a message.
Figure 5. ITCAM for SOA data collectors
For each monitoring environment, the data collector is the component that is updated. The agent is used for all environments managed. Integration with WebSphere (and other) products is accomplished by providing data collectors that are embedded into each productâs runtime. Below are descriptions of these data collectors for various WebSphere environments:
ITCAM for SOA and WebSphere Application Server
A JAX-RPC system handler is used when managing the services that are hosted on WebSphere Application Server. This handler intercepts each message flowing in and out of the server, enabling basic monitoring capability, such as counting messages and capturing fault information, as well as calculating the response time for each request.
ITCAM for SOA also provides some basic mediation capability within the handler by providing the ability to log the message, the header, the body, or the full message, as well as the ability to reject messages, by returning a SOAP fault when a request is received. Message logging can be turned on for all messages, or configured for a particular port or operation. Similarly, faults can be configured for all messages, particular ports, or operations, as well as for the host name or IP address of the requester.
ITCAM for SOA and WebSphere Message Broker
ITCAM for SOA provides monitoring for the WebSphere Message Broker (hereafter referred to as Message Broker) environment through the use of the Message Broker tracking exit, which enables the tracking of all messages flowing through the Message Broker environment. ITCAM for SOA provides support for SOAP and non-SOAP messages flowing over HTTP, MQ, or JMS. Figure 6 shows a sample representation of the collection for a message broker flow. ITCAM for SOA correlates a flow to a service to be monitored.
Figure 6. WebSphere Message Broker data collector
The collected information about the flow of a message can then be visualized in the IBM Tivoli Enterprise Portal, which serves as the front end to the management runtime. For example, Figure 7 shows a typical service flow, with a single icon representing the Message Broker flow.
Figure 7. Service message flow visualized in the Tivoli Enterprise Portal console
ITCAM for SOA and WebSphere ESB or WebSphere Process Server
ITCAM for SOA provides support for WebSphere Enterprise Service Bus (ESB) and WebSphere Process Server environments in two ways. First, it provides monitoring of the Service Component Architecture (SCA) components. As shown in Figure 8, message handlers (prior to Version 6.1 of WebSphere ESB and WebSphere Process Server) provided the method for monitoring the SCA components; this monitoring provided the same monitoring capabilities as the JAX-RPC handler but without the management function, which was performed with mediation modules. Notice ITCAM for SOA monitors the flow at the component level, not at the module level.
Figure 8. Data collector for WebSphere ESB and WebSphere Process Server
In Version 6.1, WebSphere ESB and WebSphere Process Server have a new observer interface for monitoring which makes it is easier for ITCAM for SOA to collect all the appropriate data for synchronous and asynchronous messages.
In the operational flow shown in the portal console, you can see both the SCA components and the mediations represented. An example is shown in Figure 9. Notice that the interface provides a different icon for those items representing a mediation; mediations are shown with a pipe in the background of the icon. This way, SCA components that are not mediation flow components can be easily distinguished from those that are.
Figure 9. Service message flow including various monitored SCA components
The second way that ITCAM for SOA supports WebSphere ESB is through a set of managed mediation primitives, which are shipped with ITCAM for SOA and are installed in your IBM WebSphere Integration Developer environment. These new managed primitives can be used the same as standard primitives, but they provide one additional capability: they can be enabled or disabled via simple Take Action commands in Tivoli Enterprise Portal. The primitives provided are log, filter, route, and transform. When using the primitives, they can be deployed either enabled (the default) or disabled.
ITCAM for SOA and WebSphere DataPower
A proxy approach is used when managing a WebSphere DataPower SOA Appliance. Since no additional software is installed on the appliance, the proxy is built to communicate to the DataPower management interface. Through this interface, the details for the messages flowing through the DataPower appliance are communicated to the management infrastructure. The DataPower appliance handles the calculation of the correlator, as well as the insertion of this correlator into the SOAP header for the message. By including the correlator in the message flow, the DataPower appliance can be shown in the overall message flow. Figure 10 shows a DataPower appliance in an example service flow.
Figure 10. Service message flow including a WebSphere DataPower SOA Appliance
ITCAM for SOA and WebSphere Service Registry and Repository
Integration with the IBM WebSphere Service Registry and Repository (hereafter referred to as Service Registry) can done in one of two ways:
Collect Service Registry service definitions for import into ITCAM for SOA to understand the observed versus registered services.
This integration is provided through a discovery library adapter (DLA) that pulls the services definitions and meta data associated with the services out into a DLA file. This file then can then be loaded into ITCAM for SOA (as well as several other products, like IBM Tivoli Business Service Manager or the IBM Tivoli Change and Configuration Management Database). When loading the DLA file into ITCAM for SOA, a list is generated so you can easily see what services have been observed by monitoring (in ITCAM for SOA) versus which services have been registered (in Service Registry), as shown in Figure 11.
Figure 11. Observed versus registered services
This overview gives insight into which services actually exist and are utilized in a run time environment, as compared to services that exist in the registry.
Send situation events to Service Registry to indicate the performance of the service operations.
This integration sends âsituation eventsâ from ITCAM for SOA to Service Registry, adding a custom meta data property to the port associated with the invoked service operation. This situation event feed is achieved by creating a âsituationâ in ITCAM for SOA; when the situation fires, it is sent out as an Event Integration Facility (EIF) event to the registryâs EIF receiver. The EIF receiver is configured to receive the events and specifies what action to take with each event (and adding appropriate information to the service port). Within Service Registry, this additional run time meta data can then be seen by looking at the custom properties assigned to the port, and retrieved to make intelligent routing decisions in an ESB, to name one example.
Figure 12 shows the Service Registry administrative console, listing a number of the custom properties filled in via ITCAM for SOA.
Figure 12. Service Registry service meta data from ITCAM for SOA
ITCAM for SOA and WebSphere Business Monitor
At a high level, monitoring in the context of Business Process Management can be looked at in two ways: monitoring the business process from a business perspective, or monitoring it from more of an IT perspective.
ITCAM for SOA and WebSphere Business Monitor cover both of these aspects. They each collect different types of information, geared towards different audiences, and together provide complementary monitoring information about a solution.
SOA brings new opportunities and challenges to solution management. You need to incorporate SOA management planning throughout your transition to an SOA environment. The key is to manage the environment in an integrated fashion, ensuring the appropriate monitoring at each layer, but integrating all layers together to provide a comprehensive and coordinated view. IBM SOA Foundation solutions provide this comprehensive and coordinated view, from business and services monitoring to monitoring detailed resources.
- IBM SOA Foundation product integration: Using WebSphere Transformation Extender with IBM Enterprise Service Bus products
- IBM SOA Foundation: An architectural introduction and overview
- IBM WebSphere Transformation Extender product information
- IBM WebSphere Message Broker product information
- IBM Tivoli Composite Application Manager for SOA (ITCAM for SOA) product information
- ITCAM for SOA with WebSphere -- IBM Tivoli Open Process Automation Library
- Integration between IBM Tivoli Composite Application Manager for SOA and WebSphere Service Registry and Repository
- ITCAM for SOA Event Handler for WebSphere Service Registry and Repository SupportPac
- Configuration guide for ITCAM and the DataPower SOA Appliance
Dig deeper into Business process management on developerWorks
Get samples, articles, product docs, and community resources to help build, deploy, and manage your cloud apps.
Keep up with the best and latest technical info to help you tackle your development challenges.
Software development in the cloud. Register today to create a project.
Evaluate IBM software and solutions, and transform challenges into opportunities.