Why you want to use Enterprise Services for your .NET applicationPart 1: Introduction
Yesterday I did a 4.5 hour talk about the relevance and basics of Enterprise Services here at TornadoCamp.NET. In our audience we have about 90% developers who have been using mostly VB6/VB5 up until now and more than half are writing "classic" client/server applications with (very) fat clients and the only server-side actions happening inside SQL Server, Oracle, Sybase by way of stored procedures. What I've found here is consistent with what I find at our other workshops and very many other events where I speak: Only very few developers really ever used COM+ or MTS for anything but server-side transaction handling and the majority didn't even look at Enterprise Services/COM+/MTS ever, at all.
Why that is the case is easily explained and there are two primary reasons:
(a) Visual Basic 6 (and previous versions) is the most popular language for writing business applications on Windows, at least with our customers and the people I usually talk to at conferences and events. COM+ provides quite a few very useful features, which either can't be used from within the VB's "STA ghetto" due to its inability to produce thread-safe code (like ObjectPooling) or which are very difficult to deploy without rather complex installation scripts (like "loosely coupled events") .
(b) The main reason is a different one: COM+ provides the implementation of a lot of common architectural patterns and solutions to very typical functional challenges. If I either don't understand these patterns or, more often, don't see an obvious mapping of such a functional challenge that I find in my project to a feature provided by COM+, I simply won't use it. The dilemma: If you don't really know what's in COM+ feature bag, you won't be able to find out why you'd ever want to consider using it. If you have no interest in COM+, you will not buy a book on it. For most developers, all feature areas of COM+ beyond "Transaction.Required" therefore remain in the dark.
So, instead of blogging random Enterprise Services features out-of-context (such as CoRegisterSurrogateEx), I will try to illustrate the "why" and use-cases for several (best:all) Enterprise Services/COM+ services in a very compact, blog compatible form, which will hopefully create a context for the other obscure things I am typically writing about and will allow more people to see why this stuff is very relevant for their apps.
Next installment: Part 2: Basic Architectural Considerations and the benefits of Processes and Process Models