Building SOA portfolio Business Services, part 10th

Part 10th: Provide governance for service consumption using WebSphere Process server and WebSphere service Registry and repository

Typically, SOA governance focuses on service providers, especially in the service lifecycle. Little attention is focused on the consumer or subscriber side. Who should be able to see or discover related service endpoints? Or, how does the person who discovers the service send the request to use the service? Or, what is the process associated with authorizing access to the service? The answers to these questions vary from customer to client. This article answers these questions in the context of a virtual prototyping composite application called the Jivaro Bank, and also describes how to use the WebSphere service Registry and Repository and websphere®process Ser Ver realizes the governance of service consumption and subscription.

Introduction

Jivaro Bank is a virtual prototyping composite application that publishes banking services in a custom WebSphere service Registry and Repository named Jivaro Bank service Registry. These services will be used by other internal customers (assuming that internal customers have user accounts in the user registry). The first article in this series builds SOA portfolio business services, part 1th: Developing SOA composite applications to support business services introduces some scenarios supported by Jivaro banking applications. The Jivaro Bank security architecture authenticates using an LDAP user registry based on Tivoli®directory Server. To authorize it, Tivoli Access Manager is used as the authorization policy decision point for its WebSphere Portal front-end and its WebSphere Process Server backend. When an internal customer is able to invoke the Jivaro banking service at run time, it is required to authorize it, and the customer also needs to agree to the specific terms and conditions stipulated in the contract between the service consumer and the provider.

To govern subscribers and consumers, the Jivaro Bank has the following policies in place:

Service subscribers must not view and use service endpoint information without prior authorization from the service provider.

Service subscribers can register an interest in a given service by completing a form or contract provided by the service provider in the service registry.

Once approved, the service subscriber should be able to view the endpoint information, have the right to call the endpoint, and automatically obtain any notification of service metadata updates.

The service provider should be able to manage the service contract with the service subscribers of the Service registry.

Any published service can have multiple endpoints that can be categorized as public or private, as well as test or production. Allows service subscribers to view only public endpoints.

This article outlines how to implement these policies in the Jivaro Bank using the WebSphere Process Server and the WebSphere Service Registry and Repository.

In the example shown in Figure 1, the potential subscriber, Mr. James Hu, wants to invoke the published Jivaro banking service in its business process, such as the Accounts payable process (in this case, the Jivaro bank Batch ACH Service for automated liquidation checks). First, he needs to subscribe to a published service. After the subscription has been approved by the administrator, he can find the public endpoint of the service and use it in his business process. Calls in the accounts payable process are routed through the Jivaro Bank Batch ACH Service mediation module, which routes the call to one of the dedicated endpoints based on multiple criteria. The mediation module uses the number of checks in a batch request as a criterion for determining which internal endpoint to route this request to. For an example of how to use the WESB mediation module with the WebSphere Service Registry and Repository, see Resources.

The Jivaro Bank registered two internal endpoints at the Jivaro Service registry:

Highvolumeendpoint (Cost: 5 minutes per check; Response Time: 2 milliseconds per check; 10000 > number of checks per batch > 1000)

Lowvolumeendpoint (Cost: 3 minutes per request; Response time: 20 milliseconds per check; 1000 > number of checks per batch > 1)

Figure 1. Jivaro Bank Service Subscriber Authorization process overview