Interview Questions On Java,Java EE


Enter your email address:



Add to Technorati Favorites
Google PageRank Checker
Showing posts with label JMS. Show all posts
Showing posts with label JMS. Show all posts

Saturday, October 11, 2008

More JMS Questions

Question:What are different types of messaging?

Answer: There are two kinds of Messaging:
Synchronous Messaging: In Synchronous messaging, there is a client that waits for the server to respond to a message.
Asynchronous Messaging: In Asynchronous messaging, there is a client that does not wait for a message from the server rather an event is used to trigger a message from a server.

Question:What are the core JMS-related objects required for each JMS-enabled application?

Answer:Every JMS-enabled client has to establish the following:
• A connection object provided by the JMS server (the message broker)
• Within a connection, one or more sessions, which provide a context for message sending and receiving
• Within a session, either a queue or topic object representing the destination (the message staging area) within the message broker
• Within a session, the appropriate sender or publisher or receiver or subscriber object (depending on whether the client is a message producer or consumer and uses a point-to-point or publish/subscribe strategy, respectively)
• Within a session, a message object (to send or to receive)

Question:Can two different JMS services talk to each other? For instance, if A and B are two different JMS providers, can Provider A send messages directly to Provider B? If not, then can a subscriber to Provider A act as a publisher to Provider B?

Answer: As per JMS specification,one JMS provider cannot send messages directly to another provider. However, the specification does require that a JMS client must be able to accept a message created by a different JMS provider, so a message received by a subscriber to Provider A can then be published to Provider B. One caveat is that the publisher to Provider B is not required to handle a JMSReplyTo header that refers to a destination that is specific to Provider A.

Question:Why doesn't the JMS API provide end-to-end synchronous message delivery and notification of delivery?

Answer: Some messaging systems provide synchronous delivery to destinations as a mechanism for implementing reliable applications. Some systems provide clients with various forms of delivery notification so that the clients can detect dropped or ignored messages. This is not the model defined by the JMS API.

JMS API messaging provides guaranteed delivery via the once-and-only-once delivery semantics of PERSISTENT messages. In addition, message consumers can ensure reliable processing of messages by using either CLIENT_ACKNOWLEDGE mode or transacted sessions. This achieves reliable delivery with minimum synchronization and is the enterprise messaging model most vendors and developers prefer.

The JMS API does not define a schema of systems messages (such as delivery notifications). If an application requires acknowledgment of message receipt, it can define an application-level acknowledgment message.

Question:How is a java object message delivered to a non-java Client?

Answer: A non-java client cannot receive a message in the form of java object. As per specifications, the message sent should be received in the same format. It is the responsibility of the provider to handle the conversion of the data type and the message is transferred to the other end in its understandable format.

Question:What is MDB and what makes it special?

Answer: A Message Driven Bean(MDB) resembles a Stateless session bean where incoming and out going messages are handled and this ability to communicate asynchronously is the special feature about the Message driven bean.

Question:Give an example of using the publish/subscribe model.

Answer: JMS can be used to broadcast shutdown messages to clients connected to the Weblogic server on a module wise basis. If an application has six modules, each module behaves like a subscriber to a named topic on the server.
Continue reading...

Tuesday, July 10, 2007

Interview Questions On JMS

Continue reading...

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.

Pub-Sub Messaging Domain(Image Source:java.sun.com)
Continue reading...

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.



    PTP Messaging Model(Image Source:java.sun.com)
    Continue reading...

    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.



    Image Source:java.sun.com
    Continue reading...

    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.

    Continue reading...

    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.
    Continue reading...

    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.
    Continue reading...
     

    Disclaimer
    Interview Questions On Java,Java EE Copyright © 2016. Reads: best tracker