Web Design and Applications

Transcription

1 Web Design and Applications JEE, Message-Driven Beans Gheorghe Aurel Pacurar

2 JEE, Message-Driven Beans

3 Java Message Service - JMS Server JMS is a standard Java API that allows applications to create, send, receive, and read messages asynchronously. The package is named javax.jms JMS defines a common set of interfaces and classes that allows programs to communicate with other message providers. JMS is analogous to JDBC: the latter connects to several databases (Derby, MySQL, Oracle, DB2, etc.), and JMS connects to several providers (OpenMQ, MQSeries, SonicMQ, etc.). The JMS API covers all the required functionality for messaging, that is, sending and receiving a message through destinations. JMS API provides: Message producers: JMS provides the API for clients to generate the message (a.k.a. senders and publishers). Message consumers: The API allows clients applications to consume messages (a.k.a. receivers or subscribers). Messages: a message consists of a: 1. Header 2. Properties 3. A body that contains different information (text, objects, etc.). Connections and destinations: The API has several factories where connections to providers can be obtained, as well as destinations (queues and topics)

4 JMS Architecture - Java implementation

5 Queues and topics There are two different types of destination, each applying to a specific architectural model: The point-to-point (P2P) model: In this model, the destination used to hold messages is called a queue. When using point-topoint messaging, one client puts a message on a queue, and another client receives the message. Once the message acknowledged, the message provider removes the message from the queue. The publish-subscribe (pub-sub) model: The destination is called a topic. When using publish/subscribe messaging, a client publishes a message to a topic, and all subscribers to that topic receive the message. The JMS specification provides a unified set of interfaces that can be used with both P2P and pub-sub messaging.

6 P2P model details In the P2P model, a single message travels from a single producer (point A) to a single consumer (point B). The model is built around the concept of message queues, senders, and receivers. A queue retains the messages sent by the sender until they are consumed, and a sender and a receiver do not have timing dependencies. This means that the sender can produce messages and send them in the queue whenever he likes, and a receiver can consume them whenever he likes. Once the receiver is created, it will get all the messages that were sent to the queue, even those sent before its creation. Each message is sent to a specific queue, and the receiver extracts the messages from the queue. Queues retain all messages sent until they are consumed or until they expire. The P2P model is used if there is only one receiver for each message. Note that a queue can have multiple consumers, but once a receiver consumes a message from the queue, it is taken out of the queue, and no other consumer can receive it. In Figure 13-4, you can see one sender producing three messages. Two receivers consume a message that will not be available to the other. JMS also ensures that a message is delivered only once. Note that P2P doesn t guarantee messages are delivered in any particular order, and if more than one receiver exists for a message, a receiver is chosen randomly.

7 Publish Subscriber model In the pub-sub model, a single message is sent by a single producer to potentially several consumers. The model is built around the concept of topics, publishers, and subscribers. Consumers are called subscribers because they first need to subscribe to a topic. The provider manages the subscribing/unsubscribing mechanism as it occurs dynamically. The topic retains messages until they are distributed to all subscribers. Unlike the P2P model, there is a timing dependency between publishers and subscribers; subscribers do not receive messages sent prior to their subscription, and if the subscriber is inactive for a specified period, it will not receive past messages when it becomes active again. Note that this can be avoided, because the JMS API supports the concept of a durable subscriber, as you ll later see. Multiple subscribers can consume the same message. The pub-sub model can be used for broadcast-type applications, in which a single message is delivered to several consumers.

8 What is a message-driven bean? A message-driven bean is an enterprise bean that allows J2EE applications to process messages asynchronously. It acts as a JMS message listener, which is similar to an event listener except that it receives messages instead of events. The messages may be sent by any J2EE component--an application client, another enterprise bean, or a Web component--or by a JMS application or system that does not use J2EE technology. Message-driven beans currently process only JMS messages, but in the future they may be used to process other kinds of messages.

9 Message-driven beans versus session beans MDBs are asynchronous message consumers that are executed inside an EJB container. The container takes care of several services (transactions, security, concurrency, message acknowledgement, etc.), while the MDB focuses on consuming JMS messages. MDBs are stateless, meaning that the EJB container can have numerous instances, executing concurrently, to process messages coming in from various JMS producers. Even if they look like stateless beans, client applications cannot access MDBs directly; the only way to communicate with an MDB is to send a message to the destination that the MDB is listening to. In general, MDBs listen to a destination (queue or topic) and when a message arrives, they consume and process it. MDBs can also delegate business logic to other stateless session beans in a safe, transactional manner. Because they are stateless, MDBs do not maintain state across separate invocations from one message received to the next. MDBs respond to JMS messages received from the container, whereas stateless session beans respond to client requests through an appropriate interface (local, remote, or no-interface).

10 Message-driven bean versus session beans. Clients do not access message-driven beans through interfaces. Unlike a session bean, a message-driven bean has only a bean class. A message-driven bean's instances retain no data or conversational state for a specific client. The instance variables of the message-driven bean instance can contain some state across the handling of client messages--for example, a JMS API connection, an open database connection, or an object reference to an enterprise bean object. All instances of a message-driven bean are equivalent, allowing the EJB container to assign a message to any message-driven bean instance. The container can pool these instances to allow streams of messages to be processed concurrently. A single message-driven bean can process messages from multiple clients. A message may be delivered to a message-driven bean within a transaction context, so that all operations within the onmessage method are part of a single transaction. If message processing is rolled back, the message will be redelivered. When a message arrives: 1. The container calls the message-driven bean's onmessage method to process the message. 2. The onmessage method normally casts the message to one of the five JMS message types and handles it in accordance with the application's business logic. 3. The onmessage method : 1. may call helper methods, or 2. it may invoke a session or entity bean to process the information in the message or to store it in a database.

11 When to use a message-driven bean? Session beans and entity beans allow you to send JMS messages and to receive them synchronously, but not asynchronously. To avoid tying up server resources, you may prefer not to use blocking synchronous receives in a server-side component. To receive messages asynchronously, use a message-driven bean.

12 MDB development requirements The requirements to develop an MDB class are as follows: 1.The class must be annotated or its XML equivalent in a deployment descriptor. 2.The class must implement, directly or indirectly, the MessageListener interface. 3.The class must be defined as public, and must not be final or abstract. 4.The class must have a public no-arg constructor that the container will use to create instances of the MDB. 5.The class must not define the finalize() method.

13 JEE recommended links

14 Thank you! Any suggestion, comment and critics are more than welcome: