fast and scalable asynchronous processing with websphere extreme scale

8/9/2019 Fast and scalable asynchronous processing with WebSphere eXtreme Scale

1/11

IBM Extreme Transaction Processing (XTP)patterns: Fast and scalable asynchronousprocessing with WebSphere eXtreme ScaleSkill Level: Intermediate

Robert Wisniewski ([email protected])Technical EvangelistIBM

26 May 2010

Modern enterprise systems are being confronted with the need for more complexprocessing, coupled with higher loads and greater demand for resources. This realityis driving a need for separation of functional units and motivating the use ofasynchronous methods to accomplish work and aggregate results. This articledescribes an example that brings the power and scalability of IBM WebSphereeXtreme Scale to work on the problem, providing nearly limitless flexibility and

expandability to the asynchronous paradigm.

Introduction

Even the most casual observers of technology must be aware of the migrationtoward systems and services that can perform increasingly more complex tasks withmore data sources than ever before, and all with an interface that's even easier touse. Mash-up is the term thats been coined to express this concept. For example,providing comprehensive and detailed street maps is good. Adding current trafficdata to the maps is even better. And including the closest place to get lunch with

user ratings? Now thatscool.

Whether it's something for the average consumer or within the massive grids of afinancial trading system, the trend is obvious. Making more decisions based on moredata sources more quickly is becoming vital to cutting-edge systems. Luckily, we'restarting to learn exactly what it takes to get these kinds of problems solved, and oneof the best tools for this evolution is a move from synchronous, linear processing to

Fast and scalable asynchronous processing with WebSphere eXtreme Scale Copyright IBM Corporation 2010. All rights reserved. Page 1 of 11
mailto:[email protected]://www.ibm.com/legal/copytrade.shtmlhttp://www.ibm.com/legal/copytrade.shtmlmailto:[email protected]


2/11

more responsive asynchronous processing. These asynchronous patterns areespecially useful for integrating information from disparate and possibly externaldata sources. This asynchrony also provides perceived responsiveness for users, aswell as best case overall throughput for the system as a whole. By delegating tasksto asynchronous requests within a scalable processing infrastructure, more optimal

and efficient system utilization can be achieved.

When depending upon outside sources of information, it is important to decouple theseparate application tiers and link them together more loosely, solving the scalingproblem individually for each tier. This is not only an easier problem to solve, butalso, in the presence of delay or downtime from the data sources, the client isn't leftwith an unresponsive or non-functioning mess. This decoupling adds the ability tooffload, retry, and prioritize work tasks as needed.

The pitfalls of synchronous processing in a scale-up environment are related to theexhaustion of resources spent waiting on non-responsive or temporarily overloadedcomponents of the infrastructure. In a synchronous scenario, a slowly respondingexternal resource or fully utilized connection pool will tie up the upstream processingthreads until the bottleneck is alleviated. This will continue up stream all the way tothe client experience, as each sequential resource is tied up waiting on thebottleneck.

With an asynchronous model, the queue itself acts as a relief valve. The slowcomponent is isolated behind the queue, and the biggest effect is requests buildingup in the queue, which will eventually catch up. Even if it never does, only theservices dependent on the slow resource will be affected. This decoupling has aneffect on the overall system that will prevent bottlenecks during scale-up simply dueto the fact that each resource is able to act independently.

WebSphere eXtreme Scale and asynchronous processing

Although IBM WebSphere eXtreme Scale is most widely and commonly used as anelastic grid, there are key features of WebSphere eXtreme Scale that enable it to bea prime and suitable candidate to help solve the asynchronous problem. One featureis its ability to deploy a processing agent into a grid and direct the grid to invoke this"agent" on each entity sent into a particular map. We have used that capability andgeneralized it into a set of functions that essentially turn a POJO entity into a"message." You provide the code for the agent, which is business logic that youwould like executed asynchronously.

