SCEA之路--8. Messaging

General.
Synchronous communication.
Synchronous communication represents a tight coupling between a sender and receiver :
• the sender and receiver must both be available – i.e. real-time communication
• the sender will block until the response is available
• communication is one-to-one
• sender / receiver have some knowledge of each other – e.g. location, protocol, methods, etc.
• the sender is responsible for dealing with failures - e.g. retries, etc. “request/response” is an example of a synchronous communication paradigm.
Example : a browser sends a request to a web server and “waits” for the response. The “wait” can be indefinite or until a timeout occurs.
Asynchronous communication.
Asynchronous communication represents a loose coupling between senders / receivers :
• sender and receiver communicate via a midde-man / broker / mediator
• no requirement for sender or receiver to both be available – i.e. deferred communication
• sender doesn’t wait for a response (if any)
• communication can be one-to-one or one-to-many
• sender and receiver have no direct knowledge of each other so promotes reuse / extension – e.g. new senders / receivers can be added without impact; senders / receivers can be replaced as required
• the broker is responsible for dealing with failures – e.g. retries, etc.
• messages may be delayed and/or arrive out of sequence

JMS.
JMS (Java Message Service) is an API from Sun which allows generic access to MOM services – in a similar way that JDBC allows generic access to databases.
Concepts.
• Provider – vendor implementation of the JMS API
• Messaging domains – two types of domain, Point To Point (PTP) or publisher/subscriber
• Message consumption – two types of consumption, synchronous and asynchronous (see below).
• Administered objects – JMS bootstrap objects (e.g. connection factories, destinations) bound in the JNDI namespace by an administrator
• ConnectionFactory – Queue/TopicConnectionFactory, used to create a connection to the Provider
• Destination – Queue/Topic, target of message production/consumption
• Connection – Queue/TopicConnection, encapsulates connection to the Provider; start () indicates that message delivery should begin
• Session – Queue/TopicSession, used to create producers, consumers and message; also provides a context for transactions
• MessageProducer – QueueSender/TopicPublisher
• MessageConsumer – QueueReceiver/TopicSubscriber; consume messages synchronously using the receive () methods or asynchronously by passing a MessageListener to setMessageListener ()
• Message – object produced or consumed; composed of header, properties and body. Body types are : text, name/value pairs, bytes, stream of primitives, serialized object or none.

PTP messaging.
• based on Queues, Senders and Receivers
• Senders and Receivers address the Queue by name
• one or more Senders but only one Receiver
• messages stay in the Queue until consumed or past expiry time
• receiver acknowledges successful processing of a message

Publisher / subscriber.
• based on Topics, Publishers and Subscribers
• Publishers and Subscribers address the Topic by name
• one or more Publishers publish to the Topic subscribed to by one or more Subscribers
• messages only stay in the Topic for as long as it takes to send them to the active Subscribers
• a subscriber can only consume “active” messages – i.e. those published since the subscriber became active (unless durable subscriptions are in use)

List Benefits of Synchronous and Asynchronous Messaging
The benefits of synchronous messaging follow:
• Because both parties must be active to participate in synchronous messaging, if either party is not active, the message transaction cannot be completed.
• A message must be acknowledged before proceeding to the next message. If it is not acknowledged, the message cannot be considered processed.

The benefits of asynchronous messaging are as follows:
• As the volume of traffic increases, asynchronous messaging is better able to handle the spike in demand by keeping a backlog of requests in its queue and then operating at maximum capacity over a period of time instead of needing to service the requests instantaneously.
• Asynchronous messaging is less affected by failures at the hardware, software, and network levels.
• When capacities are exceeded, information is not lost; instead, it is delayed.

Identify Scenarios That Are Appropriate to Implementation Using Messaging
• Scenarios appropriate to implementation using message include asynchronous communication, one-to-many communication, guaranteed messaging, and transactional messaging.

Identify Scenarios That Are More Appropriate to Implementation Using Asynchronous Messaging, Rather Than Synchronous
• You need to implement a messaging system in which a response is not required or not immediately required.
• You need a high-volume transaction processing capability for sending messages.
• You want a messaging system that uses your system hardware in an efficient manner.

Identify Scenarios that Are More Appropriate to Implementation Using Synchronous Messaging, Rather Than Asynchronous
• One scenario more appropriate to synchronous messaging includes that in which a response to the message is required before continuing, for example, for transactions requiring credit card or user login authentication.
• A second scenario includes a transaction where both parties must be active participants.

Identify Scenarios That Are Appropriate to Implementation Using Messaging, Enterprise JavaBeans Technology, or Both
• The scenarios appropriate for messaging technology include broadcasting stock prices to traders, instant messages, and in situations when integration of incompatible systems is necessary.
• The scenarios appropriate for EJB technology include those that perform business logic and those that maintain persistent data.
• The scenarios appropriate for messaging and EJB technology including those that require maintenance of distributed transactions and those that send an order to another system.