Professional JMS

The JMS specification as of version 1.0.2 does not address the following features, even though some messaging providers add support for these in their product implementations:

• A Wire Protocol for Messaging

  JMS does not specify a wire protocol for messaging. It lets the messaging provider take care of specific protocols used in the implementation.

• A Message Metadata Repository

  JMS does not define a repository for storing message type definitions; neither does it define a language for creating message type definitions.

• Load Balancing Criteria and Fault-tolerant Mechanisms

  A large number of products in the market today provide support for multiple, cooperating clients implementing critical services. The JMS API does not specify how such clients cooperate to appear to be a single, unified service.

• Error Notification

  A number of messaging products define system messages that provide asynchronous notification of problems or system events to client applications. The JMS specification does not attempt to standardize these messages. This means that clients should not be using these messages to ensure that there are no portability problems when moving from one provider to another.

• Administration API

  JMS does not define an API for administering messaging products.

• Security API

  JMS does not define an API for controlling the privacy and integrity of messages. It also does not specify how digital signatures or keys are distributed to clients. Security is supposed to be a provider feature that needs to be implemented by the provider in their own specific way - which severely limits portability and reusability if coding is required to enable this - and security controlled by the administrator without the need for any standard API.