This framework is the WebSphere eXtreme Scale asynchronous serviceframework, which is a library that you can utilize with WebSphere eXtreme Scale inyour applications to give you the ability to asynchronously process work in a reliableand scalable manner. Because this framework is in fact a library or application usingstandard WebSphere eXtreme Scale capabilities to perform this function (as any

developerWorks ibm.com/developerWorks

Fast and scalable asynchronous processing with WebSphere eXtreme ScalePage 2 of 11 Copyright IBM Corporation 2010. All rights reserved.
http://www.ibm.com/legal/copytrade.shtmlhttp://www.ibm.com/legal/copytrade.shtml


3/11

WebSphere eXtreme Scale deployment would), we will refer to this framework as asample. However, the intention of the sample is to hide some of the details andprovide an intuitive interface to deploy this asynchronous processing without a lot ofhassle.

There are several benefits to using WebSphere eXtreme Scale over the establishedframeworks (such as JMS and other messaging infrastructures) for asynchronousprocessing:

Simplicity: WebSphere eXtreme Scale and the asynchronous serviceframework can be deployed as a few JAR files in the classpath of aJava SE environment.

Scalability: The processing of the asynchronous work happens on thegrid nodes themselves. This could be the same JVM that issued therequest, or -- even better -- it could be one of thousands of grid partitions

deployed. The flexibility of WebSphere eXtreme Scale is such that if youneed the processing to happen faster, you need only deploy more JVMsto the grid processing the messages. This is what we characterize aselasticity, making the asynchronous service framework an elastic queue.

Reliability: Just as WebSphere eXtreme Scale replicates and handlesapplication objects, the same function is applied on the asynchronousmessages within the grid. You can eliminate single points of failure withthe processing system given an adequately deployed and replicated grid.

Most of the benefits above can be attained in some form with other asynchronousframeworks, but usually with greater expense and a steeper learning curve.

Figure 1. WebSphere eXtreme Scale asynchronous service frameworkarchitecture

ibm.com/developerWorks developerWorks



4/11

An example

Let's implement a simple "Hello World" application to illustrate the simplicity of theWebSphere eXtreme Scale asynchronous service framework. This example willdispatch a message into the grid, identify which grid partition has been assigned toprocess the message, and return that information back to the dispatcher. While thisis a simple example, you'll see the core concepts in action, which you can apply to awide variety of applications.

Figure 2. Developer's view of the framework




5/11

The message POJO

First, you need to define the message itself, as well as the business logic to beprocessed. Do this by creating a POJO that implements the "serializable" interface.

This interface indicates that the object can be sent as a parameter with a remotemethod call, which is the basic requirement of any object being inserted into aWebSphere eXtreme Scale grid.

Listing 1. Sample message object

package com.ibm.websphere.asyncservice.test;

import java.io.Serializable;

public class TestMessage implements Serializable {

private static final long serialVersionUID = 7894711850787375307L;

public int id;

public TestMessage(int id){this.id = id;

}

}




6/11

This object serves as the data container for the work that needs to be done uponreceipt of the message in the grid. In this case, youll stick to a single Integer fieldwhich will be used as a unique identifier and enable you to track the progress of amessage through the grid.

When such an instance is inserted into the grid, the grid partition that receives themessage will execute the logic in the message listener using the data in the instancevia a local pool of threads devoted only to processing these requests. We'll call thispool a processing unit, with one pool hosted in each shard. Configuration of theprocessing unit can be achieved with some use of the Spring framework (to becovered in an upcoming article). By default, each processing unit uses three threads,and since this is replicated for each partition, it would likely be ideal for many typesof applications.

The listener (MessageProcessor)

To implement the message processing logic, you need only create a class thatimplements thecom.ibm.websphere.objectgrid.asyncservice.MessageProcessor interface,which only requires the implementation of a method called onMessage. Thismethod is passed a unique message ID, a reference to the grid where the messagewas sent, as well as the message itself as an object. The code for this is shown inListing 2.

