This project is read-only.

Reactor Service Bus

Reactor Service Bus is a light weight .Net service bus built upon the Apache NMS messaging API. It provides a rich subscription model and built in load balancing features for consumers.

The Reactor Service Bus isn't just another .Net service bus. Although it provides a similar programming interface to other .Net service bus frameworks on the market, it’s built upon the Apache .Net Messaging API, which allows Reactor Service Bus to connect to multiple providers or transports using a single API. NMS is modeled to implement the JMS specification, which provides powerful features not found in non-JMS based messaging brokers.

Currently, Reactor Service Bus can integrate with the following transports:



Reactor Service Bus uses standard messaging transactions to handle failures. If the handling of an incoming message fails, the bus places the message back on the queue from which it was delivered. To avoid “flip-flop” delivery, a configurable maximum number of deliveries is evaluated each time the message fails. Once this maximum number of deliveries is met, the message is placed in the dead letter queue for later intervention and processing.

Easy Configuration

Although Reactor Service Bus contains many extension points, it is easily configured through a succinct configuration API and conventional application configuration. Reactor Service Bus is container-agnostic and provides the following 5 adapters to integrate IoC containers for it's use:

Read more about how to use the adapters in the Containers section of our documentation.

Simplified Programming Model

The standard JMS programming model can be cumbersome. Imagine writing ADO.Net "plumbing" code to access all of your data. While easy to use, certain pieces of plumbing, such as connections are better abstracted. Reactor Service Bus uses a programming model similar to other .Net service bus frameworks on the market. Creating message handlers that either listen to queues or topics is as easy as implementing a simple interface and decorating the class with attributes that declaratively specify what queue or topic the message is expected on.

Messaging Patterns

Common messaging patterns such as publish/subscribe and request/reply are implemented naturally from the broker up because of our use of proven standards and conventions. Additional patterns can be implemented easily by extending the framework or through features exposed by certain message brokers, such as Fuse and ActiveMQ (see broker links above).


In enterprise test environments, Reactor Service Bus has moved over a million messages a day with ease.


The framework was built with ultimate scalability in mind. Since it utilizes brokers that implement the JMS specification, load balancing of services is done simply by having the load balanced services take input from the same queue. The specification dictates that JMS brokers must deliver messages in a round-robin fashion. Should the broker become the bottleneck, it can be clustered to handle the additional load and fail over scenarios.



* - Preferred Broker:

Fuse Message Broker delivers large amounts of data efficiently and reliably. Performance testing has shown that Fuse Message Broker exhibits the highest performance of any open source messaging platform, and has clustering and failover to ensure high availability.

Fuse Message Broker supports JMS 1.1 and many integration-related standards including JDBC, JCA, and EJBs; dependent specifications such as JTA and JNDI; as well as AJAX, REST, HTTP, TCP, SSL, NIO, UDP, multicast, JGroups and JXTA transport protocols.

Last edited Feb 22, 2011 at 7:23 PM by akilhoffer, version 1


No comments yet.