Monitoring WebSphere DataPower, Part 1

Fundamentals of monitoring


Content series:

This content is part # of # in the series: Monitoring WebSphere DataPower, Part 1

Stay tuned for additional content in this series.

This content is part of the series:Monitoring WebSphere DataPower, Part 1

Stay tuned for additional content in this series.

This 3-part article series covers the various options of monitoring the WebSphere DataPower appliance. The series focuses on alternatives and strengths to help you decide on the best approach for your requirement. This article, Part 1, describes the fundamentals of monitoring an appliance, its importance, and the options available. It is a starter guide for subsequent parts by setting the fundamental layer. It lays the groundwork for Part 2, which dives deeper into the IBM® Tivoli-based monitoring option. It is followed by Part 3, which describes using the SOAP Configuration Management (SOMA) interface of DataPower through cURL and Java technology as an example.

Overview of the DataPower appliance

With the evolution of computing power and more structured data processing, we always are in need of high performing solutions. Software solutions have their own limitations in terms of performance, time to procure and configure, and so on. This led to the importance of pre-built, pre-configured appliances called DataPower. Being an appliance, DataPower provided ease of ownership and sped up the process of setting it up. It comes with high performance XML processing and various other features that depend on various models of the appliances.

While this is an interesting topic in itself to discuss about the beauty of DataPower appliances, we will focus only on the monitoring aspects of DataPower. For interested readers, refer to the Related topics section.

Components of the appliance

An appliance consists of a set of objects that work together in a configured manner to perform in a desired way. These objects are configured by the administrator of the appliance. From an integration appliance perspective, Figure 1 depicts the hierarchy of the objects.

Figure 1. Components of DataPower
Components of DataPower
Components of DataPower

To configure the appliance to perform the desired function, a service needs to be instantiated and configured. There are different types of services in an appliance that are provided based on the type of appliance. Each appliance has common services and advanced appliances that are configured for special needs with advanced services. For example, an integration appliance (XI52) has XSL proxy, XML firewall, WS proxy, and multi-protocol gateway as available services.


Each service requires a processing policy. This policy defines the processing that is carried out when this service is invoked. The policy object depends on multiple other objects, such as front-side handlers, rules, XML manager, and so on.


A policy may have multiple rules attached to it. These rules are reusable objects and can be used by multiple policies. Rules are identified with the direction of invocation (for example, request, response, and so on), priority, and its associated actions.


An action is the basic processing unit within a rule. These are the operations that are applied to the message in a defined sequence.

Along with the above objects, there are supporting objects, such as front side handler, log targets, file systems, and so on that contribute to the overall functioning of the appliance. They are also important from a monitoring perspective.

Monitoring the appliance

Appliances are positioned at a critical juncture in the lifecycle of a message. They may act as a gatekeeper to guard systems from threats, provide mediation capabilities to deliver the messages at the right destination in expected manner, secure the infrastructure from denial of service attacks, and so on. With a higher level of dependency on the appliance, organizations expect it to continue performing its expected duties in a consistent fashion. It translates to performing the expected functionality with expected performance at the expected time of the day.

As an example, if not monitored properly, the CPU utilization may go up and the device may become unusable or may restart. This impacts the function of the appliance, and therefore, breaches the quality of service.

Monitoring of the appliance helps ensure that all the objects are working as expected. Any potential issues may be identified before they actually occur and proactive steps can be taken to handle them immediately.

Monitoring options

You can monitor an appliance in multiple ways. The selection of the method is a decision that depends on multiple factors, such as cost, complexity, skills, strategy, and so on. This section provides a technical overview of these alternatives.

IBM Tivoli monitoring

Providing monitoring solutions for IT systems is one of the key capabilities of the IBM Tivoli® family of products. It helps optimize the IT infrastructure performance and availability. The IBM Tivoli monitoring suite consists of software agents and other supporting components that monitor the DataPower appliance. It is an enterprise grade suite of products that are specifically designed to ease and automate the monitoring of systems like DataPower.

