Recently I have seen too many customers writing their own transaction, thread pooling, role based AuthZ…code when they should have just used COM+ to host their business components.  Just because they are using managed code and they can do database transactions explicitly, they do.  What did COM+ do to be shunned so?  Perhaps it was some of the guidance, that if you don’t need distributed transactions don’t use COM+, that was circling about.  But what about object pooling, role based security, process isolation and component load balancing for free?  Throwing out the baby with the bath water?

Ok, I know that DCOM has its problems, but give it some credit for being mature, transactional, secure and reliable within the datacenter.  Don’t get me wrong, I’m not advocating using DCOM between client and server, but it kind of makes sense between the Service Façade and your business logic within your service.  I know that Indigo will change this, but with compile time (attributes) and deployment/runtime semantics in COM+, there will be a transition path into Indigo.

Check out the following for a performance review of EnterpriseServices and COM+ and decide for yourself…

http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dncomser/html/entsvcperf.asp

This posting is provided "AS IS" with no warranties, and confers no rights.