BlueStorm Technologies

1. Application Development Services BlueStorm Technologies Employee Technical Education Asynchronous Beans

2. Asynchronous Beans • Multi-threaded applications and JEE • Asynchronous Beans API • WorkManager • Events • AsynchScope • Alarms • SubsystemMonitor • Operational Classes • RSS Feeds Example

3. Benefits of Multi-threaded Programming • Parallel execution mitigates the effects of: • Slow or unreliable data sources • Connection speed • Query speed • Processor-intensive operations • Sorting, operations on lists, recursive functions, etc. • File and stream I/O • Multiple Processors and Multi-core processors • Multi-threaded applications can take greater advantage of the machine’s available resources • Single-threaded applications are resigned to using just one processor core for execution

4. No Spawning Threads in JEE • No containment • The JEE container has no handle on the thread • Exists outside the JEE container in the raw JVM • No execution context for the thread • No collection • The JEE container can not throttle or collect the thread when it needs resources elsewhere • No control • The JEE container has no ability to control a rogue thread if something were to go wrong

5. JEE Asynchronous Options • Stateless EJBs can execute code without stopping the main thread • JMS can request for background processes to be kicked off • But what if you want something that doesn’t • require an IDE to generate the required classes for simple operations? • require the installation of additional middleware? • force unnecessary XML translations? • provide more functionality than you need?

6. Asynchronous Beans to the Rescue! • JEE friendly method for asynchronous code execution • Has been around since WAS 5.0 • Simple to implement • Just like spawning a thread • Minor server configuration required • Spawned threads remember their context • Security • Internationalization • java:comp scope • The JEE container has control over the new threads • Can be used with POJO Java beans or EJBs

7. Asynchronous Beans API Components • WorkManager – Thread pool • Events – Custom listeners • AsynchScope – Hierarchical organization • Alarms – Timed alerts • SubsystemMonitor – Heartbeat subscribers • Operational Classes – Primary interfaces

8. WorkManager • A thread pool created by WebSphere Administrators • Can have context policies applied to them • Has a name bound in JNDI • Can be used directly to execute a thread • Allows asynchronous or synchronous threads

9. Events • Event framework, no prescribed classes • Allows implementation on custom classes • Event sources and listeners are linked through a proxy • The proxy can be found through JNDI

10. AsynchScope • A grouping or scoping mechanism for creating a hierarchy of containers under the WorkManager • AsynchScopes are children of a WorkManager or another AsynchScope • Used for Alarms and SubsystemMonitors

11. Alarms • Functions similarly to java.util.Timer • java.util.Timer should not be used • Operates within a single AsynchScope • Must determine the wait time and listener up-front • However the Alarm creator can modify, cancel, or reset the alarm • The listener is fired on a new thread that is managed by the JEE container • Caveat – Alarms are not persistent. Use the Scheduler if you need something to stick around.

12. SubsystemMonitor • Listens for heartbeat pings from another process to monitor its state • Missed heartbeats can indicate there is a problem with the monitored process • Other processes listen to the SubsystemMonitor for three states: • Stale • Dead • Alive • The missed heartbeat thresholds for each state are set on creation of the SubsystemMonitor

13. Operational Classes • Work (com.ibm.websphere.asynchbeans.Work interface) • Derived from java.lang.Runnable • Must implement two methods: • run() – called when the thread is spawned • release() – called when the thread is terminated • AlarmListener (.asynchbeans.AlarmListener interface) • Must implement the fired() method • Spawned as a thread when the alarm is fired • Should cancel or reset the alarm as appropriate • EventListener (any interface) • Allows you to spawn a thread based on a custom interface

14. RSS Feed Example • The RSS Feed portlet keeps a universal cache of transformed feed results in a singleton • The data expires on interval based on the individual portlet settings • Expiration does not mean the data is bad • When expired data is found, a thread is kicked off to find all the stale data and reprocess those feeds • Instead of making the user wait for the long turnaround in fetching and transforming a feed when it has expired, the stale feed is sent to the browser • Next time a user sees the RSS Feed portlet, the data is fresh and no one had to wait for the fetch and transform process

15. Final Notes • Use Asynchronous Beans with • Partitioned tasks to be run in parallel • AJAX for delayed page updating • Integrate third-party messaging solutions with JMS • Additional Options • CommonJ WorkManager API • Provide the same functionality with standardization • Now available in WAS 6 • Scheduler • For starting tasks at specified times and intervals

16. BlueStorm Technologies, Inc. • 20-24 Wall Street • Binghamton, NY 13901 • http://www.bluestormtech.com • Contact: • Robert D. Matson • rmatson@bluestormtech.com • 607-762-5401