Bringing Visibility to your Services with Oracle Service Bus

We recently finished a project where the requirements were to enhance an existing service to support new client requirements and also to provide non functional requirements related to operational and business visibility such as:

  • Monitor the number of requests
  • Overload protection by controlling the number of requests
  • Historical reports on how many were processed, how long they took, how many succeeded, failed etc.

The current architecture for the application was based on WebLogic Platform. The architecture was enhanced to include Oracle Service Bus as all of the above functionalities are provided out of the box with the service bus and thus we were able to complete all the requirements in a span of couple of man weeks.

This article will discuss how each of these requirements is implemented with Oracle Service Bus.

The concepts and terminology of Oracle Service Bus can be found here

Existing Interface:

Web Services Client -> Web Services Endpoint

New Interface with Service Bus:

Web Services Client -> Web Services Endpoint

Requirement #1 : Monitoring

The key requirements here were:

  • How many times has the service been called?
  • What is the average response time?
  • How many requests had errors?
  • What is the minimum response time?
  • What is the maximum response time?

In order to get statistics such as number of times a proxy has been called etc, operational monitoring on the proxy needs to be enabled. It can be enabled by clicking on the proxy and enabling the monitoring as shown below.

OSB Visibility

Once the monitoring is enabled, the runtime statistics for the service can be viewed by going to Operations -> Dashboard-> Service Health and clicking on the proxy service you are interested in.

OSB Visibility

In order to get the statistics at the operation level, click on operations as shown below.

OSB Visibility

Requirement #2: Overload Protection by controlling the number of requests

The requirement here was -

  • Control the maximum number of concurrent requests that can be sent to the service end point.
  • Reject the additional requests.
  • Provide visibility on rejected requests so that appropriate tuning can be done.

Oracle Service Bus provides the ability to throttle the number of requests in the Business Service. Throttling can be enabled by clicking on the Operational Settings of the business service. By enabling throttling, one can set

  • Maximum requests that can be sent to the service end point
  • Maximum number messages can be left in the queue before message is to be expired and a failure message is sent to the client
  • Message expiration interval.

Here is the screenshot for setting the above parameters.

OSB Visibility

In order to see how many messages were throttled at run time, you can go to Operations->Dashboard and click on the Business Service you want to monitor. Clicking on Service Metrics shows the Throttling characteristics. Be aware that throttling data can be seen here only if monitoring is enabled for the business service.

The screenshot below depicts the throttling characteristics.

OSB Visibility

Requirement #3: Historical Reporting

The requirement here was to report all the errors and its details for a period of time.

Oracle Service Bus provides a mechanism where messages can be persisted to a reporting database. The persistence is done asynchronously using JMS for performance reasons. In order to write the errors into the reporting database, one can use the Report action in the error handler and write the ./soap-env:Fault/detail/error.

The screenshot below shows a proxy using the Report action.

OSB Visibility

These errors can be viewed by Operations->Reporting->Message Reports. Details of the message such as SOAP faults can be viewed by clicking on the index fields as shown in the screenshot below.

OSB Visibility

Conclusion

By leveraging these out of the box functionalities, Oracle Service Bus decreased our implementation and testing times many fold. We have implemented time consuming custom overload protection mechanisms in our previous projects and thus appreciated this out of the box functionality very much. We have not touched upon other operational features such as alerts and SLA management that Service Bus provides. The reader is encouraged to explore these operational features of the service bus to enhance visibility of their deployed services.