Load balancing with Websphere Service Registry and Repository

This article guides you through the steps required to create a load balancing feature in a mediation module. You'll learn how to set up WebSphere® ESB to implement a custom mediation for WebSphere Service Registry and Repository, how to query Service Registry and Repository to retrieve content through an API, and how to identify scenarios in which you might want to use load balancing.

Muhammed Yaseen Muriankara (muhammedyaseen@in.ibm.com), SOA Architect, IBM

Muhammed Yaseen photoMuhammed Yaseen Muriankara is an SOA Architect at the IBM India Software Lab in Bangalore, India. He has over nine years of experience in software development, and has been architecting solutions for the past six years. Prior to working at IBM, he was an ESB and service registry and repository architect, and is now working with IBM Business Partner Technical and Strategic Enablement to enable systems integrators and partners in SOA and WebSphere products. You can reach Yaseen at muhammedyaseen@in.ibm.com.



22 August 2007

Introduction

Multiple instances of a service are often used to provide high availability, load balancing and scalability. These qualities of service are often provided by Websphere XD or hosting the services in a clustered environment. However, in situations where this isn't possible, for example when the service implementations already exist and are provided by different vendors or when services are available and are hosted on heterogeneous systems that cannot be clustered, or when non-clustered versions of the services already exist, a mechanism is needed to provide the appropriate routing to those services during execution time. In cases like this, Websphere Services Registry and Repository (hereafter called Services Registry and Repository) can host the metadata necessary to achieve the load balancing between those services. Websphere Enterprise Service Bus (hereafter called ESB) provides the run-time capability for such routing. This article takes you through the steps required to create a load balancing feature in a mediation module. You'll learn how to set up ESB to implement a custom mediation for Service Registry and Repository, how to query Service Registry and Repository to retrieve content through an API, and how to identify scenarios in which you might want to use load balancing.

To get the most out of this article, you should have a basic understanding of Service Registry and Repository and mediation development in ESB, as well as a good understanding of Java™ programming, Web services standards, and architectural and design patterns.

The evolution of business in terms of responsiveness, dynamicity, and flexibility is perpetual. One of the key catalysts to this evolution is automating the processes and sub-processes within a business. SOA has gained popularity and acclaim as a way of architecting automation because of its low cost and faster time to market. The most popular and interoperable way for a business to create an SOA is to use Web services over HTTP. The composite and atomic Web services that form part of an architecture should meet certain qualities of service (QOS), such as:

  • Availability (is it running)
  • Integrity/reliability (will it crash while I run/how often)
  • Throughput (how many simultaneous requests can I run)
  • Latency (response time)
  • Regulatory (conformance to standards)
  • Security (confidentiality, authentication)

In this article, we'll focus on availability and integrity.

The use cases for this scenario as modeled in Rational Software Architect V7 are shown in Figures 1, 2, and 3.

Figure 1. Use case from a user perspective
Figure 1. Use case from a user perspective
Figure 2. Use case from a business analyst perspective
Figure 2. Business Analyst
Figure 3. Use case from an IT architect perspective
Figure 3. IT Architect perspective

The solution to the above use cases is the following architecture, as shown in Figure 4.

  1. Service Registry and Repository is populated with the service-related metdata
  2. The request from the customer is directed to ESB mediation module, which handles the service routing based on the services metadata from Service Registry and Repository.
  3. The routing logic and implementation can be reused across multiple mediations by making the logic an API hosted in a shared library on the ESB server.
  4. The API is called from the custom mediation module and queries Service Registry and Repository for endpoints, then returns the next endpoint based on the routing logic.
  5. The queried results from Service Registry and Repository are cached to improve performance.

Figure 4 illustrates this architecture:

Figure 4. Architectural overview
Figure 4. Architectural overview

Figure 5 summarizes the sequence of operations. The components do not provide a one-to-one mapping, but the figure explains the sequence.

Figure 5. Sequence diagram
Figure 5. Sequence diagram

The router API

For many use cases, the endpoint lookup node would be sufficient, but for added functionality, such as the use cases in our example, we would need to use the rich set of APIs provided by Service Registry and Repository. As illustrated in Figure 4, the router API builds on top of the Service Registry and Repository API. The API also maintains a single metadata cache in the ESB server, hence reducing traffic between ESB and Service Registry and Repository.

The API's core class is called WSRRUtils, in which the following are of interest:

  • getInstance method
  • getNextEndpoint method
  • CACHEUPDATE field

