JMS

Java Message System is for the software using asynchronous messaging.

JMS has two types

JMS Queue:
peer to peer
One provider, one consumer.

JMS Topic:
subscribe and publishing
One provider, multiple consumers.

JMS is typically used in the following scenarios
1. Enterprise Application Integration: - Where a legacy application is integrated with a new application via messaging.
2. B2B or Business to Business: - Businesses can interact with each other via messaging because JMS allows organizations to cooperate without tightly coupling their business systems.
3. Geographically dispersed units: - JMS can ensure safe exchange of data amongst the geographically dispersed units of an organization.
4. One to many applications: - The applications that need to push data in packet to huge number of clients in a one-to-many fashion are good candidates for the use JMS. Typical such applications are Auction Sites, Stock Quote Services etc.

JMS messages are composed of the following parts:

• Header - All messages support the same set of header fields.Header fields contain values used by both clients and providers to identify and route messages.
• Properties - Each message contains a built-in facility for supporting application-defined property values. Properties provide an efficient mechanism for supporting application-defined message filtering.
• Body - The JMS API defines several types of message body, which cover the majority of messaging styles currently in use.

There are different types of messages available in the JMS API.

• Message
• TextMessage
• BytesMessage
• StreamMessage
• ObjectMessage
• MapMessage

Message is a light weight message having only header and properties and no payload. If the receivers are to be notified about an event, and no data needs to be exchanged then using Message can be very efficient.

TextMessage contains instance of java.lang.String in the message body.This message type can be used to transport plain-text messages, and XML messages.

BytesMessage contains a stream of uninterpreted bytes. This message type is for literally encoding a body to match an existing message format. In many cases, it is possible to use one of the other body types, which are easier to use. Although the JMS API allows the use of message properties with byte messages, they are typically not used, since the inclusion of properties may affect the format.

StreamMessage contains a stream of primitive values in the Java programming language ("Java primitives") in its message body. It is filled and read sequentially.

ObjectMessage contains a Serializable Java object. It allows exchange of Java objects between applications. The consumer of the message must typecast the object received to it's appropriate type. Thus the consumer should before hand know the actual type of the object sent by the sender.

MapMessage carries name-value pair in its message body, where names are String objects, and values are Java primitives.

Q: What is the difference between BytesMessage and StreamMessage??
A: BytesMessage stores the primitive data types by converting them to their byte representation. Thus the message is one contiguous stream of bytes. While the StreamMessage maintains a boundary between the different data types stored because it also stores the type information along with the value of the primitive being stored. BytesMessage allows data to be read using any type. Thus even if your payload contains a long value, you can invoke a method to read a short and it will return you something. It will not give you a semantically correct data but the call will succeed in reading the first two bytes of data. This is strictly prohibited in the StreamMessage. It maintains the type information of the data being stored and enforces strict conversion rules on the data being read.