Re: Concerns with COM+

From: Dave (recneps.w.divad_at_elcaro.moc)
Date: 07/28/04 

Date: Wed, 28 Jul 2004 16:20:37 +0100

kai wrote:

> I am in the middle of an application group who listens to a very
> charismatic individual who tends to like hyping up the latest and
> greatest "n-tier" model as if it were set in stone.

It's his fault if it all goes tits up. Talk the group out of it and you
could find all the blame landing on your doorstep.

Are you sure your problem is with the framework and not with this "very
charismatic individual" - a criticism if I ever heard one.

> It has finally come to the point where I need to either (a) move this
> group away from a total reliance on COM+ or (b) move myself away from
> this group of developers/project managers. I'd rather perform option
> a, as I like ghe general direction of the group and many of the group
> members. As usual, several members are very much like sheep in that
> they'll follow a convincing leader, even if that leader is misguided.

Well, if you don't want to do COM+, and they're doing COM+, then the
solution is simple. OTOH, if you want to be with a group that does
COM+, then you must also do COM+.

A charismatic leader, followers like sheep....when you start saying
stuff like "I'm right and the rest of the world's out of step" perhaps
it's time for a bit of introspection...

> Bloated - it takes up too many server resources for the support
> structure it is supposed to provide.

It (the runtime stuff, not the devkit of course) comes free with
Windows. (Hint: have a look in the registry.) It takes up,
effectively, no space. Install J2EE or any other framework and you have
two frameworks installed for no obvious benefit. Now who's bloated?

> Difficult to maintain - in order to debug and analyze code issues,
> many steps have to be taken, which could be easier handled by simply
> writing C++ binaries, which aren't dependent on COM+ substructure.

One large executable with thousands of subtle interdependencies* between
modules is easier to maintain than a bunch of components with clearly
defined interfaces? Hmm...

*of course, you don't have to do it this way, but that's how large
executables always end up. A distributed design _forces_ you to use
defined interfaces, and with a single large executable, sooner or later,
a shortcut instead of the necessary redesign will be forced on you by
marketing issues.

Besides, this isn't a COM+ issue, this is a distributed programming
issue, and will exist in any other distributed framework just as much as
it exists in COM+. Whether or not you can write maintainable code is
not dependent on any particular framework.

> Non-expandable - one of the "benefits" of COM+ is supposed to be the
> ability to provide application back end resources on a scalable
> platform. I have found that in practice this is untrue. Scaling up an
> application which relies on COM+ is virtually impossible and requires
> far more effort and resources than a simple replication model.

Scalability is also a design issue. You can write non-scalable J2EE
code just as easily as you can write non-scalable COM+ code. Again,
this is a design/programming issue, not a framework issue.

You seem to be asserting here that you think COM+ is inherently
unscalable. I don't think that's true at all.

> Platform Dependent - I don't want to say that J2EE is the end-all
> here, but a back-end process that is written in a given 2G (or even
> 3G) language compiled should - IMO - be able to be recompiled with
> minimal library changes so that it could run in various platforms as
> servers change and evolve over the years.

If they want platform independence they can't use COM+. Your COM+
evangelist knows this already, as do most of the rest of the group. If
they want to use COM+ they already know they're stuck with Windows.

Platform independence should be driven by marketing requirements, not
technical preferences. If you don't have enough non-Windows customers
to be able to develop/support other platforms, then platform
independence is irrelevant.

A couple of points you missed (there may be others):

Java is interpreted (or at best JIT compiled), not executed directly by
the processor. Speed is therefore an issue; of course you can write
fast Java code and slow C++ code, but all things being equal, C++ will
run faster than Java.

Sun's internal document that said Java should really not be used for
internal projects due to various critical, unfixable, problems.

Platform independence comes at a cost. The most obvious is the GUI.
Ever seen something written in gtk (and others) trying to run on
Windows? No default buttons, no keyboard interface, gadgets that don't
match the rest of the system, yuck. It's all very well running gtk/etc
stuff on Unix where people don't expect a rich user interface, but on
Windows you get a lot of stuff for free that doesn't come with X-Windows
and you need some really good reasons for throwing that away.

Dave.