JMS/ Asynchronous Messaging

■Fundamental idea
□provide a communication abstraction that decouples collabrating distributed entities
-time decoupling --> asynchrony
-space decoupling --> anonymity
□asynchrony --> persistence of messages

■Message-Oriented Middleware
□a message-oriented middleware (MON) is a software layer acting as a kind of "middle man" between distributed entities
□most software companies offer middleware products that fall in the MOM category,
 e.g., IBM MQ Series, Oracle AQ, Sun Java System Message Queue, Microsoft Message Queueing, etc..

■Broker & Client Library
a MOMO is often based on a message broker and a client library.

■Communication models
□Point-to-point model
One-to-one communication between message producers and consumers, where each messages is consumed by one and only one consumer
□Publish/Subscribe (pub/sub) model
One-to-many communication where producers publish messages and all consumers that have subscribed receive them
□in both models, the notion of message is key

□Each message is received by only one consumer
□Messages are placed in a queue and are persisted until they are consumed
□This model can be used to load-balance tasks cavert:
 fifo processing cannot be guaranteed

□Each message is received by all subscribers
□Messages are not persisted by default
□There exists various message routing variant:

■J2EE Overview
□J2EE stands for Java 2 platform, Enterprise Edition
□J2EE is the specification of a distributed multitiered application model for enterprise applications, presented as a coherent set of programming APIs
□Implementations of the J2EE specification are usually proposed in the form of application servers

■Java Messaging Service
□the java messaging service (JMS) defines the asynchronous messaging standard of the J2EE platform
JMS follows the general J2EE philosophy:
 -JMS is a specification
 -JMS implementations rely on existing products (IBM MQ Series, Oracle AQ, Sun Java System Message Queue, etc.)
 -JMS-based applications are prtable across any JMS-compliant implementation

[producer JMS API ] <-> message broker <-> [consumer JMS API]
□a producer creates messages & sends them via the JMS API, specifying a message destination
□a consumer receives messages via the JMS API, specifying a message destination and an optional message selector
□a JMS-compliant product provides an implementation of the JMS API in the form of a client library that knows how to communicate natively with the message broker

■Deployment time
□start the message broker (usually via the J2EE application server)
□create the adaquate destinations
□install the Jms client library on the producer & the producer, and start them

■Unified programming model
Two communication models:
 -point-to-point (destination = queue)
 -publish/subscribe (destination = topic)

■Development: publisher
■Development: subscriver
■Development: producer
■Development: consumer
■Synchronous consumer

■Message format & types
□a JMS message is composed of three parts:
 -a header holding required fields for the client library and the message broker, e.g., priority, time-to-live, etc.
 -a list of optional properties, which act as meta-data used by the message selection mechanism.
 -a body containing the actual data of the message
□these exists various types of messages, which deffer in the type of data they carry in their body, e.g., Message, TextMessage, ObjectMessage, etc.

■Message selectors
□by default, JMS provides topic-based pub/sub
□thanks to message properties, JMS also support content-based pub/sub via message selectors
□a message selector is a string whose syntax is a subset of the SQL92 conditional expression syntax

■Quality of Service (QoS)
□parameterized Quality of Service (QoS) is usually offered by MOM products
□in JMS, the level QoS depends on the following parameters:
 -message ordering, time-to-lice & priorities
 -acknowledgement modes
 -durable subscriptions
 -delivery modes

■Order, priority & time-to-live
producer.send( aMessage, DeliveryMode.NON_PERSISTENT, 3/*priority*/, 5000/*time-to-live(in ms)*/);
□Jms specifies that messages are received in the order in which they were sent with respect to a given session and a given destination (commonly called FIFO order)
□JMS specifies no order across destinations or across sessions sending to the same destination
□the notion of priority allows programmers to have finer control over ordering, via the send() method
□programmers can also specify how long the message broker should keep a message, via a time-to-live parameter passed to the send() method

■Acknowledgement modes
□an acknowledgment informs the MOM (e.g., its underlying message broker) that the client has successfuly received a message
□JMS supports three acknowledgment modes:
   the session automatically acknowledges the receipt of each message
   the client acknowledges programmatically, invoking acknowledge() on each message
   more efficient variant of AUTO_ACKNOWLEDGE that can result is duplicate messages in case of faiures

■Delivery modes
□in JMS, there exists two delivery modes:
   most efficient but less reliable, since messages are guaranteed to be delivered at most once, i.e., some might be lost, e.g., due to some filure (power outage)
   most reliable, since messages are guaranteed to be delivered once and only once; this is usually achieved by persisting sent messages on stable storage and keeping them until they are acknowledged
□the delivery mode can be specifies at the producer level or each time a message is sent

■Durable subscriptions
□with pub./sub, messages are only received by subscrivers present at the time of the publication
□a durable subscriver is one that wants to receive all messages published on a topic, even those published when the subscriver is inactive, i.e., when it has no associated subscriver object
□in order to tell the message broker what messages latter must provide a unique name

□a transaction allows a group of messages to be managed as a single unit of work
□in JMS, transactions are managed by the session
□the decision to have a session trasacted must be taken at creation time:
  Session session = connection.createSession(true/*the transaction mode*/, Session.AUTO_ACKNOWLEDGE);
□as soon as messages are sent or received via a transacted session, the trasaction starts, i.e., sent/received messages are grouped as one unit of work.
□when method commit() or method rollbak() is called on the transacted session, the current transaction termnates and a new one is started
□transaction termination affects producers and consumers in the following manner:
 -Producer: that happens to messages sent during the transaction?
   - Commit all grouped messages are effectively sent
   - Rollback all grouped messages are desposed
 -Consumer: that happens to messages received during the transaction?
   - Commit all grouped messages are disposed
   - Rollback all grouped messages are recovered, i.e., they might be received again in the next transaction

Asynchronous Messaging (★★★☆☆)

tag : JMS

2009-05-10 15:13 : __j2ee__jms : コメント : 0 : トラックバック : 0 :

« next  ホーム  prev »




tag cloud

category cloud