Concerns with COM+

From: kai (abuse_at_127.0.0.1)
Date: 07/28/04 

Date: Tue, 27 Jul 2004 21:56:56 -0700

I'm trying to put together a list of reasons why it is bad to use COM+
as an application framework. Unfortunately, after several hours of
using Google, altavista and yahoo search, I can find nothing leading
me in this direction.   Most arguments are J2EE or CORBA vs COM+. 

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 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.

In addition, I'll be presenting in October at a large user group
meeting sponsored by one of our vendors. Many there are in the COM+
camp, and I'd like to say why it is I feel we should move away. (There
are many J2EE supporters in that group as well.)

So:  I need for some of you out there in programmer/administrator land
to provide me with some arguments why using a COM+ architecture as a
middle-tier / application framework is a poor choice.   If you have a
competing view, I'll take that, too.

IMO, COM+ is:

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

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.

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.

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.

TIA - putting on flame retardant jacket 

-- 
kai
www.filesite.org || www.perfectreign.com
g3prod at cotse.net

Relevant Pages

  • Re: Using .NET 2.0/3.0 component in ASP.NET 1.1
    ... do not want to migrate the entire application to .NET 2.0 platform). ... ..NET Framework to run the applicaiton. ... introduced in v 2.0 The latter was developed ouside of the design ...
    (microsoft.public.dotnet.framework.aspnet)
  • Re: Concerns with COM+
    ... Are you sure your problem is with the framework and not with this "very ... If they want platform independence they can't use COM+. ... Java is interpreted, ...
    (comp.programming)
  • Re: Testing a package
    ... I looked at SUnit and ended up building my own framework that was friendly to package level testing and was simple. ... I suspect that a combination of singleton test resouces combined with a clear pattern for their use (perhaps a TestCase method to access them) would make it almost as easy as checking the #test* methods against references to the subclasses of TestResource. ... a TestCase subclass could override #requiredResources to add anything that slipped past the detection grid. ... a singleton implementation of resources. ...
    (comp.lang.smalltalk.dolphin)
  • Re: some interesting perspectives on .NET from the other camp ...
    ... >> now rather use framework functionality directly. ... Do you really think a VB.NET writer is any more dependent on MS ... low platform or framework level functions altogether. ... Trimming a string just seems to me to be exactly ...
    (borland.public.delphi.non-technical)
  • Re: Re: chr() .Net equivalent
    ... look at the notes from the conversion and the ... A new platform may introduce differences of its own simply due to ... framework. ... If you start dropping Visual Basic functionality in order to simply avoid ...
    (microsoft.public.dotnet.languages.vb)