Following are some of the key benefits of using the Tivoli monitoring suite:

  • Enterprise grade monitoring solutions provide reliability, scalability, and high performance.
  • Out-of-the-box agents are available for DataPower.
  • A reduced time to set up results in no required development – only the agent installation and configuration are required.
  • A choice of pre-integrated notifications engines is available for organizations such as eMail, FTP, and so on.
  • Integrated performance and capacity management are available to monitor, alert, and report on future capacity bottlenecks.
  • Flexibility allows integration with advanced analytical tools.
  • An enterprise portal for a central location allows viewing and acting on information provided by IBM Tivoli Composite Application Manager (ITCAM) and other agents.
  • Support is available for multiple operating systems.
  • Product level quality and support are available for any issues.

SOMA through cURL

As an alternate for automated monitoring of the DataPower appliance, the SOAP Management Interface (SOMA) comes handy. It is based on SOAP standards and uses XML-based commands to inquire about the status of different objects of the appliance. You can use this interface to modify the configuration and perform operations on the appliance as well. However, those aspects of the interface are out of scope for this article.

cURL is a command line tool for transferring data with a URL syntax. It supports a variety of protocols, such as HTTP, FTP, IMAP, SCP, and POP3 to name a few. It is a free and open software and runs on multiple operating systems. It is reliable and highly portable. Its easy-to-use interface makes it popular for all types of projects, be it open source or commercial.

Following are key points to consider when you monitor the DataPower appliance using SOMA with cURL:

  • It is lightweight because it does not require any platform or an application server to run.
  • It is supported on most operating systems, and therefore, highly portable.
  • It does not involve licensing costs, and therefore, it is a cheaper option.
  • It requires a short learning curve to understand various SOMA commands and their functions.
  • Development effort is required to code the monitoring scripts, which requires formulation of SOMA commands and parsing the output as well as various authentication requirements.
  • It is "pull" based monitoring, where commands have to be invoked on regular intervals to get the status.
  • The quality of the monitoring module is directly dependent upon the skills of the team.
  • Any requirement for reporting and data warehousing the statistics for future reference would be separate.
  • If any kind of integration is required with existing monitoring solutions in the enterprise, it has to be evaluated.
  • Custom development effort is required to integrate with notification engines such as SMS, eMail, and so on.

SOMA through Java

As we understood, SOMA is an XML-based management interface. The SOAP service exposed by the DataPower appliance can also be invoked by Java™ or any other programming language that supports a SOAP-based service invocation. Because this topic is beyond the scope of this article, we will focus on the SOMA interface through Java.

The SOAP/HTTP service provides a platform independent interface to invoke a service. It is an industry standard and supported by all the recognized platforms and products. Let us look at the key features of monitoring the DataPower appliance by using the SOAP/HTTP interface through a platform like Java.

  • Similar to SOMA through cURL, this is also lightweight as it just requires the underlying JVM minimally.
  • Java is a popular skill and easily available. This is a favorable point for this approach.
  • It is supported from all the platforms that support JVMs – the majority of modern day operating systems.
  • There is no licensing cost involved, which makes it an attractive option.
  • The effort required for skill building on the SOMA interface is similar to the cURL alternative.
  • It requires custom development to invoke the SOMA commands and to parse the response, which means investing time and cost as well as skill development.
  • It is also a "pull" based monitoring solution that fetches status information on scheduled intervals.
  • Reporting requirements have to be separately evaluated since they require customization.
  • Evaluating the integration requirements with existing monitoring solutions in the enterprise is allowed.
  • Notification requirements, such as SMS, eMail, and so on, need to be custom designed since this is a completely home-grown solution.


Based on the above features and highlights of different type of monitoring alternatives, you can evaluate and decide a suitable approach. The decision depends on multiple factors. Some of these factors are purely on technical merits, while others may be related to cost, schedule, resource availability, skill availability, or other constraints in the organization.


This article described various approaches of monitoring WebSphere DataPower appliances to help you evaluate and decide the right approach. Proceed to the next article in the series to learn about each approach.


The authors would like to thank Rakesh R. Nair for his review of the article series. Rakesh is a WebSphere DataPower specialist and has led many DataPower-based engagements for worldwide customers.

Downloadable resources

Related topics


Sign in or register to add and subscribe to comments.

Zone=WebSphere, Tivoli, Tivoli (service management)
ArticleTitle=Monitoring WebSphere DataPower, Part 1: Fundamentals of monitoring