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

■Point-to-Point
□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

■Publish/Subscribe
□Each message is received by all subscribers
□Messages are not persisted by default
□There exists various message routing variant:
 -topic-based
 -content-based
 -location-based

■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

■Executiontime
[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
 -transactions

■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:
 -AUTO_ACKNOWLEDGE
   the session automatically acknowledges the receipt of each message
 -CLIENT_ACKNOWLEDGE
   the client acknowledges programmatically, invoking acknowledge() on each message
 -DUPS_OK_AKNOWLEDGE
   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:
 -NON_PERSISTENT
   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)
 -PERSISTENT
   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

■transactions
□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


ref:
Asynchronous Messaging (★★★☆☆)
http://nsl.epfl.ch/teaching/middleware07/lectures2/jms.pdf

tag : JMS

2009-05-10 15:13 : __j2ee__jms : コメント : 0 : トラックバック : 0 :
コメントの投稿
非公開コメント

« next  ホーム  prev »

search

ad



counter


tag cloud

category cloud