Simple Service Bus is an asynchronous messaging
framework that enables the rapid construction and customization of messaging endpoints, allowing services and applications to interact with one another across the network in a fault tolerant, robust environment that is less susceptible to network volatility than traditional synchronous approaches to distributed systems. SSB can be used as a message bus in an SOA, or simply as an integration tool enabling reliable cross process communication among distributed software components.Simple Service Bus Overview.pdfGetting Started with Simple Service Bus.pdf
Simple Service Bus is a fork of Udi Dahan's open source ESB nServiceBus http://www.nservicebus.com
. The basic principles of nServiceBus are left in place, but the lifecycle of a message from when it enters an endpoint until fully processed or, the reverse, from when a message is sent by an endpoint until it is actually transmitted, has been modularized into customizable, replaceable building blocks, allowing custom implementations of message serialization, subscription handling and dispatching, message -> message handler resolution, etc. A simple pipeline architecture has been added to the Message Bus to abstract the various stages of processing a message goes through when it is sent or received by and endpoint, providing virtually limitless flexibility in message handling. I explain the motivations for this project in detail here
Simple Service Bus is supported by a full suite of unit tests and includes a comprehensive set of samples to demonstrate the various messaging patterns exposed by the API as well as the Endpoint Health & Performance Monitoring
features built into the framework.
Currently, Simple Service Bus supports the following features:
- Preserves the simple Send,Receive,Publish,Subscribe semantics of nServiceBus
- System.Object based signatures on the Message Bus API - message types are not required to implement a marker interface, such as IMessage, allowing message DLL's to remain free of external references
- Pipeline based message processing archiecture, allowing custom fowarding, message recording, performance logging, dynamic routing components, etc. to be plugged in either pre-message-deserialization or post-message-deserialization.
- No requirement for an IoC container (although they are supported). Instead a Service Locator is used, allowing simple code based replacement of any subsystem, in case your project isn't using an IoC.
- Flexible Message Type -> Message Handler mapping that allows message handlers to be defined for interfaces or base classes at any level in a message hierarchy. This means you can write handlers OR subscribe to families or categories of messages, instead of having to write handlers or subscriptions for individual message types.
- Centralized endpoint health and performance monitoring is built into the core library
- Small DLL footprint - most functionality is included in the core dll. Additional DLL's impelment a specific transport and the collection of system messages.
- Abstract base classes are provided where appropriate to allow easy, targeted implementation of extensions or custom pipeline components, performance probes, transports, etc.
- Message Envelope allows for custom headers to be added to the message that are serialized and deserialized separately from the message, allowing infrastructure items like authentication tokens or data useful for routing a message to be kept separate from the domain oriented business messages.
- MSMQ Transport included. ActiveMQ, HTTP and possibly other transports may be added in the future. A TransportBase class makes implementing custom transports trivial.