Fog Creek Software
Discussion Board




Making the jump to COM+

I've recently crossed paths with what could be described as a COM+ Evangelist, who has said it's very important for writing large scale enterprise applications.

Traditionally we've written single-tier applications, most of our customers being small to medium business. Now management want to grow the business to try and tackle larger companies as well. Our current product range won't scale to this, so I've been tasked with coming up with an alternative.

The end result must be an architecture that will last for at least several years and product lifecycles. It must scale between 1 user and potentially hundreds of simultaneous transactions. And run on everything from NT4 upwards.

From what I've read up on, using COM+ sounds ideal - allowing me to defer a lot of the resource pooling, synchronisation and security to it. But I don't have much experience in it, so I'm not sure exactly what benefit I'll get out of it. Or what problems I'll run into if I don't design the architecture around it.

Any comments? I'm confused about whether to make the jump or not....

Better Than Being Unemployed...
Friday, October 10, 2003

Why not skip COM+/DCOM and go straight to .NET (which uses "remoting" to do similar things)?

If you're setting future strategy it ought to be on technology with a future!

Gwyn
Friday, October 10, 2003

Ah, I should have said. We are using .NET as well. But the .NET Enterprise Services use COM+ under the hood, don't they?

Better Than Being Unemployed...
Friday, October 10, 2003

As you rightly identified, in no way is .NET remoting the replacement for COM+: For enterprise services .NET fully makes use of the binary services of COM+, and is fully dependent upon it.  At some point in the future Microsoft may release a .NET Enterprise Service host, however because the .NET Framework is already making the .NET -> COM+ layer transparent, it is irrelevant.

Having said this, COM+, like most other external services, is not a panacea - While segregating your application and taking advantage of COM+ type services of JIT, synchronization, pooling, etc, allows you to scale out more, for high volume systems you humorously will have to greatly take advantage of that facility immediately : COM+ calls, using COM+ services, to inprocess Library services are much slower than direct in-proc COM calls or inprocess calls, and COM+ calls, using COM+ services, to out-of-process ("Server" COM+ packages) are DRAMATICALLY slowed down. Add in transaction coordination to solve a problem that binary separation causes (which is cross process transactions) and each call becomes absolutely monstrous. I'm sure someone will swagger in claiming that it is irrelevant, but it most definitely is, _especially_ when talking about enterprise systems.

There is absolutely a time and place for COM+ and the services that it offers, but a true "enterprise" programmer weighs the upsides and downsides. The pseudo-enterprise programmer (there are many out there) latch onto anything that seems enterprise-ish without metrics or actual analysis, and proclaim their ability to add  System.EnterpriseServices.ServicedComponent as the ancestor of their class the true sign of an enterprise programmer.

Dennis Forbes
Friday, October 10, 2003

I'm entering dodgy territory cos I've avoided COM thru' .NET because I understand it all goes through nasty old Interop which is a legacy bodge (in the nicest sense of the word) and has performance implications.

My understanding is that remoting is the way to go.

I'm happy to be shown otherwise!

Gwyn
Friday, October 10, 2003

"I understand it all goes through nasty old Interop which is a legacy bodge (in the nicest sense of the word) and has performance implications."

"nasty old Interop"? I understand what you're getting at, and there is a fresh, clean feeling about .NET Remoting that is shiny and new (and one can chatter about how they use an "HTTP channel", thereby making their app cutting edge and "Web Enabled"), but one must realize that .NET remoting is just, as Joel would call it, fire and motion, and the primary purpose of .NET remoting is making a "COM for dummies", so to speak (because about 10 people in the world actually fully understand COM, and they all have beards...). Because .NET remoting is so much in its infancy, there are no enterprise services, so if you want those services (such that COM+ supply) you need to host your .NET object in a COM wrapper that is run in COM+.

Personally I find some aspects of .NET remoting, such as the explicit declaration of TCP ports, absolutely ridiculous -- This is an idea that should never have made it out of Microsoft. I have a feeling that this is an aspect of .NET that is going to go through some major revisions.

As a sidenote, .NET remoting using the binary formatter (i.e. "proprietary", like DCOM RPC) has an equal speed to .NET calling a DCOM server. If you use another transport protocol for .NET remoting your speed will decrease from there.

Dennis Forbes
Friday, October 10, 2003

>> "My understanding is that remoting is the way to go..."

That's if COM+ was just some RPC mechanism -- you're not comparing apples with apples.

>> "...the explicit declaration of TCP ports"

You can put the TCP ports etc in the app config file and call RemotingConfiguration.Configure() -- so they don't have to be/shouldn't be hard-coded.

Duncan Smart
Friday, October 10, 2003

Better Than...:

I'd encourage you to think long and hard about what business problems you're really trying to solve, and if they require the use of COM+ to solve them.

Adding a new, powerful technology into the mix sounds wonderful, but just remember that you're going to need to deal with the additional development overhead of deciding how to integrate the technology into your application's framework.

Also, I'd like to point out, that to utilize COM+, you need Windows 2000 SP2 or later, so NT support is out.  See:

.NET Framework System Requirements
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpguide/html/cpconnetframeworksystemrequirements.asp

In many cases, especially if the bulk of your clients are *not* going to be running hundreds of users, the best solution may be to simply use ADO.NET directly from the client to talk to the database server.

Oh, and if this is your first major .NET project, you're going to have enough work determining the best way to utilize the Framework on its own, nevermind throwing COM+ into the mix.

Dave

Dave
Friday, October 10, 2003

(We're two years into a three-year .NET/WinForms/SQL Server project. We evaluated COM+ early on and decided it was overkill for our particular app and introduced too much schedule risk. In addition, we didn't like the additional system requirements.)

Dave
Friday, October 10, 2003

If your COM+ evangalist was talking about transactions across multiple database vendors (Oracle, SQL), then COM+ is almost a must.  This happens frequently in distributed enterprise applications.

Otherwise, proceed carefully.

Canuck
Friday, October 10, 2003

I'd say use it only if you have to - it causes as many problems as it solves, if not more.

Additionally, chances are your app will run slower, not faster, by using COM+ (due to the stuff other people have mentioned).

That said, distributed transactions are one of the things it provides that are sometimes needed, and are a pain to do without COM+.

Sum Dum Gai
Saturday, October 11, 2003

Take a look at the big picture. There are the big three technologies of multi-tier business software development: COM+, EJB and CORBA.
Each of it has it's pros and cons.  See http://www.stal.de/Downloads/middletier_components.pdf for an overview.

If you want dig deeper into COM+, I can recommend to you Michael Stal's "Hitchhiker's Guide to COM and COM+" ( http://www.stal.de/Downloads/COMplus.pdf ).

Michael Bruckmeier
Sunday, October 12, 2003

*  Recent Topics

*  Fog Creek Home