JMS Interview Questions
What is Message Oriented Middleware (MOM) ? What is JMS ?Message Oriented Middleware (MOM) is generally defined as a software infrastructure that asynchronously communicates with other disparate systems (e.g. Mainframe system, C++ System, etc) through the production and consumption of messages. A message may be a request, a report, or an event sent from one part of an enterprise application to another.
Why use a messaging system as opposed to using Data Transfer Objects (aka DTOs, Value Objects)?
How MOM is different from RPC ?
Remote Procedure Call (e.g. RMI)Remote Procedure Call (RPC) technologies like RMI attempt to mimic the behavior of system that runs in one process. When a remote procedure is invoked the caller is blocked until the procedure completes and returns control to the caller. This is a synchronous model where process is performed sequentially ensuring that tasks are completed in a predefined order. The synchronized nature of RPC tightly couples the client (the software making the call) to the server (the software servicing the call). The client can not proceed (its blocked) until the server responds. The tightly coupled nature of RPC creates highly interdependent systems where a failure on one system has an immediate impact on other systems. Client is blocked while it is being processed.
MOMWith the use of Message Oriented Middleware (MOM), problems with the availability of subsystems are less of an issue. A fundamental concept of MOM is that communications between components is intended to be asynchronous in nature. Code that is written to connect the pieces together assumes that there is a oneway message that requires no immediate response. In other words, there is no blocking. Once a message is sent the sender can move on to other tasks; it doesn't have to wait for a response. This is the major difference between RPC and asynchronous messaging and is critical to understanding the advantages offered by MOM systems. In an asynchronous messaging system each subsystem (Customer, Account etc) is decoupled from the other systems. They communicate through the messaging server, so that a failure in one does not impact the operation of the others. Asynchronous messages also allows for parallel processing i.e. client can continue processing while the previous request is being satisfied.
Why use JMS ?Message Oriented Middleware (MOM) systems like MQSeries, SonicMQ, etc are proprietary systems. Java Message Service (JMS) is a Java API that allows applications to create, send, receive, and read messages in a standard way. Designed by Sun and several partner companies, the JMS API defines a common set of interfaces and associated semantics that allow programs written in the Java programming language to communicate with other messaging implementations (e.g. SonicMQ, TIBCO etc). The JMS API minimizes the set of concepts a programmer must learn to use messaging products but provides enough features to support sophisticated messaging applications. It also strives to maximize the portability of JMS applications across JMS providers. Many companies have spent decades developing their legacy systems. So, XML can be used in a non-proprietary way to move data from legacy systems to distributed systems like J2EE over the wire using MOM (i.e. Implementation) and JMS (i.e. Interface).
What are the components of the JMS architecture ?
Message producers:A component that is responsible for creating a message. E.g. QueueSender, and TopicPublisher. An application can have several message producers. Each producer might be responsible for creating different types of messages and sending them to different destinations (i.e. Topic or Queue). A message producer will send messages to a destination regardless of whether or not a consumer is there to consume it.
Message consumers:A component which resides on the receiving end of a messaging application. Its responsibility is to listen for messages on a destination (i.e. Topic or Queue). E.g. QueueReceiver, TopicSubscriber, MessageDrivenBean (MDB). A MDB is simply a JMS message consumer. A client cannot access a MDB directly as you would do with Session or Entity beans. You can only interface with a MDB by sending a JMS message to a destination (i.e. Topic or Queue) on which the MDB is listening.
Message destinations:A component which a client uses to specify the target of messages it sends/receives. E.g. Topic (publish/Subscribe domain) and Queue (Point-to-Point domain). Message destinations typically live on a MOM, which is remote to the clients. Message destinations are administered objects that need to be configured.
JMS messages:A message is a component that contains the information (aka payload) that must be communicated to another application or component. E.g. TextMessage (e.g. XML message), ObjectMessage (e.g. serialized object) etc.
JMS Administered objects:JMS administered objects are objects containing configuration information that are set up during application deployment or configuration and later used by JMS clients. They make it practical to administer the JMS API in the enterprise. These administered objects are initialized when the application server starts. When a producer or a consumer needs to get a connection to receive or send a JMS message, then you need to locate the configured administered objects QueueConnectionFactory or TopicConnectionFactory. Message destinations are administered objects that need to be configured as well. These administered objects hide provider-specific details from JMS clients.
JNDI naming service:For a producer and consumer to be able to use the administered objects to send and receive messages, they must know how to locate things such as the destination and connection factories.
Are messaging applications slow ?While there is some overhead in all messaging systems, but this does not mean that the applications that are using messaging are necessarily slow. Messaging systems can achieve a throughput of 70-100 messages per second depending on the installation, messaging modes (synchronous versus asynchronous, persistent versus non-persistent), and acknowledgement options such as auto mode, duplicates okay mode, and client mode etc. The asynchronous mode can significantly boost performance by multi-tasking.
For example: In an Internet based shopping cart application, while a customer is adding items to his/her shopping cart, your application can trigger an inventory checking component, and a customer data retrieval component to execute concurrently. Performance tuning comes at a cost of reliability and flexibility.
Some tips on performance:
Are messaging applications reliable ? What is a durable message delivery ?This is basically a tradeof between performance and reliability. If reliability is more important then the:
What are some of the key message characteristics defined in a message header ?Characteristic Explanation
What are the different body types (aka payload types) supported for messages ?All JMS messages are read-only once posted to a queue or a topic.
What is a message broker ?A message broker acts as a server in a MOM. A message broker performs the following operations on a message it receives:
What type of messaging is provided by JMS ?
Point-to-Point:It provides a traditional queue based mechanism where the client application sends a message through a queue to typically one receiving client that receives messages sequentially. A JMS message queue is an administered object that represents the message destination for the sender and the message source for the receiver. A Point-to-Point application has the following characteristics:
Publish/Subscribe:It is a one-to-many publishing model where client applications publish messages to topics, which are in turn subscribed by other interested clients. All subscribed clients will receive each message. A Publish/Subscribe application has the following characteristics:
Example: A bulletin board application may use a topic based publish/subscribe model where everyone who isinterested in particular news becomes a subscriber and when a message is published, it is sent to all its subscribers.
How do you determine whether it would be better to use a Topic or Queue ?You must choose to use a Topic if one of the following conditions applies:
How does XML over HTTP compare with XML using JMS ? Why use XML with JMS ?XML itself does not specify a communications infrastructure. If you do not need reliable and scalable messaging then use XML over HTTP. This approach is sufficient for rudimentary applications but does not scale for distributed applications across multiple systems.
XML over HTTPSimple to implement, widely compatible and has less performance overhead but HTTP does not provide reliability in terms of guaranteed delivery because there is no message persistence, no inherent reporting facility for failed message delivery and no guaranteed once only delivery. The application programmer must build these services into the application logic to provide reliability & persistence, which is not an easy task.
XML over JMSThis is an easy to implement, reliable, scalable and robust solution. The main disadvantage of this approach is that the JMS providers (i.e. Message Oriented Middleware) use a proprietary protocol between producer and consumer. So to communicate, you and your partners need to have the same MOM software (E.g. MQSeries). JMS allows you to toss one MOM software and plug-in another but you cannot mix providers without having to buy or build some sort of bridge.
Why use XML with JMS ?
What are the security related issues you need to consider ?
XML Interview Questions >>>