What is messaging and how is it different from RMI?
Messaging occurs between applications or software components which may or may not be distributive in nature.In enterprise applications where the possibility of distributed components across the geographies are too high, messaging comes as an obvious choice to make them communicate with each other.
In Java , middleware(which acts as an infrastructural support for messaging) level messaging is supported with Java Message Service(JMS) APIs.JMS is a specification (java.sun.com/products/jms ) that describes the properties and behavior of an information pipe for Java software. It also describes how Java client applications interact with the information pipe.
JMS helps business applications asynchronously send and receive critical business data and events.It supports both message queueing and publish-subscribe styles of messaging.
The constituents of JMS are producers,consumers and messages themselves through interfaces' abstraction.The beauty lies here in loose coupling and infact message broker systems need not go in details of message-contents, they just have to deliver them between systems reliably.There is not dependency on APIs of systems involved in message communications.
In case of RMI, the message passing is tightly coupled with APIs of remote application or component.That is what makes JMS as an obvious choice in enterprise applications for reliable messaging.
When is JMS needed?
JMS can be used in following scenarios:
- When distributed components,applications within an enterprise need to communicate with one another without creating any sort of dependencies(loose coupling support by JMS).This communication could either be synchronous or asynchronous.
- When an application has to communicate with a provider without worrying its availability,.i.e. in an asynchronous way.A synchronous communication occurs when message requested is consumed immediately that means both producer and consumer are up and running at the same time while in case of asynchronous communication it is not necessary to have both entities available at the same time. An application may like to send a message to other without waiting for response and keep on doing its job.
How Does the JMS API Work with the Java EE Platform?
The JMS API in the Java EE platform has the following features.
* Application clients, Enterprise JavaBeans (EJB) components, and web components can send or synchronously receive a JMS message. Application clients can in addition receive JMS messages asynchronously. (Applets, however, are not required to support the JMS API.)
* Message-driven beans, which are a kind of enterprise bean, enable the asynchronous consumption of messages. A JMS provider can optionally implement concurrent processing of messages by message-driven beans.
* Message send and receive operations can participate in distributed transactions, which allow JMS operations and database accesses to take place within a single transaction.
The JMS API enhances the Java EE platform by
-allowing loosely coupled, reliable, asynchronous interactions among Java EE components and legacy systems capable of messaging.
-supporting distributed transactions and allowing for the concurrent consumption of messages. For more information, see the Enterprise JavaBeans specification, v3.0.
Moreover, a JMS provider can be integrated with the application server using the Java EE Connector architecture. You access the JMS provider through a resource adapter. This capability allows vendors to create JMS providers that can be plugged in to multiple application servers, and it allows application servers to support multiple JMS providers.
Explain JMS API Architecture.
A JMS application is consisted of the following parts as shown in the figure at the end of this post:
-JMS Provider is a messaging system that implements the JMS interfaces and provides administrative and control features.
-JMS Clients are any Java EE application component except Applets.
-Messages are objects that exchange information between JMS clients.
-Administrative objects are preconfigured JMS objects created by an administrator for the use of clients.
Administrative tools bind destinations and connection factories into a JNDI namespace. A JMS client can then use resource injection to access the administered objects in the namespace and then establish a logical connection to the same objects through the JMS provider.
Explain Point-to-Point Messaging Domain.
The constituents of a point-to-point (PTP) product or application are message queues, senders, and receivers. Each message is addressed to a specific queue, and receiving clients extract messages from specific queue(s) . Queues retain all messages sent to them until the messages are consumed or until the messages expire.
So in PTP messaging domain:-
# Each message has only one consumer.
# There are no timing dependencies on a sender and a receiver of a message . The receiver can fetch the message oblivious of its availability when the client sent the message.
# The receiver acknowledges the successful processing of a message.
PTP messaging is used when every message sent must be processed successfully by one consumer.
Explain Publish/Subscribe Messaging Domain.
In a publish/subscribe (pub/sub) product or application, clients(publishers as well as subscribers) address messages to a topic, which functions similar to a bulletin board. Both publishers and subscribers are generally anonymous and can dynamically publish or subscribe to the content hierarchy. The system takes care of distributing the messages arriving from a topic's multiple publishers to its multiple subscribers. Topics retain messages only as long as it takes to distribute them to current subscribers.
Pub/sub messaging has the following characteristics.
* Each message can have multiple consumers.
* Publishers and subscribers have a timing dependency. A client that subscribes to a topic can consume only messages published after the client has created a subscription, and the subscriber must continue to be active in order for it to consume messages.
No comments:
Post a Comment