NServiceBus: The Magic of Generic Host

I have done a few posts on NServiceBus and have talked in great details about how it works with messages and MSMQ. However I haven’t talked much about the Generic Host and today’s post is just about that.And hope you will find quite amazing and valuable for your SOA development.

As you had seen in my previous post that it is a means to host your NServiceBus application, whether it’s the client sending a message to the bus or the server reading the message from the queue they both are assemblies and are hosted in this executable called the “Generic Host Process” for NServiceBusIt is this host which takes of wiring up messages, handler and endpoints to MSMQ etc.

When we run the generic host using command line we can see some interesting options as shown below.

This means that you can configure any message endpoint as a Windows Service and Generic host will take care of installation. You don’t have to do a windows service host application, installer etc. All the plumbing and hard work is taken care by the generic host and you have to focus on writing your messages,message handlers and endpoints.

Let’s try installing the server component in the Full-Duplex sample as a windows service.

The Command Line:

NServiceBus.Host.exe /install /serviceName:MyServer.dll 
/displayName:"My Super Duper service" 
/description:"My server installed by NService Magic"

As you can see the command line is very self-explanatory, we have an assembly called MyServer.dll which implements a handler of a specific type and we want it’s display name to be My Super Duper Service and the description to be My server installed by NService Magic.

Lets verify this by opening the Windows Service Management Console and we can see our NServiceBus Server component installed as a windows service. When i did this for the first time it was not less than a magic.

To test whether it is doing what it is supposed to do I am going to run the Client only project from Visual Studio and our message gets picked by the windows service and our handler processes it successfully.

That’s it for now and I hope you guys will find a lot of value in using NServiceBus

NServiceBus Integration Pattern – Part 2

Continuing with my previous post on NServiceBus in this part I am going to implement what we had discuss about integration and how NServiceBus can be used. Based on the previous architecture diagram I am doing to drill into component architecture and for easy illustration I am going to use the FullDuplex example which is part of the samples provided by NServiceBus.

And let’s see how it looks from the visual studio.

And when we look into the project properties you can see that the project type is an output library and it is configured to run with an external program which is the NServiceBus.Host.exe.

So let’s run a typical failover / offline scenario and run the client application in isolation

and as you can see in the above diagram that the client can send messages even if the server is not running.

Let’s run the server application with debugging and mimic as if there is a failure. For example the finance system is down, exchange server in unavailable or any system to system integration failure. So in this scenario when we run the server application we see this exception thrown and seen like this in the console window.

Interesting thing is that if you have a break point in the server application set correctly you will see that the code gets retried 5 times before the exception is shown in the console.
This happens due to the fact that the server application is configured to use transactional queues and in the config file it has been configured to retry 5 times.

Upon close inspection of error queue this is what it looks like

And when we click to open the message you will see this is how the message looks like.

Next thing we have to do is fix the problem and whether the problem was due to hardware, software infrastructure failures let’s pretend those problems are resolved. So now what we have to do is put the message(s) back into where they belong and run our server component and there is exactly a tool called “ReturnedToSourceQueue” in the tools folder.Let’s run the tool.

This first thing you have to enter is the name of your error queue and after that you can specify a specific message with the Guid or all of it. For demonstration sake I’ll specify the keyword ‘all’ and you will see the message gets disappeared from the error queue and reappears in the server input queue.

and the message reappears in the input queue.

And now when we run our server component you will see the message gets processed.

As you can see we can fine tune and design these components to integrated different integration points and have that failover/durability scenario taken care by NServiceBus, we can take the message and transform into different type and let the handler of the new type take care of it.

For example our FinanceMessageHandler talks to the Finance system and processes the order if it fails to do so the order remains in the error. We don’t have to hack into some database or ask user to reenter the order. As soon as we resolved the Finance system failure/downtime the message will be processed successfully.On succesfully processing of this business process we can transform the message into an Email message and puts it into EmailQueue.

Now our EmailMessageHandler picks up the message and tries to process and if it encounters any problem with the mail server the message gets routed to the error queue that’s it. This is like creating a messaging eco-system where each system talks to each other in terms of a message and we are building this orchestration.This is what I meant by “Pass the Parcel (message)” pattern in my previous post.

That’s it for now and in my next post I am going to talk about the Generic host and what wonders it can create for your enterprise.

NServiceBus Integration Pattern – Part 1

A couple of months ago I gave this NServiceBus integration presentation/walk through to my colleagues and thought about blogging it but for some unforeseen circumstances I couldn’t and today here I am with the presentation.

If you have no idea of what NServiceBus please read my previous post here.

Coming to the point straight lets start with an architecture diagram.

So the idea behind this architecture is that we will be building services which listens for a particular message and based on the message and it’s content it interact/performs an atomic operation and on completion forwards new message back into the queue.

For example in my project the “System A” is a finance system and as a result of an online financial transaction the “Message A” gets written to our Queue.As part of our NService infrastructure this message gets automatically picked by a handler, as in NService Universe for every message there has to be handler and each of these service interaction happens through a message.(We will see these handlers and message code in the second part)