The code below connects the utility to the name server on which Service Registry and Repository is running, and returns the single instance of the utility class.

String nameServer="corbaloc:iiop:localhost:2812";
com.ibm.bptse.wsrr.WSRRUtil ut=
com.ibm.bptse.wsrr.WSRRUtil.getInstance(nameServer);

As shown in the code segment below, you can modify the cache refresh rate by changing the value for CACHEUPDATE. The default is 3000 seconds, after which it queries Service Registry and Repository again to populate the cache.

com.ibm.bptse.wsrr.WSRRUtil.CACHEUPDATE=3000;

The query sent to the Service Registry and Repository is based on the values set in the HashMap, where "Name" corresponds to portType and "CustomProperty" specifies the custom properties to be looked for in SOAPAddress metadata. You can add more custom properties by separating the key value pairs by commas as shown below.

java.util.HashMap map= new java.util.HashMap();
map.put("Name","HelloWorld");
map.put("CustomProperty","isAlive=true");

You can add more custom properties by separating the key value pairs by commas as shown below.

map.put("CustomProperty","isAlive=true,BizKey=Partner");

String endpoint= ut.getNextEndPoint("MediationKey",map);

The code snippet above populates the cache and returns the first endpoint on the first call. On subsequent calls the endpoints are returned in round-robin fashion. The "MediationKeyquot; parameter uniquely identifies a routing table for a particular mediation so that each mediation flow gets routed in round-robin fashion.

You can extend this API as needed. For example, you may need to extend the behavior of caching to incorporate JMS notifications from Service Registry and Repository to dynamically update cached content. Service Registry and Repository sends out notifications when an item is created, updated, or deleted. The cache that is used by the routing logic can feed on these notifications and choose to add, remove, or update cache data.

Let's consider a scenario where IBM Tivoli® Composite Application Manager for SOA (ITCAM for SOA) is not a part of the IT infrastructure, and the service being used goes down. In this situation, when the next invoke happens from the ESB, the service invocation returns an error. The solution to this is to update the Service Registry and Repository metadata related to the service, so that availability of the service is recorded as isAlive=false. The cache is also updated at the same time to indicate that the endpoint is no longer live. When the service invocation in an ESB mediation flow results in an error, you can use the router API to get the next endpoint and route the request to the next available endpoint.

Deploying the API

The API jar file available in the Download section can be deployed as a shared library, which means that you can use it across multiple mediation modules. The cache is centralized so it is easy to manage and would reduce traffic from the ESB to Service Registry and Repository. In future parts of this series, we'll look at further advantages of shared library deployment, such as increased availability and integrity using Service Registry and Repository and ESB.

Adding a shared library is a basic activity in Websphere Application Server, so is not covered in this article.

Identifying usage scenarios

Not every service is a likely candidate for multiple instances, especially if the services use locks on shared resources like databases, or semaphores or critical sections on any shared resource leading to situations where only a single thread has access to the process. Fortunately there are many processes that allow for multiple thread access, such as transformations, reporting, most data reads, complex calculation routines, and so on. Examples of such services are credit reports, last ten credit card transactions for a user, financial and statistical reports, e-mail inbox reads, and so on. These services are all good candidates for multiple instances.

Populating metadata in service registry and repository

Service Registry and Repository is a centralized registry and repository capable of storing both data and metadata. Service Registry and Repository is an ideal place to store the artifacts relating to a service, such as the WSDL, and metadata, such as example operations, custom properties, classifications, and more. Service Registry and Repository makes it easy to find the data or metadata of interest, while providing capabilities for governing the artifacts, notification and subscription mechanisms. In our scenario we have a set of services that performs the same function but at different locations or by different service providers. This section describes how to upload a WSDL and add relevant metadata to Service Registry and Repository.

Uploading a WSDL to Service Registry and Repository

Before you start, collect the WSDLs and related schemas in a folder in the file system or locate the WSDL URL where the service is located. Then do the following:

  1. Open the Service Registry and Repository Web user interface.
  2. Select to Service Documents => Load Documents.
    Figure 6. Load documents
    Figure 6. Load documents
  3. Either specify the local path to load the dependent schemas and WSDL files manually, or select Remote file location and specify the WSDL URL to have Service Registry and Repository automatically load the dependencies.
  4. Specify a description and version and click OK.
  5. Repeat the previous steps to upload the second WSDL.

Adding metadata

