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.

Here you will find all the information you need to make your Shuttle ESB usage a success.

If you are new to Shuttle:

• What is a service bus?
• What a service bus should not be used for
• Why use a service bus?
• Architectural overview
  • Request / Response
  • Publish / Subscribe
  • Message Distribution
• Processing Pipelines
  • Startup Pipeline
  • Send Message Pipeline
  • Receive Message Pipeline
  • Inbox Message Pipeline
  • Control Inbox Message Pipeline
  • Distributor Pipeline
  • Outbox Pipeline
• Getting started
• WCF and web Services vs. a service bus
• Miscellaneous Configuration Settings
• Full Configuration File Section

Here are some common questions that you may have:

• How does Shuttle ESB know where to send my messages when IServiceBus.Send(message) is called?
  • see Message Routing
• How does Shuttle ESB send messages to subscribers when IServiceBus.Publish(event) is called?
  • see Publishing Messages
• How does Shuttle ESB scale horizontally using message distribution?
  • see Message Distribution
• How can I have a message forwarded to a common endpoint?
  • see Message Forwarding