Conquering NServiceBus part 1 – Getting Started

This post is part of a series:

1. Conquering NServiceBus part 1 – Getting Started
2. Conquering NServiceBus part 2 – Initial configuration
3. Conquering NServiceBus part 3 – A simple Saga
4. Conquering NServiceBus part 4 – Testing
5. Conquering NServiceBus part 5 – Troubleshooting DTC

Before we get started with coding there are a whole new language with terminology to learn so let’s start there.

• Enterprise Service Bus – http://en.wikipedia.org/wiki/Enterprise_service_bus
• NServiceBus  – What you use to build an ESB
• MSMQ – Microsoft Message Queuing used by NServiceBus as transport system
• (IoC) Container – used to inject dependencies when needed. You get to chose your favorite one to work with (mine is StructureMap)
• Unicast Bus – The messaging system that NServiceBus ships with. (Currently the only one that works to my knowledge).
• Serialization – http://en.wikipedia.org/wiki/Serialization  XmlSerialization based on interfaces preferred for performance. NServiceBus ships with BinarySerialization and XmlSerialization. You can also easily create your own Serializer and use.
• Subscription – NServiceBus makes publish/subscribe extremely easy. You can tell your message handler to subscribe to a certain type of message.
• Message Handler – The actual handler of a given message (implementation detail goes inside the handle method)
• Endpoint Config – The programmatic way of initializing a “bus”.
• Saga – Long running process with the need for temporary storage before the final result can be processed.
• Profile – When installing your service you can explicitly tell it to handle only a certain profile which is good if you have multiple environments and want different settings on different machines.

Let’s start from the beginning. I know from start I have a long running process where the client will be generating a lot of hits on a WCF REST service. The exchange will not be data heavy but it will be many requests at a time. That’s why I want to use NServiceBus and the Saga functionality. I also want to invalidate the saga after a given time, something that is supported by the Saga. When the saga completes I want to do expensive (time consuming) work and there for I don’t want the saga to do this which means I need to pass the whole thing on to another sort of service with main purpose of doing this heavy work. That means I can focus on threading and what not in one place only should I ever need to and it will also be extremely easy to measure performance of the various parts of the system and at the same time it will allow me to scale out pretty easily.

Question is, where do I start? Some of you might consider starting with writing tests. Myself I have no idea what kind of tests to write yet or how the application should be created. All I can do now is to try and get the high-level parts of me brain to cooperate with the low-level parts.