After playing with MT I have noticed that there is a distinct lack of entry level documentation that may put developers that are not up to the calibre or the uber nerd* MT members. so i have offered to attempt to document or at least given some guidance to help people get into it.
So i am going to start from the very start and try to aim a t a n intermediate level .net that is comfortable with web service and distributed communication etc but may be a bit hazy of what exactly terms like SOA, ESB and Asynchronous Durable Messaging mean.. ;)
*Chris, Dru and Greg and i mean nerd in the good "I am not worthy" sense
I plan to do some basic "This is what this does" type posts too, so there is some step by step articles to get people up and running fast, but for starters here is the proposed initial doc:
The official synopsis of MassTransit, from its website is as follows:
"MassTransit is lean service bus implementation for building loosely coupled applications using the .NET framework.
The lean implementation is supported by the YAGNI principle. By focusing on a tight set of specific concerns, the touch points between Mass Transit and the application are minimized resulting in a clear and concise set of interfaces."
But what does it actually do?
Well as the brief states MassTransit is a service bus for building loosely coupled applications. Let’s break that down.
So what is a service bus and how does it aid in loose coupling? Well hopefully the follow example may help you understand:
You may have 1 or more systems/components communicating with out any real knowledge of who or what each systems/components is. For example if I what to Create a New Purchase Order for a client I may send a specific message, for example a message called "CreateNewPurchaseOrderRequest" (with the company and order details inside that message) MassTransit picks up this message and forwards on to which ever system(s) is registered to deal with that type of message. Now my sending component does not know or care which system receives and deals with that message, it has done its job of raising the purchase order.
Ideally there is another system that is ready to deal with that type of message. It is given the message from the buses queue and the service processes the data in the message; persisting, starting workflows etc. It may even send a message back to the bus, say a "CreateNewPurchaseOrderResponse", to acknowledge that, yes, the purchase order has been successfully created. The original sender of the CreateNewPurchaseOrderRequest may (or may not) be interested in this response and can subscribe to the message type and act on it accordingly.
What this does require is that the bus is alerted of who wants to receive what type of messages and also that when a message is created and ready to be sent, it is passed to the bus.
Now this scenario raises a bunch of questions
Why not use method calls/web services?
• A service bus like MassTransit allows you to send and forget. You give the bus a message and let the bus decide where to send the message. This means you do not need to know that HR is now looking after message X and the Logistic is dealing with message Y differently. You don’t care. You also don’t need references to those other systems. Changes to other systems are much less likely to affect your system.
Why the ignorance?
• What happens if the business now decides that when we raise a Purchase Order we also need to alert Logistics, Warehousing, Marketing and the original Sales department? If you where using traditional web services this means you would need to go into you code add references to those web services and make class to them from the raising application. With a service bus you raise the message and let the the bus forward the message on t the interested parties. It means the component focuses on the job it is supposed to do and not worry about departmental interactions. This concern is now that of the Bus
Why messages?
• As business and their technical solution grow, maintaining those technical solutions can become difficult. Architects have been using SOA approaches to help delineate logical service and use messages as the means of moving data around. A message in itself guides the bus to what its intended purpose is. A CreateNewPurchaseOrderRequest is quite self explanatory and very specific. Well constructed messages and services means disparate components can talk to each other, showing their intention but hiding the implementation.
Benefits of MassTransit
• Loose coupling/Recipient ignorance: Send and forget. In the same vein you can subscribe to a message type and not care where it was sent from.
• Asynchronous communication: no need to hold up connections and thread waiting for replies. You can send the request and if you are interested in the response subscribe to the message type
• Durable and reliable messaging thanks to the message queue backbone (e.g. MSMQ)
• Light weight : MassTransit.ServiceBus.dll, MassTransit.ServiceBus.MSMQ.dll & MassTransit.WindsorIntegration.dll combined are under 100KB
• .Net Type safe. You can subscribe to message based on the .net type of the message. No need to interrogate XML files or manually transform .net types to xml etc
• Castle integration: The stack is built using best practices such as IoC and is ready to integrate with the popular .net Library “Castle”
• Open Source: The source code, including unit tests and samples, are available openly.
Who would want to use MassTransit?
• A designer or developer who’s systems are predominantly in .Net realm.
• A designer or developer that wants to have a means to communicate to separate systems in a loosely coupled and possibly asynchronously manner
• A designer or developer that wants to have a reliable and durable means of communication
• A designer or developer that wants to have an easy means to set up a messaging bus!
What does this require of the developer?
• You will need a supported Messaging Implementation such as MSMQ
• You will need to base your communication on a message construct i.e. each message has a specific intent and relevant data. Passing entities is not explicit enough as it does not show intent.
• You will need to reference MassTransit and use the library accordingly! (see the samples for more info)
I hope this gives some basic back grounds as to what MassTransit is and does. Any question please email me or for technical issues go here
Subscribe to:
Post Comments (Atom)
2 comments:
Thanks for writing this up, it really helps explain the intent of MassTransit. It was especially helpful to see it explicitly called out that this is a .NET-centric solution. That is, that if you have some development teams writing apps for your service bus that don't want to write .NET code, this isn't an optimal solution.
No worries Peter,
I hopes it helps either using the ESB or in the descion to implement an ESB. If you are interested in .Net based lightweight ESBs then be sure to keep and eye on MT as Chris and Dru have updated quite alot of the components since this article was written. Also look at Udi's NServiceBus and Ayendes RhinoServiceBus in his RhinoCommons library. Both have extensive blog postings about not only their ESB but SOA associated stuff too.
Rhys
Post a Comment