The metadata in this case should show the state of availability of the service at the endpoint location. The Service Registry and Repository would automatically populate for you all the metadata available in the WSDL like ports, message, services etc. Here we add a custom property to the Port metadata called ‘isAlive’ which when ‘true’ means the service is available and false when service is down. Service Registry and Repository can be integrated with ITCAM for SOA to do this automatically when service goes down but as of now let us assume that has been taken care of either by ITCAM for SOA or Service Registry and Repository Admin user. So that when a query is performed from Service Registry and Repository this property value is used to get the live endpoints.

To upload metadata to Service Registry and Repository, do the following:

  1. Open the Service Registry and Repository Web user interface.
  2. Select Service Metadata => Services.
  3. Select the appropriate service from the list.
  4. Select Ports under Additional Properties.
  5. Select Properties under Additional Properties.
  6. Click New and add a new property called isAlive with a value of true, as shown in Figure 7, and click OK.
    Figure 7. Add isAlive property
    Figure 7. Add isAlive property
  7. Verify that the new property is listed with the other port properties, as shown in Figure 8.
    Figure 8. Verify isAlive property
    Figure 8. Verify isAlive property

Creating the mediation

Figure 9 shows the mediation scenario.

Figure 9. Mediation scenario
Figure 9. Mediation scenario

The client invokes the virtualized Hello service exposed by the ESB. The mediation routes each of the invocations from the client request to the next available endpoint.

As shown in Figure 10, the mediation assembly has an import and an export. The export exposes the Hello service to the service consumers, mediation does the routing, and the export defines the Hello partner service that is invoked.

Figure 10. Mediation assembly diagram
Figure 10. Mediation assembly diagram

First approach

For the sake of simplicity, the preferred approach to creating the mediation is to use the Endpoint Lookup primitive provided with ESB, which has the following advantages:

  • Connection to Service Registry and Repository is managed by the ESB server through Service Registry and Repository definitions
  • The primitive has a built-in caching mechanism

The mediation flow diagram for this approach is shown in Figure 11:

Figure 11. Mediation flow - first approach
Figure 11. Mediation flow - first approach

In the above flow, the Endpoint Lookup primitive (EPLookup) is configured to return all endpoints that match the given criteria by specifying the match policy as return all matching endpoints. The endpoints are set to the SMO header at XPath /context/primitiveContext/EndpointLookupContext. The Route is a custom mediation with a Java implementation that collects all the endpoints from the SMO header, then selects one based on routing logic (in this case, round-robin) and sets it to /headers/SMOHeader/Target/address. The callout uses the endpoint value set to the above XPath in the SMO header as the endpoint to route the invocation.

The Java code for this custom mediation is shown in Listing 1:

Listing 1. Custom mediation code - first approach
java.util.List
seq=input1.getList("/context/primitiveContext/EndpointLookupContext");
java.util.List epList= new java.util.ArrayList();

for (int i = 0; i < seq.size(); i++) {
	commonj.sdo.DataObject array_element =
(commonj.sdo.DataObject)seq.get(i);
	epList.add(array_element.getString
("endpointReference/Address/value"));
	
}

com.ibm.bptse.wsrr.WSRRUtil ut= 
com.ibm.bptse.wsrr.WSRRUtil.getInstance();
String endpoint= ut.getNextEndPoint("Key", epList);

commonj.sdo.DataObject dObj
=input1.getDataObject("/headers/SMOHeader");
dObj=dObj.createDataObject("Target");
dObj.setString("address",endpoint);

return input1;

The first section gets the endpoints from the SMO header and populates it to an array list. The second section returns the next selected endpoint based on the routing logic implemented within WSRRUtil. The third section sets the endpoint to /headers/SMOHeader/Target/address.

This approach would be useful in cases where each service endpoint is assumed to be highly and continuously available. When the service goes down or a new service is available it will not be reflected in the cache until the cache update time expires.

Second approach

Consider using the second approach to create the mediation if the requirements of your use case are not met by the first approach. The second approach provides some additional flexibility, as described in The router API.

Another advantage of this approach is that the connection to the Service Registry and Repository server relies on the mediation rather than the ESB server, which means that a restart of the server is not required if the Service Registry and Repository IP address changes.

The custom mediation shown in Figure 12 hosts the logic and implementation behind the load balancer. The response tab is wired directly to the output.

Figure 12. Mediation flow - second approach
Figure 12. Mediation flow - second approach

