Java Messaging System

[TechGate]

Java Messaging System

Introduction :
JMS API is asynchronous communication via message of Java. This API allows an application to invoke the services of a MOM. JMS is part of JEE 5 and is thus available to applications running on Java application servers. The first version of JMS, JMS 1.0.2b was released 25 June 2001. The second version, JMS 1.1 was out in March 18, 2007, showing no significant difference. JMS 1.1 classes allow JMS clients to achieve more easily. We will look briefly JMS 1.1. But we will start by asking a few definitions and concepts. Like any specification, JMS must ensure that all applications that comply with the same behavior regardless of the provider implementation. The JMS also leaves well-defined cases, freedom for suppliers to implement or not certain features. We talk more about these features that distinguish the different Moms. As for JDBC access to databases or JCR to access a content repository, JMS allows in theory to develop an application interfaced to a MOM, not dependent on a particular product. That is to say it should be possible to replace a JMS MOM another transparently to the application. As for access to databases, this aspect is not always interchangeable verified in practice. There may be small differences in implementation of the specification, and also the various tools MOMS strive to offer small "plus", differentiating features.

[TechGate]

Modes of Communication :
The JMS specification introduces two modes of communication, " JMS domains ": the topics on the one hand, the tails of the other..

The point to point or "tail" :
This mode of communication is also called communication via tail. An application sends messages to a queue. One connected applications receiving the message. There may be several applications read on the tail, but one of them will receive the message.

Mode " publish-subscribe " or " Topic " :
This mode of communication is also called communication via topic. An application sends messages to the topic. In this mode, it says that applications subscribing (subscribe) to a topic, to receive messages applications can be subscribed to the same topic, and each receives a copy of messages. In the manner of distribution of a magazine for example, the issuer publishes a message, and the various recipients subscribe to receive a copy of the message. Thus an exchange of 1 to N, but can be both "P to N, because several applications may write to the topic.

Queues and Topics :
You can see the differences in usage of these two modes. In the mode line, one can imagine that a message represents a processing unit. The destination application receives the message and performs processing from the message, and in this case it is necessary that the treatment is not executed twice. In the fashion topic, you can see the message more as a unit of information that may interest different players, different applications. For example, a stock market order will be a processing unit, while a stock price will be information. Queue and Topic are grouped under the name " Domain ". Thus, "send a message to a field equivalent to "send a message to a queue or a topic".

[TechGate]

Some definitions :
JMS introduces different terms and concepts that we will quickly go:

JMS Client -
A JMS client application is written in Java, and sending or receiving messages via the JMS API.

Non-JMS Client -
A non-JMS client application is sending and / or receive messages by communicating with the JMS provider under its special protocol, either directly or through an API function. This application is not written in Java.

JMS Provider -
A JMS provider is an implementation of JMS services written in Java. Thus, i the MOMS study later we are JMS Providers.

JMS Consumer -
A JMS Consumer is an application that receives and processes JMS messages.

JMS Producer -
A JMS Producer is an application that creates and sends JMS messages. An application can be both JMS Producer and Consumer.

JMS Message -
The JMS message is the basic unit of JMS. It is sent and received by the JMS client.

JMS Domains -
Both JMS areas correspond to the two modes of communication already mentioned: point to point with tails or with the publish-subscribe topics.

Destination -
Objects destinations are objects used to identify the target messages to send or receive, that is to say areas, queues and topics.


Encoding of message bodies :
Even if the content and format of the body are basically the case of applications using JMS applications to handle certain types of objects providing different types of message body.

The body of a message can be encoded by 5 " Message Types "available:
- "TextMessage": The body contains characters.
- "BytesMessage": The body contains a sequence of bytes, depending on
Java
- "MapMessage": The body contains a map. A map is a type of
data linking a key (String encoded) has a value (coded
String, Double, or Long)
- "StreamMessage This type allows to concatenate several native type (string, Double or Long).
- "ObjectMessage": This type allows to transfer java objects.


The JMS message -
The message handled by the JMS MOM consists of the following:
- A heading, which has the same structure for all messages, and contains mainly the fields necessary for the identification and routing of the message.
- The properties, which have in some way complement the header, with specific attributes, is defined by the MOM in addition to the minimum header JMS is defined by the application to their specific needs.
- The body of the message, which may have different formats: text, Java objects or XML.

The main fields of the header are:
- JMSMessageID : unique identifier of the message
- JMSDestination : identification of the queue or topic destination of the message
- JMSCorrelationID : used to synchronize two messages so application form request / response. In this case, the response message, this field contains the MessageID of the message request

According to the usual image, the header corresponds to what is written on the envelope, the body corresponds to what is in the envelope. The MOM and does not read the header data, including properties. Thus, the selection of messages, as we shall see later, may depend on these properties, but not the body of the message.


Order messages :
The MOM provides a message on a queue will be delivered at most once, but it does not guarantee that messages will be delivered in the order in which they were issued. In fact, there is almost a theoretical impossibility to guarantee one or the other of these two properties: the single handed, and ordered the surrender. Indeed, a consumer can read a message, and do not pay until long after. If the consumer does not, the message must be recycled. So to ensure the orderly delivery, the MOM should wait until all the up to N messages have been received not only, but acquitted, before delivering a message N +1, which would have a catastrophic effect on performance. We will see later that the MOMS allow transaction management, allowing somehow to undo operations that have not yet been validated, committees, ordering Rewind, a rollback. See "Transaction Management". The following figure shows how a rollback, either express or implied, that is to say, caused by the closing session, forced to recycle a message when the following have already been issued.

Lifetime of a message :
The sending application can specify the lifetime of the message. The message is 'valid' till the expiry of this period, beyond the MOM can destroy it without having given. Most MOMS choose instead to refer to the Dead Message Queue, which will keep track of the event, and recycle the message if necessary. Note that if one is in the context of a transaction, the lifetime starts when even the emission time, and not at the moment of commit.

Priority :
An optional feature, but useful, proposed by the JMS, is the management of priorities, that is to say that the delivery of messages is done according to priority. A message of higher priority can "doubling" a message of lower priority, provided that it has not yet been read. Note that JMS 1.1 does not require suppliers to implement this functionality.


Summary JMS :
JMS is an API and the API corresponds to exchange services between producers and consumers of messages, based on concepts that we have presented. Beyond the API, therefore, JMS defines the features central MOMS. JMS specifies the service but does not specify how the service is implemented. Each provider, JMS provider, has freedom of choice of implementation. As noted above, the exchange protocols can also be regarded as implementation choice MOMS-specific, although we believe they have a real importance. The JMS specification does not in all respects complete. Some functions essential to the functioning of a platform MOM are not described in the specification and are therefore subject to specific implementations. This is particularly true for configuration and management of courier for the security (integrity and confidentiality of messages) and some parameters of service quality. Moreover, most MOMS offer additional features that are as specific strengths in relation to competing offers (eg topics hierarchical security functions and mechanisms for high availability, etc..). Of course, the implementation of these features comes at the expense of the ability to change the MOM, respecting the JMS API.