COM+ Rules - Willy-Peter Schaub's Cave of Chamomile Simplicity

COM+ Rules

After two years of intense focus on managed code, I had the pleasure of doing a time warp back to COM+/C++ as part of the interoperability sections I am creating for our new book and a production solution that is happily running on COM+. The joy and excitement exceeded the frustration of getting back into C++/ATL and I have realised that COM+, Component Services or Enterprise Services, or whatever name it is currently known as, is far to powerful to be forgotten when designing solutions of today and tomorrow.

Some facts I listed on my scratch pad: Interoperability between .NET and COM+ is seamless, functionality of COM+ is immense, there are huge business solutions “humming” away on COM+ and Microsoft recommends new solutions to use .NET, not COM+. Well, I strongly disagree with the latter and agree with the rest. If we take the approach of using the right technology for the right task and interoperating with existing, rather than migrate “working code”, then COM+ will be with us for a long, long time.

I am now an evangelist of both technologies and if that means I have joined the dark side because of it, then the COM+ Siths rule!

Share this post: email it! | bookmark it! | digg it! | reddit! | kick it! | live it!
Published Thursday, June 02, 2005 11:08 AM by willy
Filed under: , , ,

Comments

# re: COM+ Rules

Thursday, June 02, 2005 4:20 PM by ahmeds
Where do you reckon System.EnterpriseServices fits in. It makes use of COM+? but is a .NET namespace

# re: COM+ Rules

Friday, June 03, 2005 8:58 AM by wschaub
Ahmed, I am fully aware of what Enterprise Services and the associated namespace in .NET are all about. It is exactly the point I am trying to make, namely that there is a close relationship between COM+ and .NET and that the former will not become extinct for a very, very long time. Refering to the Microsoft best practices site ... "Microsoft recommends that developers use the .NET Framework rather than COM for new development" ... is the recommendation by Microsoft which I completely disagree with ... unless, off course, the statement assumes that COM+ != COM. It should be rephrased to state that new systems should be developed in .NET, but considering interoperability with .NET and COM+ (Enterprise Services) where appropriate.

# re: COM+ Rules

Monday, June 06, 2005 12:29 PM by ahmeds
Ahh, I think COM+!=COM. I think of COM+ as a set of application services and COM as object model/plumbing with a tightly bound transport.

# re: COM+ Rules

Tuesday, June 07, 2005 8:48 AM by mleach
I, too, think that MS is referring to COM and not COM+, after all there is a significant difference. In that case I would agree with MS in that using the .NET framework to wrap an existing COM+ component allows even better interoperability.

# re: COM+ Rules

Sunday, March 12, 2006 12:12 PM by willy

Ahmed, looking at the architecture of COM+ we quickly realise that COM+ is built onto of the COM plumbing. Any interaction with COM+ and its COM framework is therefore via COM interop. In my opinion COM+ cannot exist without COM, however, it is feasible to package functionality in COM components and effectively reuse them within .NET. To construct a COM+ application we are still better off, based on my experience, developing COM components and dropping them into COM+ than using Enterprise Services and dropping managed components into COM+ applications. Perhaps this statement is based on the fact that we are still maintaining huge enterprise solutions based on COM, COM+ and maintained using Visual Studio 6.

Neither COM nor COM+ will evaporate soon ... not as long as Microsoft continues to ship COM-dependant solutions, i.e. IE7, or while there are productive COM solutions in the industry.

The day a fully managed O/S and a supporting set of managed application ships, I may change my opinion.

Leave a Comment

(required) 
(required) 
(optional)
(required) 

Enter the numbers above: