Novell exteNd Messaging Platform's JMS is a high-performance and scalable implementation of the Java Message Service (JMS), an API for accessing messaging middleware using Java. JMS allows distributed Java applications to exchange data is a loosely coupled and reliable way. All features from the JMS specification are supported:
Also, several value-added features are supported:
Novell exteNd Messaging Platform's JMS provides high performance and scalability for both transient and persistent messages. It uses sophisticated buffering techniques to reduce latency resulting from database and network I/O bottlenecks. The result is unparalleled message throughput in all situations, including transacted sessions.
Novell exteNd Messaging Platform's JMS leverages enterprise class IIOP support in the Novell exteNd Messaging Platform's ORB, which provides a robust and proven engine for communication between client and server applications. In addition to a standards-based communication protocol, the ORB provides dynamic management of network connections.
To balance the incoming message rate against available system resources and the rate at which messages are consumed, the Novell exteNd Messaging Platform's JMS applies flow control to throttle producer applications. Also, the JMS server can be configured to use memory management techniques and page out infrequently accessed messages.
The JMS cluster provides fault-tolerance and load balancing, which makes it easier to develop robust and scalable applications. All topics are available on any server in a cluster, while queues are always bound to one server. Client applications can send or receive messages using any server in the cluster. The JMS cluster provides these fault-tolerance benefits with almost the same message semantics as when using a single messaging server.
A client application that only contains message producers will automatically and transparently fail-over to any available server if the server it uses fails. The server that receives a message from the producer will forward it to all other servers in the cluster (for topics), or to the server which hosts the queue where the message is designated. Since producer applications can be configured to use different primary and secondary servers, load balancing can be achived.
Consumer applications do not have transparent fail-over since automatic reconnection to another server could potentially result in message loss or message duplication. However, consumes have connect time fault-tolerance similar to producers. Consumers that are less sensitive to message loss or message duplication can use the exception listener to detect a server crash and manually reconnect to another server in the cluster.
Several databases are supported for storing persistent state, including persistent messages. A message store is required for guaranteed delivery of messages in case of hardware or software failures. The following databases are supported:
The JMS server futher supports a file store as well as a memory store. This is useful for systems where no database is available, or where other mechanisms are used to handle failures.
The Novell exteNd Messaging Platform's JMS has an extensive set of features:
Operating Systems:
System Requirements: