Clouds
Home

J2EE Overview

J2EE Servlet 1

J2EE Servlet 2

J2EE JSP

J2EE JDBC

J2EE JNDI LDAP

J2EE RMI

J2EE EJB

J2EE JMS

J2EE XML

J2EE STRUTS

J2EE SERVERS

J2EE Best Practices

J2EE Logging

J2EE Testing

J2EE Deployment

J2EE Development Process

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)?

  • Firstly, messaging enables loosely coupled distributed communication. A component sends a message to a destination, and the recipient can retrieve the message from the destination. However, the sender and the receiver do not have to be available at the same time in order to communicate and also they are not aware of each other. In fact, the sender does not need to know anything about the receiver; nor does the receiver need to know anything about the sender. The sender and the receiver need to know only what message format and what destination to use. In this respect, messaging differs from tightly coupled technologies, such as Remote Method Invocation (RMI), which requires an application to know a remote application's methods.
  • Secondly, messaging can communicate with disparate systems (e.g. Mainframe, C++ etc) via XML etc.

    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.

    MOM

    With 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:

    • Choose proper acknowledgement mode - AUTO_ACKNOWLEDGE or DUPS_OK_ACKNOWLEDGE give better performance than CLIENT_ACKNOWLEDGE.
    • Choose non-durable (i.e. non-persistent) messages where appropriate.
    • Process messages concurrently by using the server session pool. Each session in the pool can execute separate message concurrently. The JMS specification states that multi-threading a session, producer, or message method can results in non-deterministic behavior. So if your application has limited number of threads then try increasing the number of sessions. Open a connection only when required to and close it immediately after you have finished with it.
    • Transactional messages are accumulated at MOM server until the transaction is committed or rolled back. This imposes significant overhead on JMS server. So divide transactional messages and non-transactional messages separately.
    • Carefully set some of the configuration settings on message destinations, producer/consumer etc. This is usually a trade-off between performance and reliability. So increasing "Redelivery delay", reducing "Destination size" and "Maximum number of messages" can improve performance. The parameters "TimeToLive" and "DeliveryMode" are important from the performance and reliability perspective.
    • Choose the message type carefully and compress large messages (e.g. larger than 1 MB) in a JMS application in order to reduce the amount of time required to transfer messages across the network and memory used by the JMS server at the expense of an increase in CPU usage (i.e. to compress and uncompress) of the client. Less size gives a better performance. A ByteMessage takes less memory than a TextMessage. ObjectMessage carries a serialized Java object and hence network overhead can be reduced by marking the variables that need not be sent across the network as transient.
    • Favor using JMS message header fields (e.g. JMSCorrelationID, JMSMessageID, JMSReplyTo, JMSPriority, JMSTimestamp, JMSType etc) and/or the message body (carries main information i.e. payload as XML, Object, Stream etc) as opposed to using user-defined message properties which incur an extra cost in serialization, and are more expensive to access than standard JMS message header fields.
      For example: message.setStringProperty("AccountType", "Credit" );//user-defined message property Also, avoid storing large amount of data in user-defined properties or the JMS header fields because only message bodies can be compressed or paged out (i.e. freeing up virtual memory by writing it out to disk when paging is supported and enabled).
    • Using a selector is expensive and it is important to consider when you are deciding where in the message to store application data that is accessed via JMS selectors. By default, a message consumer will process every message that is sent to its destination. You can modify this behavior to allow message consumers to process only the message they are interested in using message selection and filtering. There two steps involved in setting up a message filter:
    • Initialize message header fields and/or user-defined message properties.
    • Message consumers specify a query string to select certain messages based on the message header fields and user defined message properties. A message selector cannot reference the message body.

    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:
  • Acknowledgement mode should be set to AUTO where once-and-only once delivery is guaranteed.
  • Message delivery mode should be set to durable (aka persistent) where the MOM writes the messages to a secure storage like a database or a file system to insure that the message is not lost in transit due to a system failure.

    What are some of the key message characteristics defined in a message header ?

    Characteristic Explanation
    • JMSCorrelationID:: Used in request/response situations where a JMS client can use the JMSCorrelationID header to associate one message with another. For example: a client request can be matched with a response from a server based on the JMSCorrelationID.
    • JMSMessageID:: Uniquely identifies a message in the MOM environment.
    • JMSDeliveryMode:: This header field contains the delivery modes: PERSISTENT or NON_PERSISTENT.
    • JMSExpiration:: This contains the time-to-live value for a message. If it is set to zero, then a message will never expire.
    • JMSPriority:: Sets the message priority but the actual meaning of prioritization is MOM vendor dependent.

    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.
    • Text message: body consists of java.lang.String (e.g. XML).
    • Map message: body consists of key-value pairs.
    • Stream message: body consists of streams of Java primitive values, which are accessed sequentially.
    • Object message: body consists of a Serializable Java object.
    • Byte message: body consists of arbitrary stream of bytes.

    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:
    • Processes message header information.
    • Performs security checks and encryption/decryption of a received message.
    • Handles errors and exceptions.
    • Routes message header and the payload (aka message body).
    • Invokes a method with the payload contained in the incoming message (e.g. calling onMessage(..) method on a Message Driven Bean (MDB)).
    • Transforms the message to some other format. For example XML payload can be converted to other formats like HTML etc with XSLT.

    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:
    • A Point-to-Point producer is a sender (i.e. QueueSender).
    • A Point-to-Point consumer is a receiver (i.e. QueueReceiver).
    • A Point-to-Point destination is a queue (i.e. Queue).
    • A message can only be consumed by one receiver.
    Example: A call center application may use a queue based Point-to-Point domain to process all the calls where all the phone calls do not go to all the operators, but only one.

    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:
    • A Publish/Subscribe producer is a publisher (i.e. TopicPublisher).
    • A Publish/Subscribe consumer is a subscriber (i.e. TopicSubscriber).
    • A Publish/Subscribe destination is a topic (i.e. Topic).
    • A message can be consumed by multiple subscribers.
    If a message publisher is also a subscriber, then a publisher can receive its own message sent to the destination. This behavior is only applicable to publish/subscribe model. This behavior can be controlled by setting the "noLocal" attribute to true when creating the publisher or the subscriber.
    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:
    • Same message must be replicated to multiple consumers (With Queue a message can only be consumed by one receiver).
    • A message should be dropped if there are no active consumers that would select it.
    • There are many subscribers each with a unique selector.

    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 HTTP

    Simple 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 JMS

    This 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 ?

    • Organizations can leverage years or even decades of investment in Business-to-Business (B2B) Electronic Data Interchange (EDI) by using JMS with XML. XML is an open standard and it represents the data in a non-proprietary way.
    • Sending XML messages as text reduces coupling even more compared to sending serializable objects. XML also solves the data representation differences with XML based technologies such as XSLT . For example, the way "Enterprise X" defines a purchase order will be different from the way "Enterprise Y" defines it. So the representation of XML message by "Enterprise X" can be transformed into the format understood by "Enterprise Y" using XSLT (see next section).
    • Both enterprises may be using different applications to run their business. For example Enterprise "X" may be using Java/J2EE, while "Enterprise Y" may be using SAP. XML can solve the data formatting problems since it is an open standard with a self describing data format, which allows the design of business specific markup languages and standards like FIXML (Financial Information eXchange Markup Language), FpML (Financial products Markup Language - derivative products), WML (Wireles Markup Language - for wireless devices ), SAML (Security Assertion Markup Language) etc. The structure of an XML document is similar to that of business objects with various attributes. This allows for the natural conversion of application-specific objects to XML documents and vice versa.

    What are the security related issues you need to consider ?

    • Authentication: Only valid applications and users are allowed to send and receive messages.
    • Data integrity: Data should not be tampered with while in transit.
    • Encryption: sensitive data should be encrypted while in transit to maintain confidentiality and privacy.


    XML Interview Questions >>>




    Home Clouds