Originally Java has been designed as a robust, compact, slim and elegant programming language for designing portable and bug-free software applications for consumer devices. With the arrival of the Internet world wide, the designers of Java had made some additional enterprise-oriented features to make Java as a strong and excellent programming language for developing distributed, server-side applications to work on enterprise systems. Thus Java graduated to a robust server-side platform. This shift has much to do with Java's emerging role as a universal language for producing implementation-independent abstractions for common enterprise technologies. The JDBC API is the first vendor-independent abstraction for accessing SQL databases. This abstraction has been highly successful and appealing among the database vendors. This forced Java designers to come out with similar abstractions for other enterprise technologies. As a result of this, today Java boasts of having relevant abstractions to access all the enterprise suite of tools to provide a full-fledged server-side platform to design and deploy enterprise applications. In this overview, we are to see one of the most interesting and vital enterprise service being provided by different Message-Oriented Middleware (MOM) products and its Java abstraction, called Java Message Service (JMS) for accessing these MOM products.

The Java Message Service is a Java API implemented by enterprise messaging vendors to provide Java applications with a common and elegant programming model that is portable across message systems. JMS comprises an API (javax.jms package), and semantics for a messaging service that provides capabilities such as persistence, verification and transactions. The JMS specification provides a solid, adaptable foundation for the construction of a messaging infrastructure that can be applied to a wide range of application domains. Like other J2EE APIs, JMS is not an implementation but rather the specification of an API into a messaging system with compliant semantics. The JMS specification refers to a JMS provider that implementation the JMS API and semantics. There are a few methodologies for implementing the specification. The most common one is that of a client library and a message broker. Other possibilities include a JMS interface into an existing message infrastructure or JMS services as part of a larger J2EE implementation, such as an application server.

Enterprise messaging systems are used to send notification of events and data between software applications. These messaging system, also referred to as Message-Oriented Middleware (MOM) is generally defined as a software infrastructure that asynchronously connects multiple systems through the production and consumption of data messages.

The message is the core object of JMS. In addition to carrying the information payload, the message itself plays a key role in influencing routing, reliability and other aspects of message delivery. As in virtually all other messaging systems, a JMS message is a package of bytes that encapsulates the message body as a payload and then exposes metadata that identifies, at a minimum, the message its timestamp, its priority, its destination, and the type of message enclosed.

What MOM can Do? - MOM facilitates building distributed systems by transmitting messages from one application to another across the network. MOM also ensures that messages are properly distributed among applications. Apart from these, MOMs provide fault tolerance, load balancing, scalability and transactional support for enterprises that need to reliably exchange large quantities of messages. MOM vendors use different message formats and network protocols for exchanging messages. But as the basic semantics are the same, an API is being used to create a message, populate it with application data, assign its routing information, and send the message. The same API is used to receive messages produced by other applications. MOM eliminates the need for all systems to be available simultaneously. That is, the applications that receives messages and those that send messages are decoupled. MOM facilitates communication among large numbers of application nodes. MOM has a number of communication models that can be employed to integrate disparate systems.

JMS for MOM - MOM implementation, such as IBM's MQSeries and Progress SonicMQ are unfortunately proprietary. This has changed with the advent of Sun Microsystem JMS specification and its widespread adoption by developers of messaging infrastructures and application servers. The Java Messaging Service specification represents the leading approach to standards-based messaging middleware. JMS supports a universal messaging model that supports a variety of asynchronous and synchronous communication mechanisms. To deliver a message asynchronously means the sender is not required to wait for the message to be received or handled by the recipient; it is free to send the message and continue processing. Asynchronous messages are treated as autonomous units - each message is self-contained and carries all of the data and state needed by the business logic that processes it.

In asynchronous messaging, applications use a simple API to construct a message, then hand it off to the MOM for delivery to one or more intended recipients. MOM architectures of today vary in their implementation. The spectrum ranges from a centralized architecture that depends on a message server to perform routing, to a decentralized architecture that distributes the server processing out to the client machines. A varied array of protocols including TCP/IP, HTTP, SSL, and IP multicast are employed at the network transport layer. Even there are some messaging products that use hybrid of both architectures.