Once our service has accomplished the task it simply writes a new message say “Message B” and it’s job is finished. In my case the “System B” is an enterprise wide emailing system and as soon as it gets an acknowledgement that Finance system operation is completed we are ready to send some emails and do some more interaction with other systems.

For me this is the core of designing integration system and what we are seeing here is that these services are autonomous and has no dependency on each other or the other systems.

For example if the online order submitted by a user is successful and the message gets written to the “Finance Queue” and at that time if the finance system is down still we don’t have any problems as the service will fail to perform its operation and the message will be sitting in the “Error Queue”, then as soon as Finance system is up and running we move the message from error queue to its processing queue and our job is done .

After this if for instance the Email system is down due routine updates , system failure etc still our message is sitting in the error queue and it’s going nowhere. This is exactly what one of the four tenets of Service Oriented Architecture is…

• Boundaries are explicit
• Services are autonomous
• Services share schema and contract, not class
• Service compatibility is based on policy

This is what I call as “pass the parcel” (Message) and MSMQ and NServiceBus will take care of all the infrastructure work. I don’t have to think about transactions failure and how to overcome them in case of catastrophic failures, as an architect my main job is to focus on business needs and how best to implement them.

This concludes the first part of it and I guess with this I have given you some context to the so-called “SOA” and how we can design our “SOA”, I know I didn’t cover anything substantial about NServiceBus but at times some architecture principle and theory are important before we can build the architecture.

Part 2 follow soon ….

Getting started with NServiceBus

In this post I am going to give a quick introduction into NServiceBus and how this can change the way you think or design distributed application for an enterprise.

Before we get into specifics of NServiceBus lets see what is an Enterprise Service bus and how does it fits into the realm of an enterprise. So the Wikipedia definition is

   An enterprise service bus (ESB) is a software architecture model used for designing and    implementing the interaction and communication between mutually interacting software    applications in Service Oriented Architecture. As a software architecture model for    distributed computing it is a specialty variant of the more general client-server software    architecture model and promotes strictly asynchronous message oriented design for    communication and interaction between applications. Its primary use is in Enterprise    Application Integration of heterogeneous and complex landscapes.

So here are some of the key features of NServiceBus :-

• It’s not a centralized broker like BizTalk or IBM Websphere Message Broker
• It’s not a Service Communication Framework like WCF.
• Build on top of MSMQ.
• Focuses on messaging and publish/subscribe model.
• It’s very robust and reliable
• There is no synchronous communication
• The Community Edition of NServiceBus is absolutely free and can handle up to 30 messages/sec which comes out to be around 2.59 million message a day on a decent quad-core server machine.
• The licensed version of NService is merely $2000 per license and can handle 100 messages/sec or 86.4 million messages.
• Highly extensible
• Written by the software simplest the great Udi Dahan.

Okay that’s was like the product overview but if you are like me, you might be itching to go ahead and use this stuff. So here is how you can jump into the NServiceBus wagon (oops the pun ).

• Go to http://nservicebus.com
• Click on “Download v2.5 SP1″
• Unzip the file and run RunMeFirst.bat as an admin
• Install or configure MSMQ
• Go to the samples folder and open the Full Duplex project

Just to get a feel of what the project structure looks so here it.

As you can see the project structure is self-explanatory, there is a client and a server and client is going to send a message and the server will take process the message and return it back to client.Lets run the project and see what happens.

and as you can see in the above figure that client and server are launched and ready to exchange messages. Lets hit enter in the Client console window and you will see the message gets send to the server with a Guid, which is received by the server and server sends back the message back to the client.

So till now nothing special but it’s time to go deeper and start tinkering with NServiceBus to understand some more. What I’ll now do is from the solution this time I’ll run only the client and not the server to mimic “a real life distributed application with reliable messaging” kind of scenario. So lets run the client project in isolation.

and we see that the client console windows gets launched and let hit enter to send a message to the service.So this is how it looks when we do that.

Now we will look how this message gets routed by NServiceBus. Lets open MSMQ and see where this message is routed and stored in MSMQ.

If you remember from the client console window that a message with a guid 3e8eeb98-0130-429a-862c-a56f5a02d95b but the message id in the server queue is something different and you must be wondering about this mismatch.

Lets open the message and see what’s in there.

So here in the message you can see the Data Id which matches the guid and this is how the server can correlated the incoming messaging and outgoing message to the client.

Now lets run the solution again and see how the NServiceBus will pick up the message process it and send it back to client and client will display the returned message from the server.

Viola !!! We see the NServiceBus picks up the message and processes it and return the message back to client and the client receives the processed message.If at this point you open the MSMQ and you will see that the message has been processed from the Server Queue and since the client has received the message the message disappears from the client queue. This is a good project to understand the core of NServiceBus and getting started with it.

One of thing I like about NServiceBus is the documentation is superb and all the sample projects are really good to understand. Hopefully I will able to bring more real-life & complex implementation of NServiceBus as I go my implementing in my current project.Till then …..

Enjoy !!!