The custom mediation uses the API to get the endpoint, which is set to /headers/SMOHeader/Target/address. The callout uses the endpoint value set to the XPath in the SMO header as the endpoint to route the invocation.

The Java code for this custom mediation is shown in Listing 2:

Listing 2. Custom mediation code - second approach
String nameServer="corbaloc:iiop:localhost:2812";
com.ibm.bptse.wsrr.WSRRUtil ut=
com.ibm.bptse.wsrr.WSRRUtil.getInstance(nameServer);
com.ibm.bptse.wsrr.WSRRUtil.CACHEUPDATE=3000;
java.util.HashMap map= new java.util.HashMap();
map.put("Name","HelloWorld");
map.put("CustomProperty","isAlive=true");
String endpoint= ut.getNextEndPoint("Key",map);

commonj.sdo.DataObject dObj
=input1.getDataObject("/headers/SMOHeader");
dObj=dObj.createDataObject("Target");
dObj.setString("address",endpoint);
return input1;

The first and the second sections of the code were described previously. The third section shows how you can set the endpoint address to the XPath /headers/SMOHeader/Target/address in the SMO header.

Testing the mediation

You can use Websphere Integration Developer to test mediation modules. To do that, open the mediation module and the associated assembly diagram, then right-click the mediation component and select Test Component. This opens the universal test environment, in which you can test the component.

You can also test the mediation by exporting it with an HTTP binding and using a Web service client to test it.

Troubleshooting

There are two problems that you might encounter when invoking the ServiceRegistrySession bean from a WebSphere Application Server, WebSphere ESB, or WebSphere Process Server server.

Unable to lookup ServiceRegistrySession bean.

Context: The WebSphere Application Server, WebSphere ESB, or WebSphere Process Server server is running on the same node as the Service Registry and Repository server and both are called server1 (in different cells).

Solution: Add the following Java Virtual Machine (JVM) property to either the Service Registry and Repository or the ESB server under Application servers => server1 => Process Definition => Java Virtual Machine => Custom Properties: com.ibm.websphere.orb.uniqueServerName=true.

DataFactory fails to create the Service Registry and Repository objects, such as GraphQuery object.

Context: WebSphere Application Server, WebSphere ESB, or WebSphere Process Server has an older version of the SDO library (for versions prior to V6.1)

Solution: Put the Service Registry and Repository client libraries (especially sdo-int.jar) in $WAS_HOME/classes (for WebSphere Integration Developer, it will be $WID_HOME/runtimes/bi_v6/classes), so that the V2 SDO classes used by Service Registry and Repository are loaded by the WebSphere Application Server, WebSphere ESB, or WebSphere Process Server server instead of the V1 SDO classes.

Conclusion

In this article, you've seen how you can use Websphere Service Registry and Repository and Websphere ESB to achieve load balancing between multiple instance of services, including:

  • How to identify scenarios where multiple instances of services can be used.
  • How to use and extend the Service Registry and Repository API.
  • How to identify and add metadata that could represent a state of service and use that metadata to query Service Registry and Repository to retrieve valuable information.
  • How to build and implement custom mediations to leverage Service Registry and Repository integration capabilities in ESB.

Download

DescriptionNameSize
Project filesProject_Interchange.zip89KB

Resources

Comments

developerWorks: Sign in

Required fields are indicated with an asterisk (*).


Need an IBM ID?
Forgot your IBM ID?


Forgot your password?
Change your password

By clicking Submit, you agree to the developerWorks terms of use.

 


The first time you sign into developerWorks, a profile is created for you. Information in your profile (your name, country/region, and company name) is displayed to the public and will accompany any content you post, unless you opt to hide your company name. You may update your IBM account at any time.

All information submitted is secure.

Choose your display name



The first time you sign in to developerWorks, a profile is created for you, so you need to choose a display name. Your display name accompanies the content you post on developerWorks.

Please choose a display name between 3-31 characters. Your display name must be unique in the developerWorks community and should not be your email address for privacy reasons.

Required fields are indicated with an asterisk (*).

(Must be between 3 – 31 characters.)

By clicking Submit, you agree to the developerWorks terms of use.

 


All information submitted is secure.

Dig deeper into WebSphere on developerWorks


static.content.url=http://www.ibm.com/developerworks/js/artrating/
SITE_ID=1
Zone=WebSphere, SOA and web services, Business process management
ArticleID=244826
ArticleTitle=Load balancing with Websphere Service Registry and Repository
publish-date=08222007