Listing 2. Sample message processor

package com.ibm.websphere.asyncservice.test;

import java.io.Serializable;

import com.ibm.websphere.objectgrid.Session;import com.ibm.websphere.objectgrid.asyncservice.MessageProcessor;

public class TestProcessor implements MessageProcessor {

public Integer onMessage(Session session, String msgId, Serializable msg){

int partitionId = session.getObjectGrid().getMap("Queue").getPartitionId();TestMessage testMsg = (TestMessage) msg;System.out.println("SHARD: Message " + testMsg.id + " processed by partition "

+ partitionId);return partitionId;

}

}

This example returns an Integer object that identifies the processing partition's ID tothe process/thread that initially sent the message. The asynchronous serviceframework will take this value and fulfill the Future object that was returned to theclient so that any client processes interested in this value will then be able to




7/11

consume and use the validation information.

Future is a data type introduced in the Java 5 concurrency framework, and isspecifically meant to be "filled" later, with methods provided to check if the value iscurrently assigned, or even block and wait until the value is assigned. The eventual

return type is not specified by any of the asynchronous service interfaces orimplementation classes, leaving the return type your choice, which can be anyserializable data type.

One particular detail to note is that there is a single instance of aMessageProcessor for each processing unit partition. The asynchronous serviceframework ensures this by utilizing WebSphere eXtreme Scale's shard event listenerinterfaces. This instance is used for all messages that are sent into the partition,making members of this class thread safe and providing the opportunity to cacherequired resources. You would do that here, for example, if the message processorneeds to make a datasource lookup or other expensive resource connection. Bykeeping it as a member field in this class, you can safely cache these expensiveresources.

The client

Let's take a look at what you would do to send one of these messages into the gridand process the result.

Listing 3. Asynchronous framework client example

AsyncServiceManager aservice = new AsyncServiceManagerImpl(clientGrid);

TestMessage msg10 = new TestMessage(10);Future response = aservice.sendAsyncMessage(msg10);

System.out.println("{CLIENT: Message " + i + " was successfuly processed by partition "+ responses.get(i).get() + ".}" );

Apart from the brief code segment in Listing 3, there is also a bit of code needed tocreate the connection to the grid represented by the clientGrid object, which will becovered next when we discuss WebSphere eXtreme Scale deployment details.

Once the message has been sent, the sender can store a reference to the Futureobject and check periodically for completion, or it can block and wait if needed by

calling the get() method. The code in Listing 3 shows a blocking call, in which theclient waits until the messsage has been processed to report which grid partition waschosen to consume the message.

The source code and deployment files for this example are included with this articlefor download. In addition, youll find links for obtaining the asynchronous serviceframework as well as a fully functional trial version of WebSphere eXtreme Scale inthe Resources section.




8/11

The grid

The included sample grid can be started and deployed in two ways. The first is asimple in-process catalog service and container, which is convenient fordevelopment environments and quick testing. For the second, scripts are provided to

deploy standalone grid containers which might be deployed across a cluster ofmachines. This would be the standard type of deployment for a production orperformance testing environment.

In-process gridDeploying and running the sample with an in-process grid is the easiestway to see these concepts in action. A script is provided to run the client.When this script is run with no arguments, the grid is automaticallydeployed in-process. No other changes are necessary. If you've importedthe code into Eclipse or a similar IDE, simply run the main method fromthe com.ibm.websphere.asyncservice.test.TestClient class to accomplish

the same function.

Remote gridStart by launching a catalog service, which is described in the scriptsincluded with the sample. You can find these scripts in the bin directory ofthe sample code and need only change the JAVA_HOME variable inenv.sh to reflect the path to your desired JVM, and the directory wherethe WebSphere eXtreme Scale product code is located.

To start the catalog service, simply execute the script runcat.sh

