Health checking the IBM WebSphere DataPower SOA Appliance and its services

Question

What are some common methods to use health checks against an IBM WebSphere DataPower SOA Appliance from an external scanner or load balancer?

Cause

There are many considerations to evaluate for a particular environment and requirements. Refer to the pertinent load balancer or external scanner manuals for configuration options.

Answer

There are many different ways to do health checking; this document covers some common methods that you may want to consider:

1. Simple TCP connection/port check (a lightweight example)
   
   Depending on requirements, you may want to use the most simple and "lightweight" health check that accomplishes the desired result while minimizing overhead on the backend/network.
   
   One method that could be used to mark a DataPower Appliance as "down", could be to configure the Load Balancer or External Scanner to do a simple TCP Connection/Port check to see if DataPower is responding on the network.
   
   Advantage: extremely simple, lightweight, and low overhead
   
   Disadvantage: can only determine TCP layer response and may mark the Appliance up even though the actual HTTP/HTTPS response for a Service may be wrong, empty, incomplete, or unavailable.
2. Full Request and Response check (a heavyweight example)
   
   One method to make sure a particular DataPower Service Object is up and responding with the full expected response is for you to configure the Load Balancer to send a full request to that service and expect a particular response or string in the full response.
   
   Advantage: can confirm the proper full response is generated and available since this checks the whole service.
   
   Disadvantage: can create unnecessary overhead and load on the Service, especially if the health check occurs often.
3. Check if the Service Object is operational (a middleweight example)
   
   Another method could be to configure the DataPower Service Object to match on a particular URI on the Front-End request rule (for example /healthcheck) and generate a static response.
   
   The Load Balancer could be configured to send a request that targets this particular DataPower Service Object with this particular URI (/healthcheck) and the Load Balancer could respond appropriately depending on the response.
   
   This would check to make sure a specific Service Object within DataPower is "up" and goes beyond a simple TCP check.
   
   Furthermore, at the same time, you could configure within the DataPower Service Object to use a Load Balancer Group for the backend.
   
   This could leverage the "built-in" DataPower Load Balancer Group health check to determine if the backend (relative from DataPower) is up/down.
4. Service Monitoring
   The most sophisticated approach utilizes extensive monitoring and logging, which is referred to as Service Monitoring. IBM offers a service monitoring product.See your sales representative if you'd like more information.

5.  Perform health checks. The load balancer in IBM WebSphere DataPower routes requests to the registered backend service providers according to a chosen algorithm, such as Round Robin (there are several algorithms available). When a backend service provider becomes unresponsive, you want IBM WebSphere DataPower to stop routing requests to that provider. IBM WebSphere DataPower allows for a health check request to be sent to the service provider to poll for its state of health. It is important to design an entry point into your service that can be used efficiently for a health check—one that can verify that the service is up and able to respond to requests without burdening the overall load of the environment.

 6. Don’t rely on custom HTTP return codes. Pitney Bowes’ Web application uses a considerable amount of JavaScript that executes in the browser. Some of the calls back to the server use custom-defined HTTP returns for certain error conditions and drive appropriate behavior in the browser. Since all of the traffic between the browser and the server is proxied through IBM WebSphere DataPower, these return codes were also expected to pass through IBM WebSphere DataPower. Unfortunately, IBM WebSphere DataPower has a fixed table of allowable return codes and will reject responses from the backend, preventing them from passing back to the client through the WAF. Peebles doesn’t suggest relying on the use of custom HTTP return codes, even though the specification allows it. There is always the possibility that the spec may change over time to introduce new standard codes that may conflict with the codes you are using and, as Pitney Bowes found out, some of the networking infrastructure between the end user and the actual application may reject the codes or behave in unexpected ways.