The Freak Parade

.NET 3.5 SP1 stealthily went RTM yesterday, as I’m sure none of you have noticed. It’s a big, Roly Poly bug of a service pack, and it comes with some nice enhancements to the REST oriented features introduced to WCF in version 3.5. Also included in SP1 is a tangential enhancement to WCF that removes the requirement to decorate DataContracts with WCF attributes.

First, for those of you sexy Web 2.0 Jockeys who could design a textbook REST API with your eyes closed and a pint of Johnny Walker coursing through your veins, I’ve provided a list of resources specifically about implementing REST services using WCF. There are also a few RESTish ASP.NET MVC links sprinkled in the mix, to add a little bit of flava.

Then, for REST neophytes such as myself, there are some resources to help you get your mind around the REST style itself, independent of WCF, which I highly recommend taking the time to do. Just as the use of SOAP Web Services does not magically transform your stinking rats nest of ad hoc, RPC style web services into a Service Oriented Architecture, simple use of XML or JSON over HTTP does not mean you are applying the REST architectural style. Not to imply that a stinking rats nest is bad, or that POX/JSON over HTTP is bad, it just isn’t necessarily RESTful.

None of the links presented here have much interest in the REST vs SOAP debate. There are trillions upon trillions of terabytes of available blather on REST vs SOAP and SOAP vs REST and Soapy REST vs Resting SOAP. If you want help deciding between the two, ask that scary looking guy in the corner there and he’ll show you to the REST vs SOAP room. Um, I would change out of the chaps first. Much better. (I will post one link though, to a podcast by Udi Dahan on the subject, because it is a pretty balanced discussion  and because it is sitting open in my browser and won’t cause me to do any extra typing. Fine, I lied, I’ll also link to an Information Week article about Web Oriented Architecture (WOA) and SOA that piqued my interest in the subject in the first place).

And now buckle up kids, here we go…

RESTful WCF

Zen of the Web Programming Model (Part 1) : Brain.Save()
Kirk Allen Evans’s Blog : Creating RESTful Services Using WCF
Kirk Allen Evans’s Blog : Creating a REST Twitter Client With WCF
More on RESTful Service with WCF and POX/POCO - Johan Danforth’s Blog

Ajax & RESTful WCF

Calling Web Services via AJAX - Part 1
Calling Web Services via AJAX - Part 2
jQuery AJAX calls to a WCF REST Service - Rick Strahl’s Web Log
WCF REST Configuration for ASP.NET AJAX and plain REST Services - Rick Strahl’s Web Log
CoDe Magazine - Article: REST-Based Ajax Services with WCF in .NET 3.5
Return JSON from a RESTful service

Speciality Topics

Dan Rigsby » REST Services and Metadata Endpoints in WCF
WCF, WebHttp Binding, and Authentication

Screencasts

InfoQ: Rob Windsor on WCF with REST, JSON and RSS

Not everyone’s experience with the REST support in WCF 3.5 has been like sucking sugar water from a humming-bird feeder though:

Using WCF for REST, Part 1, Part2 and Part 3. Make sure you read all the comments though, several of the gripes brought up in these posts have been addressed with SP1.

UriTemplate, UriTemplateTable
A must read reference document on MSDN describing in gory details how the UriTemplate works.

RESTful ASP.NET MVC