Centralized Architectures - Enterprise messaging systems that use a centralized architecture rely on a message server. A message server, also referred to as a message router or broker, is responsible for delivering messages from one messaging client to other messaging clients. The message server decouples a sending client from other receiving clients. Clients only see the messaging server, not other clients, which allows clients to be added and removed without any impact on the system. Typically, a centralized architecture uses a hub-and-spoke topology. That is, in a simple case, there is a centralized message server to which all message clients connect. In a real situation, the centralized message server is a cluster of distributed servers operating as a logical unit.

Decentralized Architectures - All decentralized architectures currently use IP multicast at the network level. A messaging system based on multicasting has no centralized message server. Some of the server functionality, such as persistence, security, and transactions, are embedded as a local part of the client, while message routing is delegated to the network layer by using the IP multicast protocol. IP multicast allows applications to join one or more IP multicast groups; each group uses an IP network address that will redistribute any messages it receives to all members in its group. In this way, applications can send messages to an IP multicast address and expect the network layer to redistribute the messages appropriately. Unlike a centralized architecture, a distributed architecture does not require a server for the purposes of routing messages. The network handles routing automatically.

Hybrid Architectures - A decentralized architecture mainly uses an IP multicast protocol and a centralized architecture usually uses TCP/IP protocol for communication between the various components. A message vendor may combine these two architectures. That is, clients first connect to a daemon process using TCP/IP, which in turn communicate with other daemon processes using IP multicast groups.

The Java Message Service defines six Message interface types that must be supported by JMS providers. The six message interfaces are Message, which serves as the base interface and its five sub-interfaces: TextMessage, StreamMessage, MapMessage, ObjectMessage, and BytesMessage. The Message interfaces are defined according to the kind of payload they are designed to carry. To support legacy payloads, there are text, bytes, and stream message types. In addition, there are several other message types to meet the emerging needs. One of them is ObjectMessage, which can carry serializable Java objects. An XML message type is also available to extend the TextMessage that allows developers to deal with the message directly through DOM or SAX interfaces. MapMessage type carries a set of name-value pairs as its payload.

The JMS specification offers the two most common models for messaging: publish/subscribe and point-to-point.

Messaging clients in JMS are called JMS clients, and the messaging system, the MOM, is called the JMS provider. A JMS application is a business system composed of many JMS clients and a JMS provider. A JMS client that produces a message is called a producer, while a JMS client that receives a message is called a consumer. A JMS client can be both a producer and a consumer

Each client application opens a single connection to the message broker, regardless of the mix of messaging models it intends to use. In JMS multiple connections are allowed, but typically are only one used when connecting to multiple distinct message brokers. Typically, a client will locate a broker through JNDI. Within the context of a connection, the client application establishes one or more sessions, each with its own transactional characteristics and acknowledgment modes.

Publish/subscribe is a one-to-many publishing model where client applications publish messages to topics, which are in turn subscribed to by other clients that are interested in those topics. A topic is a virtual channel to which consumers subscribe and all messages addressed to a topic are delivered to all the topic's consumers. Topics may be static or dynamic objects, and can be temporary for transitory or anonymous uses. Every consumer receives a copy of each message. This messaging model is by and large a push-based model, where messages are automatically broadcast to consumers that need not request or poll the topic for new messages. Here, the producer sending the message is not dependent on the consumer receiving the message. Normally, messages are received in FIFO order. When several messages await consumption by a subscriber, however, higher priority messages are presented to the client before those of lower priority, resulting in non-FIFO behavior. There are two types of subscriptions: durable and non-durable. A durable subscription indicates that the client wants to receive all the messages published to a topic, including messages published when the client connection is not active. The messaging system ensures that all messages published to the topic are retained until the durable subscriber acknowledges them or the messages have expired.

There is a parameter referred to as time-to-live, which specifies how long the message broker should retain the message in order to ensure that all subscribers receive it. If, after initial delivery, any durable subscribers did not acknowledge delivery, the message is retained for the time-to-live duration in anticipation that a durable subscriber will connect to the message broker and accept delivery. If the time-to-live is specified as zero, the message will not expire. When a message's time-to-live is reached, the broker will typically discard it. Typically, a message set to live forever will be discarded as soon as delivery to all current subscribers and all durable subscribers is complete.

