Details
Please explain architecture of JMS.
JMS applications consists of following parts:
1. JMS Provider: MoM that implements JMS interfaces. JEE platform should have JMS server. JMS Provider & MoM terms are used interchangeably in this document.
2. JMS Clients: Application programs or components that produce of consume messages.
3. Messages: Information.
4. Administered Objects: Destinations & Connection Factories.
What is meant by Administered Objects?
Administered objects are (java) objects which contains Configuration Information (parameters). They contain only the configuration information and has no information/resource related to actual connection. These Administered objects are (generally) created by JMS administrator and used by client to create actual connections.
JMS Specifications
JMS administered objects are objects containing JMS configuration information that are created by a JMS administrator and later used by JMS clients. They make it practical to administer JMS applications in the enterprise.
Although the interfaces for administered objects do not explicitly depend on JNDI, JMS establishes the convention that JMS clients find them by looking them up in a namespace using JNDI.
An administrator can place an administered object anywhere in a namespace. JMS does not define a naming policy.
This strategy of partitioning JMS and administration provides several benefits:
• It hides provider-specific configuration details from JMS clients.
• It abstracts JMS administrative information into Java objects that are easily
organized and administered from a common management console.
• Since there will be JNDI providers for all popular naming services, thismeans JMS providers can deliver one implementation of administered objects that will run everywhere.
An administered object should not hold on to any remote resources. Its lookup should not use remote resources other than those used by JNDI itself.
Clients should think of administered objects as local Java objects. Looking them up should not have any hidden side effects or use surprising amounts of local resources.
JMS defines two administered objects, Destination and ConnectionFactory.
It is expected that JMS providers will provide the tools an administrator needs to create and configure administered objects in a JNDI namespace. JMS provider implementations of administered objects should be both javax.naming.Referenceable and java.io.Serializable so that they can be stored in all JNDI naming contexts. In addition, it is recommended that these implementations follow the JavaBeansTM design patterns.
Define JMS API Programming Model
Why Connection Factory & Destinations are called Administered objects?
Both of them represent the physical properties of MoM. Connection Factory for actual connection parameters and actual topics and queues(destinations in short). Generally, these objects are configured outside of the application (using JNDI) and hence called the Administered objects.
What is connection factory?
Connection factory, as the name suggests, is used to create connection (to the provider (MoM)). Since it is Java, Connection Factory is a Java Object. In reality, it is a class that encapsulates a set of configuration parameters that help in creating a physical connection with MoM.
JavaDoc for Connection Factory Interface is very similar to that of Destination Interface. See Destination.
What is a Destination? What is difference between Topic & Queue?
Destinations are the actual topics or queues which are configured in MoM. From JMS perspective, it is the (java) object. A client uses it to specify the target of messages it produces and source of messages it consumes. Two types: Topics & Queues.
Some excerpts from Destination Java Doc:
A Destination object encapsulates a provider-specific address. Benefits
Destination objects support concurrent use.
It hides provider-specific details from JMS clients.
JMS provider implementations of administered objects should implement the javax.naming.Referenceable and java.io.Serializable interfaces so that they can be stored in all JNDI naming contexts
An administered object should not hold on to any remote resources. Its lookup should not use remote resources other than those used by the JNDI API itself.
Refer to Java Doc for more details.
What is difference between connection factory and topic/queue connection factory and similar objects?
Most of the tasks which can be done by specific interfaces (TopicSession, QueueSession) can be done common interfaces (Session_. It was not possible prior to current version (Ver 1.1). JMS states to use domain-independent "common interface".
JMS Specs: JMS provides a set of interfaces that allow the client to send and receive messages in both domains, while supporting the semantics of each domain. JMS also provides client interfaces tailored for each domain. Prior to version 1.1 of the JMS specification, only the client interfaces that were tailored to each domain were available. These interfaces continue to be supported to provide backward compatibility for those who have already implemented JMS clients using them. The preferred approach for implementing clients is to use the domain-independent interfaces. These interfaces, referred to as the “common interfaces”, are parents of the domain-specific interfaces.
Please note: PTP and Publish-Subscribe are called JMS Domains
What is a Connection?
Connection is an object which encapsulates the virtual connection for MoM. E.g. connection could represent an open TCP/IP socket between a client and a provider. JavaDoc excerpt: Because the creation of a connection involves setting up authentication and communication, a connection is a relatively heavyweight object. Most clients will do all their messaging with a single connection.
JMS Specifications
A JMS Connection is a client’s active connection to its JMS provider. It will typically allocate provider resources outside the Java virtual machine.
Connection objects support concurrent use.
A Connection serves several purposes:
• It encapsulates an open connection with a JMS provider. It typically represents an open TCP/IP socket between a client and a provider’s service daemon.
• Its creation is where client authentication takes place.
• It can specify a unique client identifier.
• It creates Session objects.
• It provides ConnectionMetaData.
• It supports an optional ExceptionListener.
Due to the authentication and communication setup done when a Connection is created, a Connection is a relatively heavyweight JMS object. Most clients will do all their messaging with a single Connection. Other more advanced applications may use several Connections. JMS does not architect a reason for using multiple connections (other than when a client acts as a gateway between two different providers); however, there may be operational reasons for doing so.
What is a session?
A Session is a factory for sessions that use its underlying connection to a JMS provider for producing and consuming messages. It provides transactional context.
JMS Specs
A JMS Session is a single-threaded context* for producing and consuming messages. Although it may allocate provider resources outside the Java virtual machine, it is considered a lightweight JMS object.
A Session serves several purposes:
• It is a factory for its MessageProducers and MessageConsumers.
• It is a factory for TemporaryTopics and TemporaryQueues.
• It provides a way to create Queue or Topic objects for those clients that need to dynamically manipulate provider-specific destination names.
• It supplies provider-optimized message factories.
• It supports a single series of transactions that combine work spanning this session’s producers and consumers into atomic units.
• It defines a serial order for the messages it consumes and the messages it produces.
• It retains messages it consumes until they have been acknowledged.
• It serializes execution of MessageListeners registered with it.
• It is a factory for QueueBrowsers.
How would you listen to a topic?
ConnectionFactory.createConnection().createSession().createConsumer(theTopicObject).
References:
JEE Tutorial - Primary Source