November 07, 2003
Async Beans Introduction
Async Beans is a feature in WebSphere 5.0 Enterprise. It allows J2EE applications to take advantage of threading (short lived aka pooled threads and long lived aka daemon threads). I'm just going to discuss how to use the threading in applications today.
It all centers around the com.ibm.websphere.asynchbeans.WorkManager interface. A web app or EJB can declare a resource-ref to one or more of these. These are bound to a physical WorkManager at deploy time. The administrator can create one or more WorkManagers. Each one is basically a thread pool. An application can be deployed to use multiple thread pools or a single one, it's just like a resource-ref to a DataSource.
The application component looks it up in its JNDI using the name corresponding to the resource-ref. This can be done many times but the same WorkManager is returned each time. If two application are bound to the same physical WorkManager then they share the WorkManager.
The main methods on WorkManager are startWork and join. The main interfaces to know about are Work, WorkItem and WorkManager. Work is simply a Runnable with an additional release method. So, make an instance of an inner class or a JavaBeans that implements the Work interface and then pass it to a WorkManager.startWork. You will be returned a WorkItem. These can be put in an array list and then provided to the WorkManager.join method. The join method allows the caller to block waiting for 1 or all Work's to complete. A timeout can also be specified.
The javadocs are here
When the Works are dispatched on a thread then the JNDI context from the component that called startWork is used. The Work cannot make global transactions but it can safely invoke an EJB that it looks up through an ejb-local-ref or ejb-ref and then use it to do any transactional stuff. If security is on then the credential from the caller of startWork is also present on the dispatching thread so the Work is running as the same identity as the caller of startWork.
Some variations of the startWork method take a WorkListener instance which allows events to be fired back as the Work is executed or when it finishes. Some also take a boolean 'isDaemon' which if true means that it's a daemon thread. In this case, I don't allocate it from a pool, instead I just spin up a thread for it.
The release method is there so that when the application is stopped, I iterate over the daemon threads and call this to give them a hint that they should stop.
There really isn't much to using it. I have another blog entry on this site showing how to use JMX to tune the thread pools associated with a WorkManager while it's running.
Once you get the hang of it then you can build pretty advanced J2EE applications. The commonest things I see are dynamic messaging, advanced threading models for processing messages and people using them to do tasks in parallel like database queries and calculations.
Startup beans are basically SLSBs which use a specific remote and remote home interface. If WebSphere sees one of these in an ejb module then when the module is started, we invoke the start method. The start method can be used to spawn threads or warm CMP caches etc. If the application stops normally then the stop method is called. There can be more than one startup bean in an application and they can be ordered with respect to each other.
I'll try to get permission to publish a messaging application which demonstrates how to do some useful things using async beans and JMS or Tibco.
You need to provide a PINTER FRIENDLY link
Posted by: Robert Fletcher | Nov 14, 2003 8:04:39 AM
Nice overview, Billy - thanks for taking the time to explain these new EE features. :-)
Posted by: Simon Brown | Nov 14, 2003 2:48:29 PM
in your previous blog entry "When MDBs aren't enough" you state that we cannot create threads at the servlet level because the j2ee spec says we cannot rely on that being supported. however, in this blog entry, you mention a websphere specific method for threading (even though it is not a j2ee standard, and thus support by other j2ee containers cannot be relied up.) so, we should not create threads in servlets, but it is okay to let vendor lockin api's create them?
Posted by: javajim | Nov 17, 2003 9:50:24 AM
Thats right, until the spec catches up, this is the only acceptable way to make threads, using vendor specific APIs that do what ever is necessary to make them supportable and managed.
Posted by: Billy | Nov 17, 2003 12:12:49 PM
I have built an application with a startup session bean. But when I started the application, thestart method was not called. Is there any other requirement to use it? Thanks a lot.
Posted by: Jack | Dec 6, 2003 12:09:02 AM
Can you please tell me what .jar file these asynchBeans reside in?
Posted by: Erich | Jan 9, 2004 4:48:10 PM
It looks like Async Beans -- or at least WorkManager -- is going to be in WAS6. And it's encouraging that IBM is collaborating with BEA on this so it might make it into the J2EE spec. But since WAS6 probably won't hit GA for quite some time, do you think that WorkManager will be made available to us poor WAS-ND users?
Posted by: Jim Cakalic | Jan 22, 2004 2:59:56 PM
6.0 will have the commonj stuff inside it. I don't know of any plans for moving it back to 5.x although I can't say anything about stuff which is not officially announced by IBM means anything.
Posted by: Billy | Jan 22, 2004 3:15:25 PM
The jar is asynchbeans.jar in appserver/lib
Posted by: Billy | Jan 22, 2004 3:15:55 PM
I do not find the asynchbeans.jar. Where can I get it from?
Posted by: Someone | Jun 16, 2004 6:13:07 AM
I am in the process of architecting an enterprise application which, in a nutshell, recieves large volumes of messages intermittently during the day from a series of sources via MQ. These messages are transformed, written to a database. The latter triggers the resultant transformations to be distributed to remote sites for purposes of querying at the remote site.
This solution in its current form (this is currently deployed and functional) is handling relatively small volumes as compared with the future requirements and is built using a set of C daemons reading from a message queue using the MQ Series API. The daemons are the message consumers and are the equivalent of the MDB with the exception that the current implementation manages its own transactions. I am having a religious debate here in that I am being challenged by the team with regards to the amount of additional complexity that would be introduced by bringing in a solution that leverages MDBs under WAS 5.1. My arguement is the following:
1. Scalability with MDBs is achieved easily by the addition of nodes / clones, controlling the pool sizes of the MDBs, configuration settings such as max listener sessions etc.. This would be in addition to MQ clusters. Can 2 MDBs belonging to 2 diferent nodes be consuming messages from the same logical queue manager within a cluser? My gut says "yes".
In the case of the current solution, this would have to be controlled by spawning of additional daemons bound to additional message queueus.
What is the overhead as far as performance goes introduced by the EJB container within WebSphere?
2. Manageability of the overall solution is much higher. Standard WAS plug-ins make the manageability of the MDBs a lot simpler as compared to the home-grown daemon version.
3. Delegation of distribution responsibilities, transaction management responsibilities, asynchronous message consumption responsibility to the container simplifies the programming model.
My questions are as follows:
Given that we have performance, reliability and availability as key NFRs that need to be satisfied by the solution, should I rethink the architecture vis-a-vis the use of WAS? I have some dated (2003) benchmarks run on the Windows 2000 environment from IBM that prove that a non-MDB solution is less efficient. I'm not sure that I would go by this, given that my current platform is Linux and WebSphere. Your inputs on this matter would be "muchas" appreciated.
Posted by: VP | Mar 24, 2005 12:41:58 AM
could you please tell me,what is the alternatives for wait and notify() in ibms asynch bean...
Posted by: srimukha reddy | Nov 2, 2006 1:07:45 AM
I am using RAD6 and we don't have the asyncbeans under the 5.1 lib but do under the 6. I have tried looking on the advanced edition 5.1 install and it doesn't appear to be there either. Is there a patch that we can install and is it supported in 5.1?
Posted by: John McRobb | Jan 23, 2007 8:29:09 AM