WAS v8.5 > Develop applications > Develop Messaging resources

Programming to use asynchronous messaging

We can build enterprise applications that use JMS APIs directly to provide asynchronous messaging services. We can also use message-driven beans as asynchronous message consumers. If we are writing messaging programs that interoperate between WebSphere Application Server and WebSphere MQ, there are some environmental differences needed to take into account. Enterprise applications can use JMS APIs directly to explicitly poll for messages on a JMS destination, then retrieve messages for processing by business logic beans (enterprise beans).

Message-driven beans can also be used as asynchronous message consumers. When a message arrives at the destination, the EJB container invokes the message-driven bean automatically without an application having to explicitly poll the destination.

• Programming to use JMS and messaging directly.

  Your enterprise applications can use JMS programming interfaces directly to provide messaging services, and methods that implement business logic.

  If we choose not to use JNDI to obtain configuration information for the messaging provider, for example for connection factories or destinations, we can instead use an API provided by your messaging provider to specify that configuration information programmatically.

• Programming for interoperation with WebSphere MQ
  

  There are some differences between the WAS environment and the WebSphere MQ environment. If we are writing messaging programs that interoperate between these two environments, you should be aware of these differences and take them into account when designing, coding and deploying your programs.

• Programming to use message-driven beans.

  Applications can use message-driven beans as asynchronous message consumers. You deploy a message-driven bean as a message listener for a destination. When a message arrives at the destination, the EJB container invokes the message-driven bean automatically without an application having to explicitly poll the destination.

Asynchronous beans - WebSphere Trader sample application

The Asynchronous beans - WebSphere Trader sample application illustrates how to implement a streaming stock ticker server and client using asynchronous beans and Java EE services such as:

• Servlets
• JMS
• Session enterprise beans
• Container-managed persistence (CMP) 2.0 enterprise beans
• Message-driven beans (MDB)

This sample uses several parts to maximize the utilization of a server:

• Work - Runs Java EE context-aware code on a thread.
• Alarm - Runs Java EE context-aware code at a given time interval.
• EventSource - A method of broadcasting events to registered listeners.
• SubsystemMonitor - A thread that monitors the status of any asynchronous system and uses an EventSource method to inform registered listeners of the system status.
• WorkManager - Thread configuration and Java EE context policies used by various asynchronous beans parts.
• AsynchScope - A collection of alarms, subsystem monitors and other asynchronous scopes that support relationships. This collection uses a single WorkManager thread and is also an event source.
• Startup Bean - A specialized, stateful session enterprise bean that supports bootstrapping asynchronous work when the application starts.

This sample is available from the Samples section of the information center.

Subtopics

• Programming to use JMS and messaging directly
  Your enterprise applications can use JMS programming interfaces directly to provide messaging services, and methods that implement business logic.
• Programming for interoperation with WebSphere MQ
  There are some differences between the WAS environment and the WebSphere MQ environment. If we are writing messaging programs that interoperate between these two environments, you should be aware of these differences and take them into account when designing, coding and deploying your programs.
• Programming to use message-driven beans
  Applications can use message-driven beans as asynchronous message consumers. You deploy a message-driven bean as a message listener for a destination. When a message arrives at the destination, the EJB container invokes the message-driven bean automatically without an application having to explicitly poll the destination.

Related

Samples documentation
Run Java thin client applications
Use JMS from stand-alone clients to interoperate with service integration resources

Reference:

Additional Application Programming Interfaces (APIs)

+

Search Tips   |   Advanced Search