White Papers
Abstract
WebSphere DataPower appliances play a critical role in any enterprise in various capacities, such as Enterprise Service Bus, caching. Effective monitoring of the appliance ensures that the real value of the appliance is achieved in a consistent fashion. Due to its distinguished nature of being an appliance, it has its own ways of being monitored. This article series walks through the importance of monitoring the appliance, key monitoring requirements, methods of monitoring, as well as help decide on the right monitoring approach for your requirements.
Content
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 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. 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 the beauty of DataPower appliances, we focus only on the monitoring aspects of DataPower. For interested readers, refer to the Related topics section. 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. 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. A policy can 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), 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, that contribute to the overall functioning of the appliance. They are also important from a monitoring perspective. Appliances are positioned at a critical juncture in the lifecycle of a message. They can 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. 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 can go up and the device can become unusable or restart. Therefore, this impacts the function of the appliance, and, breaches the quality of service. Monitoring of the appliance helps ensure that all the objects are working as expected. Any potential issues can be identified before they occur and proactive steps can be taken to handle them immediately. 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. This section provides a technical overview of these alternatives. Providing monitoring solutions for IT systems is one of the key capabilities of the IBM Tivoli Following are some of the key benefits of using the Tivoli monitoring suite: 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 variousf protocols, such as HTTP, FTP, IMAP, SCP, and POP3 to name a few. It is 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 that uses SOMA with cURL: As we understood, SOMA is an XML-based management interface. The SOAP service exposed by the DataPower appliance can also be invoked by 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. 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 can 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.Introduction
Overview of the DataPower appliance
Components of the appliance

Monitoring the appliance
Monitoring options
IBM Tivoli monitoring
SOMA through cURL
SOMA through Java
Recommendations
Conclusion
Acknowledgments
Was this topic helpful?
Document Information
Modified date:
08 June 2021
UID
ibm11109625