Some deployment information is required for the grid JVMs themselves,but they need little or no customization to work in nearly any environment.The names of the maps and grids are all used by the asynchronousservice framework itself and have no need to change. This information isstored in the deployment.xml and objectgrid.xml files in the sample,and you can use them to start your grid JVMs. All of these configurationdetails are in the provided scripts, so to start a container JVM, run thecommand: runcontainer.sh .

With your server processes started, you can connect to and use the gridby retrieving your reference to the WebSphere eXtreme Scale grid in the

client with the code shown in Listing 4.

Listing 4. Grid client example

// Connect to the Catalog Server. The security and client override XML are not specifiedClientClusterContext ccc = ObjectGridManagerFactory.getObjectGridManager()

.connect(localhost, null, null);




9/11

// Retrieve the ObjectGrid client connection and return it.ObjectGrid grid = ObjectGridManagerFactory.getObjectGridManager()

.getObjectGrid(ccc, Grid);

Based on the standard WebSphere eXtreme Scale development pattern, you firstget a context object from the catalog service (here deployed on localhost, whichshould be changed or parameterized for a remote catalog service). Then, you get areference to the grid, which is subsequently provided to theAsyncServiceManagerImpl object above to send the asynchronous messages.

The runclient.sh script can also be used to run the sample against a remote grid byproviding the hostname and port to the processing unit grid's catalog service as asingle parameter. For example, execute the command runclient.shlocalhost:2809 to run the client against a grid deployed on the local machine.

Runtime

The purpose here was to maximize scalability and reliability. From a scalabilityperspective, you only need to start additional JVMs to participate in the grid, whichwill automatically start servicing asynchronous messaging requests. More capacity isas simple as starting a new JVM with the same command line above, save for a newunique server ID, easily providing additional processing resources.

Reliability is already handled within the grid. As configured, each message isreplicated once in another grid JVM and will be processed there if a primary partitiongoes down. As with any typical WebSphere eXtreme Scale grid instance, thereplication behavior is configurable in the deployment XML. In the sample as

packaged, the grid is configured to synchronously perform a single replication of themessage if another container is available. This service is an assured deliver-oncemechanism with reliability only limited by the number of JVMs available to which toreplicate.

An important detail to mention is that "deliver once" is within the context of yourmessage listener implementation. The asynchronous service framework will deliverand commit the message in the grid ONLY once, however because of failurewindows it is possible that the actual logic in the listener might be executed morethan once. This means that if the listener logic changes any state in an external datasource (database, mainframe, and so on) then these interactions must be treated

with an "at least once" delivery paradigm. To be clear, the onMessage method willbe processed in its entirety only once, but it might be attempted multiple times and,as such, portions of the method might be executed multiple times. For example, if acontainer JVM fails while processing a message, the onMessage method will beexecuted again on the new primary partition once it is promoted. Any code thatmight have had an effect on outside resources must be aware of this possibility.




10/11

Transactional considerations

This framework, as well as WebSphere eXtreme Scale on which it is based, doesnot formally participate in JTA transactions (WebSphere eXtreme Scale has its own

transaction manager). However, the standard "nesting" technique can be used tomake the processing of a message a logical part of a JTA transaction. That is, yourlistener (MessageProcessor) can be written to perform the following logic in thisorder, insuring that each step has succeeded prior to beginning the next:

1. Begin a JTA transaction.

2. Process a message.

3. Mark the message as processed (or delete it from the queue).

4. Commit the JTA transaction.

If any step fails (for example, you fail to successfully mark the message asprocessed), you can rollback the JTA transaction and that message can be validlyprocessed again. The above logic makes the act of processing a message a logicalparticipant in the JTA transaction.

Conclusion

This article illustrated the WebSphere eXtreme Scale asynchronous service

framework that is available as a sample for deployment in your environment. Theexample shown here demonstrated this new capability of WebSphere eXtremeScale servers to help solve some of the more troubling and challenging growthissues in an ever-changing transaction processing environment. Asynchronousarchetypes and the scalable environments they create will be essential in manyevolving systems.

