Home > Architecture, NService Bus, Service Oriented Architecture > NServiceBus Integration Pattern – Part 1

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.

NService Architecure

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 …. 🙂

  1. No comments yet.
  1. April 16, 2012 at 3:55 am
  2. January 27, 2014 at 4:31 am

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: