JBoss Messaging provides an open source and standards-based messaging platform that brings enterprise-class messaging to the mass market.
JBoss Messaging implements a high performance, robust messaging core that is designed to support the largest and most heavily utilized SOAs, enterprise service buses (ESBs) and other integration needs ranging from the simplest to the highest demand networks. It will allow you to smoothly distribute your application load across your cluster, intelligently balancing and utilizing each nodes CPU cycles, with no single point of failure, providing a highly scalable and perform-ant clustering implementation. JBoss Messaging includes a JMS front-end to deliver messaging in a standards-based format as well as being designed to be able to support other messaging protocols in the future.
JBoss Messaging will soon become an integral component of the JBoss Enterprise Middleware Suite (JEMS). Currently it is available for embedded use within the JBoss Application Server (JBossAS), and as a JBoss Microkernel-based stand-alone server. Work to integrate JBoss Messaging with the new JBoss Microcontainer is under way.
The large and vibrant JEMS developer community fosters its continued innovation and enterprise quality. JBoss Messaging enables more agile applications in a wide range of scenarios from simple messaging needs to an enterprise-wide messaging foundation and adds flexibility to any SOA initiative.
JBoss Messaging 1.2.GA will become part of both Application Server Platform (JBoss 4.2 series) and Service Integration Platform (JBoss ESB 4 series) as default JMS provider. Production support will be fully available for these plaforms and it will cover JBoss Messaging.
Red Hat is also working on introducing a development support program, which is different from production support and caters to companies who want to have a safety net even from the development phase. The estimated availability date of this support progam is April 2007.
JBoss Messaging provides:
A fully compatible and Sun certified JMS 1.1 implementation, that currently works with a standard JBossAS 4.0.x, 4.2.x and JBoss 5.x installation and also as a JBoss Microkernel-based standalone deployment.
A strong focus on performance, reliability and scalability with high throughput and low latency. JBoss Messaging already exceeds JBoss MQ in a number of measured performance metrics. Full results will follow.
A foundation for JBoss ESB for SOA initiatives; JBoss ESB uses JBoss Messaging as its foundation.
JBoss Messaging consists of two major parts:
JBoss Messaging Core – a transactional, reliable messaging transport system.
Supports generalized messages (not just JMS)
Enables other messaging protocol façades to be added
Distributed, transactional and reliable
JMS Façade – the JMS "personality" of JBoss Messaging.
Other JBoss Messaging features include:
Publish-subscribe and point-to-point messaging models
Topics that feed multiple message queues
Persistent and non-persistent messages
Guaranteed message delivery that ensures that messages arrive once and only once
Transactional and reliable - supporting ACID semantics
Customizable security framework based on JAAS
Fully integrated with JBoss Transactions (formerly known as Arjuna JTA) for full transaction recoverability.
Extensive JMX management interface
Support for most major databases including Oracle, Sybase, MS SQL Server, PostgreSQL and MySQL
HTTP transport
JBoss Messaging 1.2.0.GA Clustering provides the following features:
Distributed queues. Messages sent to a distributed queue while attached to a particular node will be routed to a queue instance on a particular node according to a routing policy.
Distributed topics. Messages sent to a distributed topic while attached at a particular node will be received by subscriptions on other nodes.
Fully reliable message distribution. Once and only once delivery is fully guaranteed. When sending messages to a topic with multiple durable subscriptions across a cluster we guarantee that message reaches all the subscriptions (or none of them in case of failure).
Pluggable routing implementation. The policy for routing messages to a queue is fully pluggable and easily replaceable. The default policy always chooses a queue at the local node if there is one, and if not, it round robins between queues on different nodes.
Intelligent message redistribution policy. Messages are automatically distributed between nodes depending on how fast or slow consumers are on certain nodes. If there are no or slow consumers on a particular queue node, messages will be pulled from that queue to a queue with faster consumers on a different node. The policy is fully pluggable.
Shared durable subscriptions. Consumers can connect to the same durable subscription while attached to different nodes. This allows processing load from durable subscriptions to be distributed across the cluster in a similar way to queues.
High availability and seamless fail-over. If the node you are connected to fails, you will automatically fail over to another node and will not lose any persistent messages. You can carry on with your session seamlessly where you left off. Once and only once delivery of persistent messages is respected at all times.
Message bridge. JBoss Messaging 1.2 contains a message bridge component which enables you to bridge messages between any two JMS1.1 destinations on the same or physical separate locations. (E.g. separated by a WAN)
JBossMQ is the JMS implementation currently shipped within JBossAS. Since JBoss Messaging is JMS 1.1 and JMS 1.0.2b compatible, the JMS code written against JBossMQ will run with JBoss Messaging without any changes.
All the final features are available apart from:
In a very near future, it will be possible to guarantee persistent level reliability guarantee without persistence. By replicating persistent messages between nodes in memory, we can obtain comparable reliability levels to persisting messages to disk, without actually storing them to disk. However, this feature is not available in the 1.2.0.GA release. If you're interested in how this feature will be available, this is the JIRA issue you can use to track it: http://jira.jboss.org/jira/browse/JBMESSAGING-574
The "unreliable link scenario" http://jira.jboss.org/jira/browse/JBMESSAGING-676 whose development is still on-going on a parallel branch.