Would you use EnterpriseServices in a new enterprise development?

Question

As you may already know, managed code (.NET apps) can make use of COM+ through EnterpriseServices, making issues like distributed transactions, resource pooling and synchronization "simpler to program" because the solutions are provided as a supporting infrastructure to the application by COM+.

If your application servers reside in a Windows domain, COM+ "automatically makes your applications more scalable by providing thread pooling, object pooling, and just-in-time object activation. COM+ also helps protect the integrity of your data by providing transaction support, even if a transaction spans multiple databases over a network" (MS source)

So, say you have to build a big application from scratch in a company that has not written COM+ components which you can reuse, so you are not tied to that technology.

This will be a big system, but you know it could get much bigger with time. Let's say it's something like a big ERP, with distributed transactions going on all the time. Finally, let's say that the system core will reside in a Microsoft Windows domain... making the adoption of COM+ through System.EnterpriseServices (ES) a choice. You will have to make some components available to 3rd parties, and you can do so via WCF.

So, knowing this technology is available and that your environment is compatible, would you use it?

If the answer is no, are all the services COM+ offers, like distributed transactions, available and easy to use in a fully managed environment?

Answer 1

I probably wouldn't use EnterpriseServices if you're not already married to COM. I was thinking about a similar problem this morning, and if you have experience with COM, then EnterpriseServices is a godsend. Moving forward I would choose more modern (.NET) infrastructure because

1. It's easier to find developers (and training)
2. 3rd Party software will be focused on .NET
3. MS PSS is more available for .NET development (I know they are not phasing out COM support, but try calling for two different issues and time the response)

Answer 2

No.

We had no end of issues (mainly unresolvable memory leaks in COM+ - caused by various COM+ interop bits we couldn't affect) when we went with .Net in COM+. We changed to WCFServices exposing business layer functionality and kept our distributed transactions to a minimum (i.e. The transaction is complete inside the WCF service - The only way you can do it really). Using the built in .Net Transaction stuff handles everything we needed to handle transactionwise.

I would stick with various WCF service layers to expose functionality. Keep one layer internal and provide exposed services on an external layer that communicates with the internal layer. It's a bit heavy but seems to scale well later and provides the security you'd expect (and require).