ESB’s for the Microsoft (.NET) Platform
June 3, 2008I did a pretty exhaustive search for an ESB recently for use on a project that we’re getting underway. FYI, my selection criteria was coming from the point of view of an SMB, so we probably emphasized simplicity and ease of use over scalability and robust governance tools, for instance. Also, cost was a big factor, so the big infrastructure vendors weren’t even on the radar, even though I’m sure they could be used quite easily in a .NET environment.
Anyway, there weren’t all that many options. I guess I wasn’t surprised, but I was a little disappointed. The Java community has half a dozen or more full blown open source ESB projects, many with professional support organizations where you can buy support and consulting if you need it.
In .NET land there wasn’t anything like that. Here is what I found:
BizTalk Server + BizTalk ESB Guidance = ESB ?
Initially I assumed we’d be going down this path, so I read a really great book by Darren Jefford on the subject. BizTalk is a pretty deep piece of software, but like a lot of Microsoft frameworks it aims to be all things to all people, and we wouldn’t need 75% of what it provides and it didn’t offer the simplicity of development, maintenance and deployment I was looking for. The business rules chapter of the book opened up with a warning that the BRE in BizTalk is complicated beyond measure, yet you should learn it because it is powerful. To make it an interpretation of an ESB you apply the ESB guidance put out by Microsoft that I have heard eventually was the jumping off point for Neuron (possibly I made this up in my head), but the guidance exists and seemed to have quite a few moving parts. The installation instructions and prerequisites weren’t a walk in the park, and the whole itinerary based approach isn’t quite what we needed. We were looking for dead simple Send, Receive, Publish, Subscribe semantics in a code based API. BizTalk is a lot of things, but not those things, so the search continued.
Neudesic’s Neuron ESB
Next up we evaluated Neuron. This is really a pretty fantastic product that combines the easy API I was looking for with all the powerful translation, BAM and orchestration of BizTalk (but you need to license both products, I don’t believe Neuron offers these features separately) with a ton of flexibility and some great centralized endpoint configuration mechanisms. From what I gather they pretty much pulled BizTalk apart and exposed the functionality of its pieces (orchestrations, BAM, transformations, adapters, etc) directly via their messaging API and bypassed the MessageBox entirely, which is a pretty slick trick. Without BizTalk, I think Neuron still offers an alternative to orchestrations using integration points with WF and like BizTalk has a pretty good set of legacy systems adapters. Still, even though Neuron is orders of magnitude less expensive than the big dollar enterprise ESB’s, it was still more than we wanted to spend, mostly because our messaging needs were so simple.
Mass Transit
This is a pretty new open source project, currently at version .1. The code is really pretty interesting, there seem to be plenty of extensibility points and the test coverage is very good. Lot’s of moving parts in this one too, but it is a rapidly evolving project. I’ve been keeping an eye on the code as it moves from .1 to .2 and the API is changing rapidly. I think this is definitely worth keeping an eye on, but as of this exact moment in time the API is a bit too volatile, as you would expect in a .1 version. Once it cooks for a while and sees some use I think it will be a nice alternative to the others on this page. Also, they have an NMS transport for integrating with ActiveMQ, although that may not be ready yet.
nServiceBus
This is a relatively mature open source project currently at version 1.8 (RC2 or something) and from accounts has been used in some pretty demanding, large scale production applications. It is a one man show, from what I can tell, run by Udi Dahan, who has given himself the moniker of “The Software Simplist” and I think that shows in his service bus. nServiceBus has the least number of moving parts and it is very easy to understand the entire code base without furrowing your brow. It is trivial to set up endpoints and get them sending, receiving, publishing and subscribing. This is the library we are tentatively using in our project. I wish, at times, it had a few more extensibility points, or were a little more modular, as it comes apart in roughly three or four big pieces. You can replace any of the big pieces, but there isn’t a whole lot of customization or modularization within the pieces. My belief is that Udi Dahan vigorously defends the simplicity of his project and avoids adding what he considers complexity for the sake of extensibility he doesn’t see the value of. By and large I would say nServiceBus codifies a particular approach to service buses and SOA in general and is deliberately designed to enforce that philosophy. Actually, I think the website says something to that effect too. One nice thing about nServiceBus is that Udi Dahan has lots of blog posts and pod casts discussing in articulate detail his SOA philosophy, which if you agree with it will you find direct support for those ideas in the project. The thing comes with a MSMQ transport, but the contrib project has an ActiveMQ transport and it sounds like an HTTP Transport will arrive shortly with a WCF/MSMQ transport coming at some indeterminate time after that. [Update] We’re now using Simple Service Bus, our own derivative of NSB, description below
Simple Service Bus is a derivative (fork) of nServiceBus. Full details on the project can be found here, but the idea was to take the reliability and simple API found in nServiceBus and add in the extensibility and modularity required to enable us to design messaging systems in a more “building block” way, for better or worse. A pdf document providing a comprehensive overview of the project, including an architectural description / diagram, can be downloaded here. The project home page on CodePlex is here.
BizTalk Services
Microsoft is building a SaaS messaging bus with some slick features, orchestrations via WF and more significantly, I think, some sort of federated identity service using (I believe) a standards based STS service. However, it is currently in CTP and is not at all ready for production use (according tot he website). Plus, nobody knows what it will cost. I think it is designed for partner-partner integrations and I’m not sure if it is intended for the Internet Service Bus (ISB, what they are calling BizTalk services) to be a replacement for an Enterprise Service Bus, but perhaps a compliment. Not sure on that one though. In any case, it is worth watching (and possibly playing with if you have time) but not an option for production use just yet.
Linxter ISB
Another ISB in beta, this service is similar ( I think ) to the core purpose of BizTalk services (hosted, secure messaging across the open Internet), with a slightly different feature set. I posted about Linxter here.
That
’s all I could find. Personally, I think there is room for more. Resources below. Links to project/product home pages are in the titles of the products themselves.
Neuron-ESB-vs.-Microsoft-ESB-Guidance-A-Quick-Comparison
NServiceBus – Makes Building Enterprise .NET Systems Easier
- Comments
- View Comments
- Categories
- ESB, NMS, NServiceBus, SOA, WCF
Comments rss
Trackback
Recent Comments