IBM SOA Foundation product integration: Managing your WebSphere-based SOA solution

As more companies are putting service oriented solutions -- including a portfolio of services -- into production, the role of managing of these solutions becomes increasingly important. This ranges from monitoring individual services with respect to their associated service level agreements and the discovery of ”rogue” services that do not follow established protocols, all the way to the active management of an entire environment of applications, servers, and the networks that connect them. This part of our series on integrating products of the IBM® SOA Foundation looks at how to manage a WebSphere®-based SOA solution with IBM Tivoli® Composite Application Manager for SOA. This content is part of the IBM WebSphere Developer Technical Journal.

Rosalind Radcliffe (rradclif@us.ibm.com), Senior Technical Staff Member , IBM

Author photoRosalind Radcliffe is a Senior Technical Staff Member in IBM Software Group working in the Tivoli Division where she is responsible for the SOA Management Strategy, and is one of the architects responsible for the ITCAM for SOA product. Her current responsibilities include architect for the ITCAM for SOA platform bundle, as well as the relationship between Tivoli and the WebSphere ESB and Message Broker teams. Before her current role in SOA Management, she has worked in Tivoli Services, different parts of IBM development and test, and User Interface Design. She currently resides in Durham, North Carolina. When not at work, she spends time with her family.



Andre Tost (andretost@us.ibm.com), Senior Technical Staff Member, IBM

Andre TostAndre Tost works as a Senior Technical Staff Member in the IBM Software Services for WebSphere organization, where he helps IBM customers establishing Service-Oriented Architectures. His special focus is on Web services and Enterprise Service Bus technology. Before his current assignment, he spent ten years in various partner enablement, development and architecture roles in IBM software development, most recently for the WebSphere Business Development group. Originally from Germany, Andre now lives and works in Rochester, Minnesota. In his spare time, he likes to spend time with his family and play and watch soccer whenever possible.


developerWorks Master author
        level

18 June 2008

Introduction

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
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
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
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
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
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
    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
    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
    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
    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
    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
      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
      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.


Summary

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.

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into Business process management on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=Business process management, WebSphere, Tivoli, SOA and web services
ArticleID=314588
ArticleTitle=IBM SOA Foundation product integration: Managing your WebSphere-based SOA solution
publish-date=06182008