This chapter is from the book
This chapter is from the book
This chapter is from the book
JMS Architecture
JMS applications are portable across different JMS providers because the JMS architecture abstracts provider-specific proprietary information and is used by the application only at runtime. There are four elements to JMS architecture: JMS clients, the JMS provider, administered objects, and JMS messages. These elements are illustrated in Figure 12-3.
){kind=link}
Figure 12-3 JMS architecture:producer,consumer,provider,message, and administrative objects
JMS Clients
JMS clients are applications that encapsulate business logic. JMS clients are written in Java and use the JMS API to send and receive messages. JMS clients can also communicate with non-JMS clients, or Java or non-Java client applications using the native client API instead of the JMS API to send and receive messages. We'll discuss how to write JMS clients later in JMS programming model section.
JMS Provider
The JMS provider is the message server that a vendor provides to implement the JMS SPI in addition to other messaging services and functionality necessary in an enterprise messaging system. The messaging server provides the necessary infrastructure services to deliver the JMS messages from one JMS client to another JMS client. These services include message routing and providing message persistence. Some of the popular messaging servers in the market today are MQSeries (IBM), JMQ (Sun), FioranoMQ (Fiorano) and SonicMQ (Progress).
Administered Objects
The JMS specification allows JMS providers to differ significantly in their underlying messaging technology and on how they are installed and administered. Therefore, for the JMS clients to be portable they must be isolated from the proprietary aspect of the JMS provider. This is accomplished by defining JMS administered objects. Administered objects encapsulate provider-specific configuration information and are created and customized by the provider's administrator using the provider's tool and later used by clients. Think of administered objects as preconfigured JMS objects created by an administrator that clients use for providing messaging services. There are two kinds of administered objects: destination objects and ConnectionFactory objects. The destination object is the object a client uses to specify the destination of a message it's sending and the source of messages it receives; in other words, think of destination as a virrtual address. The ConnectionFactory object is the object a client uses to create a connection with the JMS provider. Destination and ConnectionFactory objects are placed by an administrator in a JNDI namespace, such as an LDAP directory. The clients use a standard JNDI lookup method to locate these administered objects in a distributed environment, as shown in Figure 12-3.