Technical Sample Questions : C |
Java | Unix |
Operating Systems |
Java Sample Questions ›› Java Messaging Service Sample Questions
Technical Java Sample Questions : Java Messaging Service Sample Questions
« Previous || Next »
Java Messaging Service Sample Question Number :
- Why can't I run the JMS API sample programs using the J2EE 1.2.x SDK?
Answer: The J2EE 1.2.x Reference Implementation did not include an implementation of the JMS API.It included only the interfaces.The JMS Reference Implementation is available as part of J2EE 1.3 and you can run the sample programs with the J2EE 1.3 server.See the JMS Tutorial for information on running simple JMS client programs with the J2EE 1.3 server.
Please see Java Message Service API Licensees for a list of vendors that provide implementations of the JMS API.Many of these vendors have demonstration copies of their JMS API implementations that you can use to run the JMS API samples that you downloaded from the website.
- According to the specification, "Getting a property value for a name which has not been set is handled as if the the property exists with a null value." In the case of getStringProperty, does this mean a null value or a null string?
Answer: Either is permissible.The reason for this ambiguity is that some MOM systems do not have the native concept of a null string, so they convert all null-valued strings at send time to empty strings.
- I used the Connection.setExceptionListener(ExceptionListener) method to try to handle connection problems, but when I stop the server, no JMSException seems to be triggered; the onException method is not called.Is this a bug?
Answer: The JMS specification does not specify exactly what exceptions are delivered to an ExceptionListener or when they are delivered, so providers vary in how they handle connection problems.Check with your JMS provider if you have questions.
- According to Section 3.4 of the JMS Specification, a client can effectively set only three of the message header fields.All the others are set either by the JMS provider or by the send or publish method.Why do all the fields have a setter method, when any client setting will be overridden when the message is sent or when the JMS provider delivers it?Wouldn't it make sense to allow only getter methods for most of the fields?
Answer: The specification requires setter methods mainly for consistency, so that each message header field has both a getter and setter method.Another reason is to allow a receiving client to change a field after a message is received but before it is passed to some other part of an application for processing.Although most setter methods are used very rarely, they are provided to give programmers flexibility.
- 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?[new!]
Answer: The answers are no to the first question and yes to the second.The JMS specification does not require that one JMS provider be able to 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
- What are the types of messaging?
Answer: There are two kinds of Messaging. Synchronous messaging involves a client that waits for the server to respond to a message. Asynchronous messaging involves a client that does not wait for a message from the server. An event is used to trigger a message from a server.
- What is publish/subscribe messaging?
Answer: With publish/subscribe message passing the sending application/client establishes a named topic in the JMS broker/server and publishes messages to this queue. The receiving clients register (specifically, subscribe) via the broker to messages by topic; every subscriber to a topic receives each message published to that topic. There is a one-to-many relationship between the publishing client and the subscribing clients.
- 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 insure 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.
- What are the core JMS-related objects required for each JMS-enabled application?
Answer: Each JMS-enabled client must establish the following: o A connection object provided by the JMS server (the message broker) o Within a connection, one or more sessions, which provide a context for message sending and receiving o Within a session, either a queue or topic object representing the destination (the message staging area) within the message broker o 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)
- What is the Role of the JMS Provider?
Answer: The JMS provider handles security of the messages, data conversion and the client triggering. The JMS provider specifies the level of encryption and the security level of the message, the best data type for the non-JMS client.