Please note that this project has been moved over to GitHub

Why a service bus?

If you need to have a task performed you send a command message:
  • A command message goes to only one endpoint that processes the message by interacting with your domain.
  • If you need to have the command message performed from outside your application space such as from another application or across the Internet from a thrid-party then expose some integration layer that sends the message on your side.

When something interesting happens in your domain / application that another system may be interested in the publish an event message:
  • There may be anything from no subscribers to N subscribers.

You get queued messages so that your system is not overwhelmed by a sudden burst of messages.

You also get automatic retries should the processing of a message fail.

Once you start using a service bus you will wonder why you ever worked without one.

Project Description

This project aims to provide a free open-source enterprise service bus.

Some quick information:
  • C#
  • Core has no dependancies on third-party components
  • Supports msmq (production-ready) and sql server table-based queues (not for production) out-of-the-box
  • Supports command and event message (publish/subscribe)
  • You can download Shuttle from CodePlex or install using NuGet (excludes the management shell)

Windows management environment

A plug-in based architecture used to manage various components within the service bus deployment.



View messages in queues and delete or move them to another queue. For instance, messages in an error queue can be returned to their source queue.

All data in the message is displayed in a hierarchical manner so that a message may be investigated and, for example, failure messages viewed.


Add or remove subscriptions. This entails having event message types sent to a particular inbox work queue.


Subscription requests

Accept or decline subscription requests. When using the secure subscription manager all automatic subscriptions are registered as requests.



You can set up scheduled messages. These are then sent to the configured endpoint at times satisfied by a CRON expression. Since you already have handlers defined that responds to a messages you simply add a handler for the ScheduleDueMessage message and send your actual message to the local uri. For instance, you may have a handler for your SendNotificationsCommand but you require notifications to be processed twice a day. The scheduler service will then send a ScheduleDueMessage to the same endpoint uri handling the SendNotificationsCommand message but simply does a SendLocal(new*SendNotificationsCommand()).

So you get enterprise scheduling for free straight off the bat:


Pipeline-based processing

Shuttle makes use of event-based pipelines for:
  • Sending messages
  • Receiving / handling messages
  • Outbox processing
  • Distributor processing
  • Service bus startup

You can even add your own event anywhere in the pipeline. Various observers handle these events so you can add an observer to any event:



With the involvement of the developer community we can make this software a success.

To get you going have a look at the readme.txt in the root folder.

Last edited Mar 29 at 1:59 PM by jabberwocky, version 41