.NET Ramblings - Brian Noyes' Blog - COM+/Enterprise Service Components are not a legacy technology

Friday, May 14, 2004

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 a declarative 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 ES based 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 to throw 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 will read 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 just how to use each service with 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.

.NET | Architecture | Languages and Tools

Friday, May 14, 2004 8:22:09 PM (GMT Standard Time, UTC+00:00)

Comments [5] |

Friday, May 14, 2004 10:54:20 PM (GMT Standard Time, UTC+00:00)

Hey Brian,
Here's my beef with ES. There is no good body of work that shows how to do this stuff in the real world. From what I have seen there is no good sample application from MSFT that shows how to use ES in a .NET world.

For MTS --- early ES --- we had FM Stocks, Fitch Mather, etc.... At least we could use these as a reference to see how it is done from top to bottom.

Juval's book is a good start and does a good job of explaining the different parts and pieces of how to use ES at a very primative level. But it does not address just how a ES application looks and feels. I would like to have seen Juval build a small but complete application using ES. This helps solidify how this is done.

Some of my questions are
How do you deploy this stuff ? Like it or not most applications are very dynamic in nature and deploying ES components to the desktop is a real PITA.

Do you build all your CRUD screens using ES. Do you build even the most simple maintenance screen (some type of lookup list) using ES ? If so how are you ever going to take advantage of what ES provides ?

Another question is? why not just use Web Services to do this. WS seems to be where MSFT and other vendors are spending their time. The WSE seems to provide a lot of functionality tha ES has as well.....

Thanks
Rodman

Rod Paddock

Friday, May 14, 2004 11:55:32 PM (GMT Standard Time, UTC+00:00)

Hi Rod,
All good questions.

Deployment to the client is as simple as generating a proxy application installer on the server. A few mouse clicks on the middle tier server where the ES components run, run the resulting MSI on the clients either directly or through SMS, and you should be ready to go.

If that is too impactful based on how dynamic the client and the interfaces to the middle tier are, then you can move to a more loosely coupled solution using no touch deployment or some equivalent auto-update solution (definitely moving to ClickOnce in Whidbey), with the client designed to talk to a web service in the middle tier that acts as a facade to the ES components that are doing the work. The WS can either be a thin wrapper over the ES components, or you can expose the ES components directly through COM+, although you don't have explicit control over what the WS contract looks like then.

If it is an Enterprise scale application, I would use a consistent architecture for the middle tier(s), whether the client was doing simple crud operations, or invoking complex business logic. The client just calls into the middle tier, and the complexity of what they are trying to do drives the complexity of the middle tier components. You can potentially scale out some business logic components (such as validation) to the client to try to harness some of the desktop machine power if you are using some form of autodeployment, but you are correct that if you are having to deploy ES components to run on each desktop, the pain threshold is going to get pretty high there. You just have to balance what those client side components are doing and whether they need any ES services against the pain to install/register them. By default my first instinct is not to do ES components on the client. The client should be as lightweight and portable as possible.

Why not use web services everywhere? A lot of reasons. Performance, security, transactions, ... all the things that will eventually come with the many WS-X specs out there and with Indigo, but that are not all ready for prime time yet. But bottom line is any time you are doing web services you are paying a heavy perf penalty to serialize your data and arguments back and forth. The reward is looser coupling and flexibility, which is worth the perf (and other lack of services) penalty when you need to interop with distributed systems. But that is just too high of a penalty to pay between components of a system running in a LAN environment where binary comms shouldn't be a problem and that you are building all the components. It especially doesn't make sense between components running on the same box.

Parts of Microsoft continue to overhype the Web Services thing and the wrong message comes across. For distributed, interoperable, loosely coupled systems, WS is the answer. Within the enterprise, within apps that are being built together as a system, WS gives up too much for too little gain.

My 2+ cents.

You are right about lack of good current books focused on .NET Enterprise Services development. Unfortunately we are now close enough to Indigo, which WILL make ES legacy (but with easy migration), that anyone who is capable of writing that book is probably focusing on Indigo and would rather start work on a book on that. Maybe a good topic for a CoDe magazine article though, huh? :)

Brian

Saturday, May 15, 2004 12:50:18 AM (GMT Standard Time, UTC+00:00)

Brian, the link to IDesign gives an ASP.NET error (and shows the stack trace! ;)

Andres Aguiar

Sunday, May 16, 2004 2:29:53 PM (GMT Standard Time, UTC+00:00)

Hello Brian,

There is a new book on Enterprise Services (which I have had the pleasure of helping to review) that is forthcoming by Christian Nagel (which has been mentioned on his blog and at his new site: http://www.thinktecture.com/Resources/Books/default.html).

Very well done article on ES. If you have read my blog over the past year, I have also been a big supporter and promoter of ES. But, I have also felt the frustration of getting this to work for some of the issues that Indigo will address. Using DCOM with built-in security across two boxes is one of the best transport solutions (performance, security, etc.) than WebServices, Remoting, etc. but comes with many penalties such as lack of support for all .Net types, problems with .Net security across machine boundaries (http://weblogs.asp.net/rhurlbut/archive/2003/11/25/39655.aspx), difficulties with custom exceptions across machine boundaries (http://weblogs.asp.net/rhurlbut/archive/2004/02/24/79161.aspx), and other headaches with distributed transactions using database vendors other than Microsoft (http://weblogs.asp.net/rhurlbut/archive/2004/01/14/58770.aspx).

Even with the limitations, I completely agree that ES provices the best solution in .Net today for distributed transactions, Windows security across boundaries, asynchronous MSMQ calls, etc. I certainly wouldn't want to roll my own (believe me, I have looked at this as others have, and it is isn't easy).

Thank you Brian for a great article on the benefits that ES does provide today, depending on your requirements and needs.

Robert

Robert Hurlbut

Sunday, May 16, 2004 2:52:46 PM (GMT Standard Time, UTC+00:00)

Robert,
Thanks much for the info on the book and the links to your blog. I must admit I hadn't come across your blog yet, but am subscribed now, and I will definitely check out the book you mentioned.
Brian

Brian

Comments are closed.