ASP.NET MVC: Using RESTful Architecture : Rob Conery
MS MVC: Simply Restful Routing | Adam Tybor’s Blog
Creating a RESTful POX Service using the ASP.NET MVC Framework [The .NET Addict's Blog]
Unifying Web "Sites" and Web Services with the ASP.NET MVC Framework | Aaron Lerch
ASP.NET MVC Tip #5 - Submitting an AJAX Form with jQuery - Mike Bosch’s Blog on .NET

This next one isn’t really about REST, but if you’re going to be creating a non-public REST API, you’re going to want to be using SSL as REST, not being a standard like SOAP, doesn’t have cool built-in encryption magic.

Steve Sanderson’s blog » Blog Archive » Adding HTTPS/SSL support to ASP.NET MVC routing

RESTful REST

RESTful Web Services | O’Reilly Media
This is a book by Sam Ruby and Leonard Richardson and is cited by just about every blogger that even has the word REST pop up their comments. And it was reviewed here. I have a copy on order, so I can’t tell you first hand how great it is, but I have read its praises many times today, so I am betting it is a very good place to start. As a bonus, the examples are mostly in Ruby - which I am ashamed to admin I’ve never actually learned to read, but maybe this is a perfect opportunity.

General RESTness
REST for the Rest of Us
REST for the Weary
Plain Old Stan: Understanding REST - a disgrace of Wikipedia definition

RESTful Services
RESTful Service - Ajax Patterns
Building Web Services the REST Way

RESTful API Design
Dustin R. Callaway - Design the REST API
Two Cardinal Sins of REST API Design: Lessons… from the NewsGator REST API
XML.com: How to Create a REST Protocol
Tarlog on Java: How to use SAML with REST Web Services

Have you ever had the experience while learning a new set of technologies in preparation for building a new system that, as your research begins to accumulate and the architecture you are searching for begins to take shape in your head, there remain a few places where your nascent mental framework is “hung up” on some piece of dogma you perceive in the subject matter? You feel intuitively there must be a better way but can’t get past some oft-repeated edict or tenet even though it is getting in the way of a truly elegant design.

This is usually only applicable when you’re new to some way of thinking because hands on experience allows you to brush away these hang-ups like spiders webs; when you have some experience in something you understand the reasons behind the dogma and can ignore it intelligently when appropriate. When you’ve just arrived on the scene you take much of what you are learning as gospel, and how could you do otherwise? Your feet aren’t damp yet, how dare you challenge existing wisdom?

If you’re very lucky then just at the right moment someone will come by and un-hook the string tethering your thought process and everything will fall into place. That, at any rate, is what just happened to me last night. If you aren’t so lucky, it may be enough to at least be aware that if you are studying something new and it just seems awkward or unnatural to you in the environment you have in mind then there is a good chance either the technology you are considering is a poor fit for your scenario or, more likely, you’re taking some piece of guidance too seriously or are misinterpreting some best practice, so ask for help!

For myself, I was relieved of just such a hang up in the wonderful world of messaging. I was under the misconception that because we had chosen an asynchronous, queue based messaging paradigm (nServiceBus) for our inter-service communication that we needed to keep all messaging activity in the system within that paradigm, even when the fit seemed just terrible. Udi Dahan was kind enough to post about that exact topic in his blog last night, setting a critical thought-balloon free and allowing a system design unnaturally warped by an arbitrary constraint to find its natural shape in my mind. Now we can use a nice, clean REST API to power the MVC front end of our application without me feeling filthy and guilty and dreading the moment when we’d have to pay the devil for the transgression. (Thanks Udi!)

Yet another case case of someone walking into my brain, moving a single dendrite from neuron A to neuron B, and suddenly the world is a simpler place. My advice: do not ignore or take for granted these million odd micro-revelations in your career or your life, and each subsequent revelation will come more easily and more frequently.

Ultimately, I imagine we have Seth Godin to thank for all these wonderful, free books. Here is another one - this one is about implementing SOA, and from Joe McKendrick’s description, it is part implementation guide, part inspiration to get started now, not wait for the mythical day when your organization’s blueprints for the Hanging Gardens of Babylon of enterprise architecture are finally complete.

The e-book is available as a free download here, and a print version can be purchased for $20.00 here.

A discussion on the nServiceBus discussion list has been taking place recently regarding how to have durable messaging on remote nodes, such as smart clients, where the deployment and maintenance requirements of MSMQ aren’t tenable. The main concept being tossed around was a local database to hold un-sent messages at the remote endpoint that could be attached to any transport, making any non-durable transport durable. Ayende went off to build a prototype (but hasn’t reported back, so I’m not sure if it is still in progress, although there were strange noises coming out of his blog recently that suggest he might still be working on it) and it was mentioned that Evan Hoff was building such a thing using Berkeley DB.

One advantage of both of those options is that durability could be bolted on to any transport, such as HTTP or one of the non-durable WCF bindings, without much fuss. However there is at least one commercial service that I’ve talked about before, Linxter, that provides an internet-oriented message transport (or Internet Service Bus, ISB) with lots of cool features. What I didn’t realize, until today, was that the Linxter client API does exactly what was discussed at the NSB forum - provides a local cache for messages via an embedded DB (SQLite in this case), essentially enabling an x-copy deployable, durable, asynchronous messaging endpoint.

Of course, it doesn’t have the flexibility to attach “durability” to any conceivable transport - because Linxter is it’s own transport - but in most cases I don’t think that should be a big issue. The only question now, is, how much will it cost? Apparently pricing will be announced with Beta 3, which is scheduled for July 31st. Version 1.0 is scheduled for August 15th.

Here is the e-mail I received from Lixter’s Jason Milgram explaining the local queue:

Yes, the Linxter API queues messages locally (does this in Beta2), and does not take them off the queue until they are delivered. In Beta 3, we will offer additional reliability and efficiency for file transfers by enabling chunking. For example, let’s say you are transferring a 100MB file, and after transmitting 70MBs you lose your connection,…when the connection is re-established, it picks up from where it left off. We felt that these queuing and chunking features were pretty important especially with wireless connectivity becoming the norm.
The ISB is a distributed system, with failover built into the SDK (API)  as well as on the ISB. If the API cannot connect to a service on a particular set of clustered servers, it will failover to another set of servers. We can also dynamically reprovision server and service assignments for programs.

And here is the updated roadmap [emphasis mine]:

Release dates:

• July 31st        Beta 3
• Aug. 15th        Version 1.0

Beta 3 Overview:

• Linxter SDK for both .NET and Java
• Reorganization of methods for on demand and scheduled sending
• Enhancements to Web Manager user interface
• Web Manager support for both IE and Firefox
• Standardization of API local datastore to SQLite
• Availability of Quick Starts - feature based sample apps

On our website we have added the following:

• Linxter ISB implementation options: http://linxter.com/implementation
• The first of several screencasts: http://linxter.com/screencast
• An updated Getting Started guide:  http://www.linxter.com/GetStarted
• A company blog: http://linxter.com/blog

A “getting-started” tutorial on how to get up and running with Simple Service Bus is available here. The guide explains various methods of configuring endpoints, how to define, send and publish messages, how to create and register message handlers, as well as how to setup the endpoint health monitoring system that is part of the framework. Much of what is presented will also apply to nServiceBus, since until you start getting into extensibility SSB hasn’t made many changes, but the syntax and configuration does differ in a number of places, so adjustments would need to be made.

I have posted a comprehensive overview of Simple Service Bus, including an architectural description, in the form of a PDF document available here. A few images from this document are included below.

[UPDATE] A pdf document providing a comprehensive overview of the project is now available here.[/Update]

I have posted a new project on CodePlex, Simple Service Bus. Simple Service Bus is a derivative of Udi Dahan’s nServiceBus, which I’ve mentioned before. I’ll be posting some more extended samples and documentation for using the new library, but first I wanted to document my motivations. nServiceBus is a very solid, very useful, very easy to use piece of software for building asynchronous, messaging based service endpoints, and it’s creator is a well respected SOA guru, at least in .NET circles. I, of course, have no such pedigree, which is why I chose to start with nServiceBus as a foundation rather than starting from scratch.

So what is wrong with nServiceBus that required us to fork it? Well, nothing. My take on nServiceBus and the direction Udi Dahan seems to take the project is that it is a library designed to provide just enough rope to get the job done, but not enough rope for us developers or architects to hang ourselves from a scalability and reliability perspective as we wade into the asynchronous, messaging based waters for the first time. This is a very useful trait for a library to have. However, such an approach comes with some tradeoffs, namely when it comes to extensibility and customization, and I’m a lego brick kind of guy, maybe stemming from control issues, who knows
In service, I believe, of the protective and prescriptive nature of the project, nServiceBus has many of its most interesting parts “soldered to the motherboard” - their implementation is blended in with the default implementation of the framework itself, which means that if you want to customize how certain things work, you have to diverge from the codebase. Now, to be fair, this is only true to a certain extent. nServiceBus has several major pieces that can be swapped out, such as IBus and ITransport, but within the responsibilities of the default implementations of IBus or ITransport are a number of smaller components that can’t easily be customized.

It hardly seems necessary to go so far as to fork the project when custom IBus and ITransport implementations could have accomplished 95% of the flexibility I was going for. And, in reality, it probably wasn’t necessary - but once the thing was already on the operating table, I couldn’t resist making some preference based changes to the IBus API, and I wanted to add custom headers to the message envelope (which crosses between IBus and ITransport) and at that point there really wasn’t any turning back.

Another question would be, well, if nServiceBus didn’t have the extensibility you were after, why not choose Mass Transit? It is extensible. And, in fact, it is - but it is still fairly young, and we’ll be going into production very soon. nServiceBus has been through the fires a few times, and I figured I could add the hooks I needed without altering the fundamental design of how nServiceBus operates, which I quite like and I’ll sleep better at night because of it. My belief, though, that if it was six or eight months from now, Mass Transit would have been the direction I’d have taken. Also, I already had a project, NsbExtensions, that implemented endpoint health & performance monitoring features on top of nServiceBus, and I wanted to be able to reuse all that code.

Here are the design goals of Simple Service Bus - most but not all of which are realized but not thoroughly tested in the version currently posted to CodePlex:

* Small DLL footprint - nServiceBus (for valid architectural reasons) is split up into eleven thousand, two hundred and nine different DLL’s. That may be an exaggeration, but many of the dll’s have only one or two code files in them, with only a few lines of code each. Simple Service Bus comes in three DLL’s for a normal endpoint, and add’s a fourth to implement an Endpoint Health Monitoring Server. Also, required third party dependencies are kept to a minimum (0).

* Custom headers in the Message Envelope - I wanted to be able to attach bits of information that are necessary for the messaging system to function properly, like authentication tokens or endpoint ID’s, without having to include those pieces of irrelevant data on the otherwise domain-oriented messages themselves. This results in a somewhat cleaner set of message contracts, but it also allows you to do some content based routing or authentication checks on a message before the payload ever has to waste the CPU’s time on deserialization. If a message is going to be blocked due to lack of authorization, or re-directed to a different endpoint, or simply written to disk as part of an audit process, there is no need to send the payload through the de-serialization / messaging handling process.

* Send and Receive Pipeline Pattern for Message Processing - instead of having a hard-coded path from Transport through final Handling, Simple Service Bus provides a configurable Pipeline approach, where each interesting step in the messaging processing process is implemented as a pipeline component. This allows programmers to add, for example, a content based message router ahead of the payload deserialization component, or to add a statistics gathering component at various places within the pipeline. Additionally, a rich set of events are fired while a pipeline is processing a message, allowing fine grained performance monitoring or logging if required.

* Replaceable Subsystems - each major concern of the bus has been factored into a simple subsystem as defined by an interface. The default implementation of any subsystem can easily be replaced. For example there is a Message Dispatcher subsystem, a Subscription Manager subsystem, a Message Serialization subsystem, a Message Type to Message Handler Resolution subsystem…etc. In this way, if you want to implement a Subscription Manager that can evaluate publisher-side expressions to determine whether or not to send a message to a particular subscriber using a custom DSL or any other expression evaluator, you can easily swap out the existing subscription manager with your enhanced one. And you can do it for just one endpoint, if only one endpoint needs that special functionality.

* IoC supported, but not required. The building of objects is handled by subsystem as well, and the default implementation can be given a reference to an IoC container to build all objects and services, or it can use simple reflection if no IoC is provided. To accommodate this, a Service Locator was used rather than a pure dependency injection approach, but the services registered with the Service Locator can optionally be built with an IoC. Also, of course, all Message Handlers and Pipeline Components will be constructed on demand using an IoC if provided, or simple reflection otherwise.

* Polymorphic Message Handlers - the default Message Handler Resolution Service allows message handlers to be defined for interfaces or base classes, allowing the creation of message handlers for families or categories of messages rather than just individual messages. This also applies to subscriptions, meaning that an endpoint can, for instance, subscribe to IEventMessage, and receive all messages that implement that interface, instead of being required to subscribe to each concrete message type.

* Endpoint Health & Performance Monitoring built into the core library - all endpoints can be configured to provide status reports to a monitor service with a few lines in the configuration file.

* Simplified Configuration - this is debatable, because Udi Dahan has gone to significant lengths to partition “programmer configuration” from “administrator configuration” - the former being accomplished in code and the latter being accomplished in a configuration file. This is probably a wise, experienced based approach, but I myself like the option to configure everything in a single, simple block of XML, if XML is being used. So that is how Simple Service Bus does configuration, in a more traditional manner.

* Abstract base classes provided for easily creating custom Transports, Pipeline Components, Performance Probes, etc., abstracting much of the ugly details and allowing the system to be extended by overriding a few simple, targeted methods.

* Fully Unit Tested - this isn’t finished yet (I’m still trying to get the hang of TDD, so the tests weren’t written first in this case) but the idea is to have unit tests for each piece of the system, allowing modifications or customizations to be done in a safe, controlled manner.

*object based API. I removed the IMessage marker interface for Simple Service Bus because (perhaps mostly for aesthetic reasons) I wanted our Message Definition dll’s to be as clean and reference free as possible. So now Send, Publish, etc. operate on System.Object rather than IMessage.

And that’s about it. I fell in love with Gregor Hohpe’s “Enterprise Integration Patterns” and wanted to apply those patterns to my own evolving messaging system, so this effort is sort of centered around enabling nServiceBus to accommodate that desire in a clean, plug and play way. We’ll see how it goes.

Similar to BizTalk services, minus the workflow/identity piece but plus a fairly robust security model and web based management dashboard, Linxter(http://www.linxter.com) provides a secure, queued transport for .NET applications. Essentially the service acts as a hosted messaging queue with an extremely simple (in a good way) API and an interesting ability to optionally send file attachments with your messages, which right off the bat gives it an edge over MSMQ over HTTP in my mind. Applications using this API will request registration with a central account on startup and security settings determine if the connection is automatically granted or if an administrator has to manually grant access to your bus to the endpoint. Once access is granted, endpoints (via the Linxter SDK) can send messages and receive messages in either an “on-demand” pull model or an event based push model. The service also supports broadcasting messages to multiple endpoints.

This isn’t something that could act as an ESB, but it could certainly act as a transport for an ESB. The service doesn’t have any pricing announced and the user agreement forbids production or commercial use, but it is something to watch if such a service would be useful to you.

In our case it would be perfect for connecting client systems to our hosted solutions without having to deal with ensuring MSMQ w/HTTP support is properly installed on each endpoint machine, and ensuring the proper queues are set up, etc. Much easier deployment and maintenance for remote nodes not in our firewall. If all your endpoints are inside your firewall, a hosted queuing service may be of little value, but if you have endpoints in the wooly wild, a service like this could be invaluable, taking care of endpoint authorization, identification, and all the rest.

Here is a link to the current stage of development, which appears to be nearing the end of Beta 2

Rob Eamon has offered some compelling, well cited arguments (corrections?) in regards to a previous post of mine describing the image of SOA as a city/society that I selected from among various alternatives to use as a mental model. See the comments of that post for a full record of his take on things.

I can’t help but wonder, though, assuming his understanding is the original understanding, that the original “scope independent” definition he has laid out for the term SOA is mutating or fracturing into a different meaning, or more probably collection of meanings, as the concept is becoming more and more mainstream. Perhaps the mutation, if is real, is fueled by relative “laymen” from such out of the way places as the SMB (such as myself) as we attempt to understand SOA and become practitioners, which perhaps wasn’t common until more recently.

Or perhaps I say that entirely defensively, not wanting to believe I could have missed the mark by such a large margin.

In any case, I certainly have no other option than to concede that I was incorrect in my naive belief that I had found for myself a way of thinking about SOA that, at least in a purely conceptual fashion, could exist at an abstract level above all the tumultuous debate.

Perhaps believing in an image of SOA that encompasses all possible schools is as foolish as believing in an image of god that includes all other religions. I never get used to how much technology feels like religion to me at times.

Maybe things would be more straightforward for everyone if there were named schools of thought one could subscribe to, and then it wouldn’t be so tempting to say “This, well THIS is SOA, and that, well that is something that may resemble SOA(maybe), but in fact it is nothing of the sort.” Rather I could just say “I am a Soascopist” and you could say “I am a Soastylist” and, like religion, an argument about which is right would inevitably continue to rage. But, when the uninitiated like myself walk into a room of people shouting different definitions over each others heads, we would clearly know we needed to pick a school, learn the dogma and start shouting back, or we could state ourselves as agnostics, but we would be less inclined to try and synthesize the “truth” from all of the various contradictory opinions, which turns out to be a rather futile effort.

Then, when the holy war breaks out (and perhaps it already has), the SoaScopists, the SoaStylists and all other various sects of Soaists will take up arms together beneath a common standard and ally themselves against the RPCists. Gifted with superior agility, close strategic and financial alignment with the emperor, and extraordinarily loose coupling, the Soasists will relegate RPC to the level of an outcast technology, kept on life support on the outskirts of the kingdom via a flimsy service adapter, until some data center technician coldly pulls the plug, changes a value in a routing table, and the lights go out for good.

Of course, however it shakes out, we’ll still always prostate ourselves before the dollar, one way or another.

Amen.

(BTW, the holy war is just a joke, not my new personal metaphor for the relationship between SOA and RPC)

I 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

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

Neuron posts from Sam Gentile

NServiceBus - Makes Building Enterprise .NET Systems Easier

http://udidahan.weblogs.us/

Mass Transit author blog

Very brief review of Mass Transit code

Simple Service Bus - Overview & Architectural Description