I was writing a long reply to John Lam's question on the need for Enterprise Services, when I accidentaly pressed Alt-RightArrow on my keyboard. No way I'm gonna write all that again, so here's the core of what I wanted to say:

I agree with John that .NET makes a lot of what COM+ offered unnecessary most of the time. However, there are still some pretty valuable services left in COM+; Distributed transactions (or rather, declarative transactions) are certainly the most important one, but Compensating Resource Managers and Queued Components are two other services I think can be quite useful.

I, too, long for a more .NET-friendly way to take advantage of those services, though. Given the services offered by the .NET platform, such as thread pooling, and the fact that you can do away with the arcane threading models COM imposed on COM+, I think it would be conceivable to write versions of some of the COM+ services, driven by thread- and request- relative contexts, that would fit more naturally within .NET.

OTOH, Clemens has gone and posted a wonderful discourse on the merits of COM+/EnterpriseServices [1]. Something he mentioned resonated within me: "Enterprise Services/COM+ (and J2EE application servers) provide you with such a predictable hosting environment for your Business Logic and Infrastructure Layer components.". He's right, of course. But here's something to think about: Predictable? Yes. Controlled? Yes. The question is: Controlled by who?

[1] I've learned much from our recent discussions. Thank you!


Tomas Restrepo

Software developer located in Colombia.