Subscribers can ask the message system to filter the messages they receive by qualifying their subscriptions with message selectors. Message selectors cause the JMS provider to evaluate message headers and properties before sending messages to the client application. Message selectors employ a syntax based on a subset of SQL-92 conditional expressions. Because the JMS provider handles the filtering, the application itself is more efficient, and the messaging traffic imposes less bandwidth use.

Point-to-point (PTP) provides a traditional queuing mechanism where a client application sends messages, through a queue, to typically one receiving client that obtains the messages sequentially. A JMS message queue is an administered object that represents the destination for a message sender and a data source for a message receiver. The first message received by the broker is the first message delivered to a consumer. Consumers can either receive the message that is first in line, thus removing it from the queue, or browse through all the messages in the queue, causing no changes. The FIFO nature of the PTP model requires that the JMS provider retains the second through nth messages until the first message is consumed. Even when there are no clients associated with a queue, messages are retained. Hence, unlike the previous model, durability and persistence are implicit in PTP. This message model has been a pull- or polling-based model, where messages are requested from the queue instead of being pushed to the client automatically. In JMS, an option exists that allows point-to-point clients to use a push model similar to publish/subscribe. A given queue may have multiple receivers, but only one receiver may consume each message. The JMS provider takes care of doling out the work, insuring that each message is consumed once and only once by the next available receiver in the group. This messaging model also offers other features, such as a queue browser that allows a client to view the contents of a queue prior to consuming its messages.

Many real-world JMS applications use a mix of these two models: both publish/subscribe and point-to-point messaging use the same format of JMS message. The two JMS messaging models employ a common programming model. Quality of service (QoS), security, and acknowledgment modes (indicating how and when the messaging system is informed that a client has received a message) are all handled in a uniform manner for both messaging models. While the logical routing of publish/subscribe messages is quite different from that of point-to-point, both models share a hub-and-spoke architecture between clients and the message broker. The broker is the heart of the messaging service, acting as a hub through which all messages are routed. If there are more than one, they will be clustered for facilitating scalability and offering a higher level of fault tolerance. Clustered brokers also allow for centralized maintenance of security functions.

JMS clients access the message broker through the JMS API. Actually, the clients call a messaging client runtime library, which implements the JMS interface and communicates with the broker. As the over-the-wire protocol is not mentioned in the JMS specification, most JMS implementations perform some form of proprietary marshalling over one or more protocols, including TCP/IP, HTTP, or SSL.

Request-Reply Programming - Normally, JMS supports formalized acknowledgment of message receipt. JMS also provides a ReplyTo mechanism, allowing client applications to request that actions be carried out on their behalf by other applications. JMS supplies necessary design patterns and helper classes to make this easier. Request-reply can be thought of as an RMI-type mechanism where the interface is abstracted into a data message. Replies in the request-reply model are different from message acknowledgments. Here, replies are sent as full JMS messages in response to incoming messages, typically following some processing in the called client, where as message acknowledgments are a lower-level indication to the messaging system that a message has been received by a consumer.

Messages that use the JMSreplyTo field are called requests. Such messages typically expect that the consumer will perform some appropriate action based upon receipt of the message, and then provide a mutually understood message, referred to as reply. The JMSreplyTo message header field contains the temporary destination where a reply to the current message should be sent. The destination can be either a queue or a topic.

There are some additional JMS programming techniques, such as transactions, message acknowledgments, message routing, message reliability.

JMS provides a simple transaction mechanism, allowing a group of messages to act as a single unit of work. This is particularly handy for transmission of large XML documents as JMS messages, with the client application marshalling a large document through JMS as a transacted message set. Transactional behavior is controlled at the session level, and is optionally enabled when the session is created. When a session is transacted, message traffic is staged within the JMS provider until the client application either commits or rolls back the transaction. The completion of a session's current transaction automatically begins a new transaction.

The JMS message acknowledgment mechanism is the fundamental wiring that supports several important messaging system semantics, such as guaranteed delivery and transaction management. Acknowledgment is the means by which the messaging system is informed that a particular client has consumed a specific message. There are a number of different acknowledgment modes. Client applications may individually acknowledge messages or they may choose to acknowledge messages in applications-defined groups, by acknowledging the last received message in the group.

