Harry Pierson posted a response to a comment I said in a previous entry about SQL Server Service Broker. Lots of interesting stuff to consider, but let me address some of the points Harry made right away.
First of all, it seems Harry made quite a bit of assumptions about what I meant from a very short sentence :-). Let me be clear to say that I never stated that SSBS only supports code completely in the database. I said that's what I considered a good match for SSBS applications. This is obviously just an opinion, and Harry can feel free to disagree.
Also, I never mentioned the DTC in any of my comments and for the record, I don't have any issues with using the DTC (and in fact have used it extensively and very successfully in several solutions). I also don't get the whole "purely database driven" rant from Harry. In my case, I used the term "database driven" to mean something very specific: A case where most of the work is basically database code to manipulate data, instead of complex business logic. Perhaps Harry understood it as "accesses a database", which I would agree 99% of applications out there do, but that's a different thing to me.
What I don't get is the whole "Two types of service architects" question. To me, there's really no question here. There are scenarios that call for request/response services, scenarios that call for one-way asynchronous services and scenarios that call for two-way asynchronous services. A good architect will choose the right style for the right scenario. Í do wish Harry would clarify exactly what he means by "long running service", as the term seems rather disconnected to me.
I'm going to venture here that what Harry calls "Long running services" are really just a specific case of "Long running processes". Certainly SSBS poses some very interesting infrastructure for writing those, but, to a certain degree I personally feel that for many tasks it is too low level (just like pure MSMQ is for many tasks). If you really are writing long running, asinchronous processes, then having a queuing mechanism is just part of the equation; there are far many other issues to be considered. And, frankly, as a developer writing business solutions, I'd much rather have someone put that infrastructure in place for me rather than having to do so myself (even though doing so is rather fun). Both WF and BizTalk put a lot of that other infrastructure in place for you (each with their ups and downs), btw.
But, maybe I'm just an idiot and don't see it, so feel free to hit me with the enlightment stick some more if you think so :-)
Technorati: Architecture, Service, SOA, SSBS
