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.
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.
-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.
Image Source:java.sun.com
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:-
So in PTP messaging domain:-
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.
Q: What is JMS?
A: JMS is an acronym used for Java Messaging Service. It is Java's answer to creating software using asynchronous messaging. It is one of the official specifications of the J2EE technologies and is a key technology.
Q: How JMS is different from RPC?
A: In RPC the method invoker waits for the method to finish execution and return the control back to the invoker. Thus it is completely synchronous in nature. While in JMS the message sender just sends the message to the destination and continues it's own processing. The sender does not wait for the receiver to respond. This is asynchronous behavior.
Q: What are the advantages of JMS?
A: JMS is asynchronous in nature. Thus not all the pieces need to be up all the time for the application to function as a whole. Even if the receiver is down the MOM will store the messages on it's behalf and will send them once it comes back up. Thus at least a part of application can still function as there is no blocking.
Q: Are you aware of any major JMS products available in the market?
A: IBM's MQ Series is one of the most popular product used as Message Oriented Middleware. Some of the other products are SonicMQ, iBus etc.All the J2EE compliant application servers come built with thier own implementation of JMS.
Q: What are the different types of messages available in the JMS API?
A: Message, TextMessage, BytesMessage, StreamMessage, ObjectMessage, MapMessage are the different messages available in the JMS API.
Q: What are the different messaging paradigms JMS supports?
A: Publish and Subscribe i.e. pub/suc and Point to Point i.e. p2p.
Q: What is the difference between ic and queue?
A: A ic is typically used for one to many messaging i.e. it supports publish subscribe model of messaging. While queue is used for one-to-one messaging i.e. it supports Point to Point Messaging.
Q: What is the role of JMS in enterprise solution development?
A: 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.
Q: What is the use of Message object?
A: Message is a light weight message having only header and properties and no payload. Thus if theIf the receivers are to be notified abt an event, and no data needs to be exchanged then using Message can be very efficient.
Q: What is the basic difference between Publish Subscribe model and P2P model?
A: Publish Subscribe model is typically used in one-to-many situation. It is unreliable but very fast. P2P model is used in one-to-one situation. It is highly reliable.
Q: What is the use of BytesMessage?
A: BytesMessage contains an array of primitive bytes in it's payload. Thus it can be used for transfer of data between two applications in their native format which may not be compatible with other Message types. It is also useful where JMS is used purely as a transport between two systems and the message payload is opaque to the JMS client. Whenever you store any primitive type, it is converted into it's byte representation and then stored in the payload. There is no boundary line between the different data types stored. Thus you can even read a long as short. This would result in erroneous data and hence it is advisable that the payload be read in the same order and using the same type in which it was created by the sender.
Q: What is the use of StreamMessage?
A: StreamMessage carries a stream of Java primitive types as it's payload. It contains some conveient methods for reading the data stored in the payload. However StreamMessage prevents reading a long value as short, something that is allwed in case of BytesMessage. This is so because the StreamMessage also writes the type information alonwgith the value of the primitive type and enforces a set of strict conversion rules which actually prevents reading of one primitive type as another.
Q: What is the use of TextMessage?
A: TextMessage contains instance of java.lang.String as it's payload. Thus it is very useful for exchanging textual data. It can also be used for exchanging complex character data such as an XML document.
Q: What is the use of ObjectMessage?
A: ObjectMessage contains a Serializable java object as it's payload. Thus it allows exchange of Java objects between applications. This in itself mandates that both the applications be Java 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. Wrong type casting would result in ClassCastException. Moreover the class definition of the object set in the payload should be available on both the machine, the sender as well as the consumer. If the class definition is not available in the consumer machine, an attempt to type cast would result in ClassNotFoundException. Some of the MOMs might support dynamic loading of the desired class over the network, but the JMS specification does not mandate this behavior and would be a value added service if provided by your vendor. And relying on any such vendor specific functionality would hamper the portability of your application. Most of the time the class need to be put in the classpath of both, the sender and the consumer, manually by the developer.
Q: What is the use of MapMessage?
A: A MapMessage carries name-value pair as it's payload. Thus it's payload is similar to the java.util.Properties object of Java. The values can be Java primitives or their wrappers.
No comments:
Post a Comment