There are two primary mechanisms for intelligent message routing between client applications: hierarchical topics, and message selection. Distributed applications typically employ a mix of these two mechanisms.

Routing via hierarchical topics - Many JMS implementations allow topics to be defined in a hierarchical fashion, so that topics can be nested under other topics. When using implementations that support hierarchical topic namespaces, client applications can subscribe to the appropriate topic level to receive the most relevant information for the application or user. This technique provides a more granular approach to topic subscriptions, which can substantially reduce the amount of coding needed to filter unwanted messages, while supporting highly flexible-based routing.

Routing via message selection - By using this mechanism, consumers in both the messaging models can limit the specific messages that the client application will receive by qualifying their topic subscriptions or queue receivers with message selectors. A selector tells the JMS provider to evaluate message properties according to the rules expressed in the selector, prior to sending messages to the client application.

Generally, hierarchical topics are used for routing situations that are relatively static, while message selection is used for ad hoc or programmatic routing. Hierarchical topics require that the topic namespace schema be both well defined and universally understood. Message selectors are more flexible, and can provide significantly more advanced routing criteria, but also incur additional processing overhead as each message must be examined and the filtering rules applied. Both approaches require that the client application knows how it should filter messages at the time that it creates a consumer, and both can be used together.

Messaging Reliability - There are several factors that affect the assurance that a consumer will receive a produced message. In publish/subscribe model, a publisher has no guarantee that any subscribers exist for a particular topic. Subscriber message selectors inherently limit the number of messages that a client will receive. Regular subscriptions and durable subscriptions with a message selector definition that excludes a message will cause the consumer never to get that message. Message destruction can occur due to expiry of the timeout set for the message or due to an administrator action that permanently disposes of stored messages.

In PTP model, since multiple receivers can share the queue message load, reliability can only be assured by the set of active receivers on a queue at any point in time. Receiver message selectors inherently limit the number of messages that a client will receive. A queue would appear empty to any receiver that effectively deselects all the existing messages in the queue. At the same time, messages can stay on a queue until a receiver either provides a liberal message selector or no message selector at all. Message destruction can occur due to expiry of the message, or due to an administrator action that permanently disposes of stored messages.

Using JMS to transport XML - JMS provides an excellent means for transporting XML due to its support for the high-level semantics required. The product vendors have already started to put a wide range of XML applications, such as EAI to B2B supply chain integrations, on top of JMS message infrastructures. There are some techniques for transporting XML messages using JMS. At this point of time, there is no specific message type for XML data. Thus the application developers have to use the standard message types specified by JMS. There are tools like JAXP to manipulate XML messages.

As told above, a message selector allows a JMS consumer to be more selective about the messages it receives from a particular destination, that is, topic or queue, using message properties. An XML application can utilize this mechanism to provide content-based routing within the messaging system. JMS does not yet have a way for the messaging system to route messages based upon the payload of the message, which would be required for XML content-based routing without application intervention. Instead, the client application must programmatically search the XML message content for the desired data, and place it within the message properties. Once the relevant data has been copied to the message properties, subscribers can use the property values in message selectors, resulting in content-based routing.

There are some real-world application scenarios where enterprise messaging systems plays a very critical role. More importantly, JMS pairs with XML, the new buzzword among the Web application developers, in accomplishing many great problems. The primary one among them is EAI, which is discussed at Enterprise Application Integration.

Business-to-Business (B2B) - In the olden days, businesses data had been exchanged using Electronic Data Interchange (EDI) systems. Data was exchanged using rigid, fixed formats over proprietary Value Added Networks (VANs). Cost of entry was high and data was usually exchanged in batch process, not as real-time business events.

The Internet, XML and the modern messaging systems have dramatically changed the methodology of exchanging business data and resulted in highly interactive business-to-business solutions. The use of messaging systems makes it possible in arriving these modern B2B solutions as it allows organizations to cooperate without requiring them to tightly integrate their business systems. In addition, it lowers the barriers to entry since finer-grained participation is possible. Businesses can join in B2B and disengage depending on the queues and topics with which they interact.