The ansynchronous service framework is available as a sample in the WebSphereeXtreme Scale samples gallery. This repository of patterns and examples is one ofour most valuable channels of communication to help users get the most from thesenew technologies.




11/11

Resources

Learn

WebSphere eXtreme Scale product information

WebSphere eXtreme Scale Information Center

WebSphere eXtreme Scale documentation library

Redbook: User's Guide to WebSphere eXtreme Scale.

IBM developerWorks WebSphere

Billy Newport's XTP blog

WebSphere Extreme Scale YouTube channel

Get products and technologies

Download the Asynchronous Service Framework from the WebSphere eXtremeScale Samples Gallery

Download IBM WebSphere eXtreme Scale trial version

WebSphere eXtreme Scale Amazon EC2 Images (AMIs) (Development andProduction).

Discuss

Engage with the development community as well as the eXtreme Scale productteam! Get your questions answered at the WebSphere XD forum

About the author

Robert Wisniewski

Robert Wisniewski is a Software Engineer specializing in performance andscalability. He has previously worked on WebSphere Applications Serverperformance for 7 years focusing on all areas of the product from EJB/JPA toautonomic computing and benchmark design. His current position as TechnicalEvangelist refocuses this experience on customer scenarios and the application of

XTP strategies in the real world.


http://www-01.ibm.com/software/webservers/appserv/extremescalehttp://publib.boulder.ibm.com/infocenter/wxsinfo/v7r0/index.jsphttp://www-01.ibm.com/software/webservers/appserv/extremescale/library/index.htmlhttp://www.redbooks.ibm.com/abstracts/sg247683.html?Open&open&cm_mmc=4443-_-n-_-vrm_newsletter-_-10300_100294&cmibm_em=dm:0:13397061http://www.ibm.com/developerworks/websphere/http://bit.ly/gwcBillyBloghttp://bit.ly/gwcXTPYouTubehttp://www.ibm.com/developerworks/wikis/display/extremescale/Asynchronous+Service+Framework+samplehttp://www.ibm.com/developerworks/wikis/display/extremescale/Samples+Galleryhttp://www.ibm.com/developerworks/wikis/display/extremescale/Samples+Galleryhttp://www.ibm.com/developerworks/downloads/ws/wsdg/learn.htmlhttp://www.ibm.com/developerworks/downloads/ws/wsdg/ec2.htmlhttp://www.ibm.com/developerworks/downloads/ws/wsdg/ec2.htmlhttp://www.ibm.com/developerworks/blogs/http://www.ibm.com/legal/copytrade.shtmlhttp://www.ibm.com/legal/copytrade.shtmlhttp://www.ibm.com/developerworks/blogs/http://www.ibm.com/developerworks/downloads/ws/wsdg/ec2.htmlhttp://www.ibm.com/developerworks/downloads/ws/wsdg/ec2.htmlhttp://www.ibm.com/developerworks/downloads/ws/wsdg/learn.htmlhttp://www.ibm.com/developerworks/wikis/display/extremescale/Samples+Galleryhttp://www.ibm.com/developerworks/wikis/display/extremescale/Samples+Galleryhttp://www.ibm.com/developerworks/wikis/display/extremescale/Asynchronous+Service+Framework+samplehttp://bit.ly/gwcXTPYouTubehttp://bit.ly/gwcBillyBloghttp://www.ibm.com/developerworks/websphere/http://www.redbooks.ibm.com/abstracts/sg247683.html?Open&open&cm_mmc=4443-_-n-_-vrm_newsletter-_-10300_100294&cmibm_em=dm:0:13397061http://www-01.ibm.com/software/webservers/appserv/extremescale/library/index.htmlhttp://publib.boulder.ibm.com/infocenter/wxsinfo/v7r0/index.jsphttp://www-01.ibm.com/software/webservers/appserv/extremescale

fast and scalable asynchronous processing with websphere extreme scale

Documents