COM+/Enterprise Service Components are not a legacy technology

I am a firm believer in the use of component based development, and for the middle tier, Enterprise Services is the right way to go for most serious applications. Unfortunately there are a lot of misconceptions about the positioning of Enterprise Services, aka Serviced Components, aka COM+ with respect to .NET development. The biggest of these is viewing COM+ development with .NET as a legacy approach. Another is that when you build COM+ components with .NET, you are doing COM interop. Another is that COM+ is too hard to be worth it. All of these are just wrong.

To really get things in perspective, you have to think of COM+ as what it really is – component services provided by the operating system. In the same way that you use the OS for services such as file and network I/O and access control, when you use COM+, you are really just using component services provided by the OS. So doing COM+ in .NET is no more “legacy” than doing file I/O or network calls using .NET. In fact it is much less so because the level of abstraction and architecture provided by COM+ is far more advanced than those other services provided by the OS. When Microsoft put together COM+, they put together a very forward looking architecture for building robust, scalable, high performance applications.

Building Enterprise Service components is also the best thing you could be doing today to migrate to Indigo tomorrow. Most of the hype surrounding Indigo (and well, just about everything in the last couple years) is about Web Services. And yes, one of the primary scenarios for using Indigo will be to build service oriented applications that happen to communicate using web service protocols. But the thing is that the Indigo programming model abstracts away all the web service goo from you and lets you work with a much more clean and declarative model.It happens to have adeclarative model that looks much closer to Enterprise Services programming today than it does to web services programming today. Through configuration, you will be able to control the transport layer and make it act like a web service, Enterprise Services, or .NET REmoting under the covers, but your code will look an awful lot like ES code from what I have seen.

So ES is not legacy by any stretch, it is very current and powerful in its capabilities, and it is very forward looking in terms of what you will build in the future.

What about interop? Well, certainly if you are calling out to a legacy COM component that is running in COM+, you are doing COM interop. But if you build a .NET ESbased system, the .NET components do not use COM interop to talk to one another. There is some unmanaged code in the loop for providing those component services from the operating system such as distributed transactions, security, instance management, queuing, loosely coupled events and so on. But there is unmanaged code involved for many other things your apps do that reach outside of their own context, so you shouldn’t let that fact drive your thinking about ES. Bottom line is that you need to try things and see if the technology can provide the performance needed for your application, not just blindly avoid things that you perceive to have performance penalties. And the fact is that you can get some huge performance benefits from the instance management features of COM+ and from the speed of the underlying transport if you design your system well.

Finally there is the difficulty of building ES systems. And yes, this is not the kind of technology that your average community college philosophy major can use tothrow together a toy app in an afternoon. You have to design your system, consider the communications and calls between components, figure out which services you need to use and how to best use them, and you have to have a lot of discipline and automation in your development and build process to do it right. But the benefits of doing these things are huge on their own and are something you should be doing for critical business applications in the first place, whether you use ES or technology X.

You also have to consider the time/cost payback of using ready-to-use, well tested and proven technology for services like distributed transactions, authentication and authorization at the application, component, interface, and method level, object pooling, just in time activation, queued component method calls, etc. etc. Sure you can build your own mechanisms for these things, but are you really so vain as to think you can build it better than they did? And without spending orders of magnitude more time than it would take to use the services out of the box? Need 2, 10, or a 100 components that call each other, possibly touching many different databases, to all become part of one distributed transaction? Sure thing, just slap an attribute on each class and each public method and you are done with ES. How long would it take you to get this right managing the transactions yourself? A little longer methinks. A security mechanism that can be locked down by the developer with a few attributes at design time based on the spec, but that can be easily modified later on adminstratively if requirements change? Done with ES. Spin your own? Have fun. Dispatch method calls asynchronously through MSMQ to components that you may not even have network access to at the time you execute? Sure thing, with ES a couple attribute, a slightly different instance creation coding pattern, done. Spin your own? Have fun.

Bottom line, people need to get past the fear and misconceptions of Enterprise Service components. If you are building toy apps, go ahead and ignore ES and keep building monolithic or client-server apps that don’t scale and are hard to maintain. But if you are building serious business apps for the middle tier and might need any of the services mentioned, then you should be looking at ES as one of your first choices. ES is an incredibly powerful capability that too many companies dismiss out of hand.

If you want to learn more, first, pick up a copy of Juval’s book. A strategic .NET-only developer willread every chapter for the concepts and understanding of each of the COM+ services, but will not get wrapped up in the C++ code presented. They will then cross reference the appropriate portion of Chapter 10, which presents justhow to use each servicewith Enterprise Services in .NET.

Also, check out our IDesign Method, which is one of our service offerings for helping companies architect and design their ES systems.