A manufacturer can set up a topic for broadcasting requests for bids on raw materials. Suppliers can subscribe to the topic and respond by producing messages back to the manufacturer's queue. Suppliers can be added and removed at will, and new topics and queues for different types of inventory and raw materials can be used to partition the systems appropriately.

Geographic Dispersion - Nowadays many varieties of companies, such as brick-and-mortar, click-and-mortar and dot-coms, are geographically dispersed. Inventory systems in remote warehouses need to communicate with centralized back-office ERP systems at corporate headquarters. Sensitive employee data that is being administrated locally at each subsidiary needs to be synchronized with the main office. JMS message systems can ensure the safe and secure exchange of data across a geographically distributed business.

One-to-many applications - Auction sites, stock quote services, and securities exchanges all have to push data out to huge populations of recipients in a one-to-many fashion. In many cases, the broadcast of information needs to be selectively routed and filtered on a per recipient basis. While the outgoing information needs to be delivered in a one-to-many fashion, often the response to such information needs to be sent back to the broadcaster. Enterprise messaging is extremely useful in this situation as publish/subscribe model can be used to distribute the messages and PTP can be used for responses.

Building Dynamic Systems - Messaging systems combined with JMS can design dynamic systems. In JMS, publish/subscribe topics and PTP queues are centrally administered and are referred to as JMS administrated objects. Applications need not know the network location of topics or queues to communicate with other applications; they just use topic and queue objects as identifiers. Using topics and queues provides JMS applications with a certain level of location transparency and flexibility that makes it possible to add and remove participants in an enterprise system. For example, a system administrator can dynamically add subscribers to specific topics on an as-needed basis.

The ability to add and remove participants and consumers allows enterprise message systems to dynamically alter the routing and re-routing of messages in an already deployed environment. For example, a gateway accepts incoming purchase orders, converts them to the format appropriate for a legacy ERP system, and calls into the ERP system for processing. Other JMS applications represented as A and B also subscribe to the purchase order topic and do their own independent processing. Application A might be a legacy application in the company, while application B may be another company's business system, representing a B2B integration. It is fairly easy to add and remove JMS applications from this process.

All the middleware technologies, such as CORBA, Java RMI and Microsoft's DCOM are basically based on RPC methodology. Even the enterprise component model EJB is built on top of RPC. These distributed object computing technologies are being used to develop multi-tier distributed systems. Regardless of the platform, the core technology used in these systems is RPC-based middleware. RPC mimics the behavior of a system that runs in one process. When a remote procedure is being invoked, the caller is blocked until the procedure completes and returns control to the caller. Work is performed sequentially, ensuring that tasks are completed in a predefined order. The synchronized nature of RPC tightly couples the client and the server. The tightly coupled nature of RPC creates highly interdependent systems where a failure on one system has an immediate reflection on other systems. Thus RPC works well in many scenarios, but its synchronous, tightly coupled nature is a severe handicap in system-to-system processing where vertical applications are integrated together.

A fundamental concept of MOM is that communication between applications is intended to be asynchronous. Code that is written to connect the pieces together assumes there is a one-way message that requires no immediate response from another application. That is, there is no blocking. Once a message is sent, the messaging client can move on to other tasks and it need not wait for the reply. This is the main difference between RPC-based middleware technologies and JMS-compliant enterprise messaging systems. Also a failure in one does not affect others in the system. JMS supports guaranteed delivery, which ensures that intended consumers will eventually receive a message even if there is a partial failure. Guaranteed delivery uses a store-and-forward mechanism, which means that the underlying message server will write the incoming messages out to a persistent store if the intended consumers are not currently active. When the receiving applications come alive at a later time, the store-and-forward mechanism will deliver all of the messages that the consumers missed while unavailable. Thus JMS was designed to cover a broad range of enterprise applications, including EAI, B2B, push models. Through asynchronous processing, store-and-forward, and guaranteed delivery, it provides high availability capabilities to keep business applications in continuous operation with uninterrupted service. JMS offers flexibility of integration by providing publish/subscribe and PTP functionality.

Click for JMS Links

---