- Does the JMS API provide a version of a distributed Java event model?
Answer: The JMS API can be used, in general, as a notification service; however, it does not define a distributed version of Java Events.One alternative for implementing distributed Java Events would be as JavaBeans components that transparently, to the event producer and listener beans, distribute the events via the JMS API.
- Why are there two separate JMS API domains, point-to-point and publish/subscribe, instead of just one?
Answer: Even though there are many similarities, providing separate domains still seems to be important.It means that vendors aren't forced to support facilities out of their domain and that client code can be a bit more portable because products more fully support a domain (as opposed to supporting less defined subsets of a merged domain).
- Why doesn't the JMS API specify a set of JavaBeans components?
Answer: The JMS API is a low-level API, and like other low-level Java APIs, it doesn't lend itself to direct representation as JavaBeans components.
- How is the JMS API aligned with the CORBA Notification Service?
Answer: The Notification Service adds filtering, delivery guarantee semantics, durable connections, and the assembly of event networks to the CORBA Event Service.It gets its delivery guarantee semantics from the CORBA Messaging Service (which defines asynchronous CORBA method invocation).
Java technology is well integrated with CORBA.It provides Java IDL and COS Naming.In addition, OMG has recently defined RMI over IIOP.
It is expected that most use of IIOP from Java will be via RMI.It is expected that most use of COS Naming from Java will be via the JNDI API (Java Naming and Directory Service).The JMS API is a Java specific API designed to be layered over a wide range of existing and future Message Oriented Middleware (MOM) systems (just as the JNDI API is layered over existing name and directory services).
- 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.
These issues are more clearly understood when they are examined in the context of publish/subscribe applications.In this context, synchronous delivery and/or system acknowledgment of receipt are not an effective mechanism for implementing reliable applications (because producers by definition are not, and do not want to be, responsible for end-to-end message delivery).
- Why doesn't the JMS API provide a send-to-list mechanism?
Answer: Currently the JMS API provides a number of message send options; however, messages can only be sent to one Destination at a time.
The benefit of send-to-list is slightly less work for the programmer and the potential for the JMS provider to optimize the fact that several destinations are being sent the same message.
The down side of a send-to-list mechanism is that the list is, in effect, a group that is implemented and maintained by the client.This would complicate the administration of JMS clients.
Instead of the JMS API providing a send-to-list mechanism, it is recommended that providers support configuring destinations that represent a group.This allows a client to reach all consumers with a single send, while insuring that groups are properly administrable.
- Why doesn't the JMS API provide subscription notification?If it were possible for a publisher to detect when subscribers for a topic existed, it could inhibit publication on unsubscribed topics.
Answer: Although there may be some benefit in providing publishers with a mechanism for inhibiting publication to unsubscribed topics, the complexity this would add to the JMS API and the additional provider overhead it would require are not justified by its potential benefits.Instead, JMS providers should insure that they minimize the overhead for handling messages published to an unsubscribed topic.
- Can a message be acknowledged after its message consumer is closed?
Answer: Yes.Since message acknowledgment processing is performed at the session level, message acknowledgement is still relevant after a consumer is closed.All messages consumed by the session are acknowledged for the following two examples:
// CLIENT_ACKNOWLEDGE session
Message msg1 = topicSubscriber1.receive();
Message msg2 = topicSubscriber2.receive();
// transacted session
Message msg1 = queueReceiver.receive();
After the session has been closed, however, a call to the Message.acknowledge or Session.commit method throws an IllegalStateException.If close is called on a transacted session before the transaction in progress is committed, the transaction is rolled back.
Note that in order to prevent duplicate delivery of a message from a durable subscription or queue, a message that can still be acknowledged by a session cannot be redelivered to another message consumer.The message can only be redelivered to another message consumer when it can no longer be acknowledged by the session that initially received the message.
- What message distribution policy does the JMS API specify when there are two or more QueueReceivers for the same queue at the same time?
Answer: The JMS API does not specify a message distribution policy when two or more QueueReceivers are registered with a destination at the same time.JMS API semantics account for only one QueueReceiver at any point in time.The JMS API does not prohibit multiple QueueReceivers for a queue; it just does not define the behavior for this case.
- What is the recoverability of messages for closed consumers?
Answer: For messages consumed from a queue or durable subscription, a rollback ensures that the messages are not acknowledged and that they will be delivered to the next consumer of these persistent entities.The JMS specification states that messages delivered to non-durable subscribers may be dropped.This statement means that the JMS API does not define the recoverability of messages consumed from a non-durable subscriber.