Alternatives to COM+

_wintermute writes "For various reasons, I have been examining M$ COM+ Services under Windows 2000. It all seems rather impressive (which smacks of heresy, obviously). COM+ basically integrates COM with Microsoft's Transaction Server, and handles concurrency & threading, security, transaction management, object pooling, and queuing (very handy for a whole range of Internet services). Everything is integrated into W2K and it all seems to work very well. Which seems too good to be true. I have been grinding away at it for months without even a single failure. I was wondering if similar services exist on other platforms and what they were like? Are there other platforms that capture this much functionality? Do we actually need all this COM+ stuff anyway?"

Good luck

[aTRaTiCa]

Good luck finding anything with COM to due with any UNIX.

http://www.kegel.com/linux/mslinuxinde x.html [kegel.com]

This was from last year I believe, so maybe there were some integrations since, but I doubt it. (Search for COM in the article, it's not stricly about COM.)

As for who needs COM... Certianly nobody I know of. :-) But if neccersay we can

COM on Microsoft [microsoft.com] is just crap IMHO... Why bother with it...?

The question makes no sense

[Signail11]

A good software developer uses the tools and platforms that best fit the task at hand, much as a good architect would use the materials that best suited the specific area of the building that he was designing. The person who posed the question stated that COM+ worked well and possessed many positive attributes; it considerably simplified the programming task, while not extracting any cost in stability. Obviously, COM+ works well for the application that the person was using it for. It is blatantly unprofessional to use an inferior product or tool when one already exists that performs the required task superbly; to do so smacks of bias and illogical prejudice based solely on the origin of a product that does not do justice to the needs of the consumer.

CORBA

[Kryffpi]

As far as I know at least, CORBA is the competition to DCOM, now COM+.

Not having used either technology I can't say for sure...

The official CORBA FAQ has a feature list that is similar to COM+ in key areas:

http://sisyphus.omg.org/getting started/corbafaq.htm [omg.org]

Yes I develop for Windows. I enjoy it too.

CORBA

[dannyspanner]

You might want to look at CORBA [corba.org] which is the open standard equivalent of COM(+). The newer versions have stuff about services in. Remember it's only a standard though, so finding a suitable implementation for you is where the real problem lies.

COM - Corba

[a2800276]

So, what's the question, really? You@re not sure whether "we actually need all this COM+ stuff anyway"?

Your're using it, right? Do you need it?

Concerning the alternatives, depending on what you need, there's things like RPC and CORBA, or take a look at the KParts Components of KDE (Gnome apparently has something similar). If you need COM functionality on a non-M$ Plattform, Iona's Orbix/OrbixWeb Corba has an adapter from COM to Corba and I would assume other vendor's ORBs have similar functionality.

CORBA

[rilel]

Get an open source CORBA implementation:
1. MICO (Mico Is CORBA): An implementaion in C++ with a nice & very "easy to use API". But it is sloooow. From another point of view you surely can't say that COM+ is fast.

2. ORBit: The GNOME CORBA implementation. The best implmentation around. It is the one which is used in the GNOME project (e.g. Bonobo which is based on CORBA). It is fast and nice. The only thing is that it is written for C (not C++), using the OO model of GTK+. Now, there is also an ORBit C++ project, check it on the GNOME CVS, I don't know the development status of this one.

COM+ SUCKS!!!

CORBA moving towards J2EE-style communications

[sobiloff]

CORBA's great stuff, but the specs were so sloppy that different ORBs from different companies usually didn't work together, making it a real pain to build extranets or complicated intranet apps that spanned multiple technologies across an enterprise. CORBA 2.3 finally provided the Internet Inter-ORB Protocol (IIOP), which tries to codify a standard way for different ORBs to communiate together. The major vendors have been a little slow to adopt it, but they're coming around.

However, if you're thinking about getting into CORBA you should be aware that the OMG (CORBA's parent organization) is moving towards adopting the Java 2 Enterprise Edition's communications method, i.e. RMI over IIOP. They realize that there are already far more Java programmers than there are CORBA programmers, even though CORBA's been around much longer. So, they're embracing some of the Java standards in order to build their market.

In short, if you're going to make a serious commitment to CORBA you should get ahead of the game and learn Java 2, including the Java IDL and EJB packages. By the time you've grokked these technologies the CORBA marketspace will have caught up with you and you'll be sitting pretty!

com+ vs. corba

[os10000]

There is no free implementation of CORBA that
does all the things that com+ does. For message
queueing, use IBM MQSeries, for transaction mgmt,
use BEA Tuxedo, for connection sharing, use any
commercial CORBA implementation. Thus, MS is
very good at providing superb services on their
own platform (which is probably going to be stable
as the "datacenter edition" where only certain
hardware and drivers are allowed). CORBA et al
are a similarly good solution in a cross-platform environment

Re:Good luck

[JonK]

Of course you don't need COM+, in the same way that you don't need any of the Standard C library. It's just that having the framework in place expedites development (tho' we all know that Real Programmers are called Mel and write pure machine code on Royal McBee drum-memory machines...).

Given, I assume, that we're all convinced of the benefits of doing as little work as possible comcommitant with getting the product as specified out of the door on time (a viewpoint which I'll call "don't reinvent the fscking wheel" or "why work 80 hours/week when you can work 60"), the target then becomes "how can I leverage as much of other people's code as possible in order to help me do my job". Now, I've read Gray and Reuter. I could, given sufficient time, build a TM (those people who don't know what a TM is had better stop reading now and go back to tweaking their KDE themes or whatever). I could possibly, given sufficient time, write a TM that manages transactions across multiple distributed datastores (equally, a suitably large number of monkeys will write Hamlet). However, I don't need to do this because my middleware does it for me. Similarly, it handles queuing, event architectures, distrubuted processing, load balancing, clustering etc

This is why I chose to use middleware. Now, in answer to the second half of the question - why use a component-oriented middleware? Because, to put it bluntly, CLIs suck (I'm referring here to call-level interfaces, not command lines. Put those flames out now). CLIs are generally not language-neutral (vis Perl->wrapper->library of Perl routines written in C) or architecture-neutral (is an int 16, 18, 32 or 36 bits? How long's a char? How much accuracy do I get with a float? Does the system I'm communicating with do ASCII or Unicode or some MBCS such as Hangul?). They generally (there are notable exceptions) handle discovery very badly (i.e. can clients ask "what members do you have"?). They're often not location-neutral (i.e a call to a local component is often subtly, or even completely, different to one to a remote component). They're, to put it bluntly, nastier than they need be.

What COM does (and what EJB and the CCM do) is abstract a lot of these problems away (admittedly EJB cheats somewhat by making everyone talk Java: there is a COM - EJB bridge but to be honest, it's pants. You can't trivially mix apples and oranges, and you're better off not trying. Decide on one middleware architecture early on in your projects and stick to it. Madness lies elsewhere. There are also COM - CORBA and CORBA - EJB bridges too, but a) I've not used them in anger and b) they're probably going to become obsoleted fairly soon once the CCM starts permeating through (always assuming that the LOIs that members of the OMG signed up to actually get followed through).). All three provide some form of lifetime management, interception, load-balancing, transaction management and, in general save you from having to write all that grungy code yourself.

Finally, why use COM+? Well, because it's arguably the best component orientated middleware out there. There are legitimate arguments for EJB but it's got a number of fundamental problems, most of which I'm happy to discuss at length: put briefly, it's got all the political problems of COM+, it's got its own set of architectural problems (contrary to what some people may claim, stateful components are not a good idea. Ever.), it's relatively immature and it mandates that you write components in Java. CCM (the CORBA Component Model, sired by the loins of the OMG) may prove to be nice but since I've not yet seen a working implementation I'm reserving judgement. As far as I can tell from reading the documentation from the OMG, it looks like the EJB-aligned vendors wanted EJB to be accepted as an OMG standard as is, various other vendors wanted something a little more sensible and the resulting spec bears the scars.

Oh, and two warnings. First off, traditional CORBA, and bastardised COM implementations like Bonobo and KParts, bear as much resemblance to COM+ as the original VW Beetle does to the new one: the general concepts are the same (a wheel on each corner, an engine and a body) but there's not many other similarities. Secondly, not all CORBA vendors' objects are equal: it was only recently that they came up with IIOP. Previous to that, inter-ORB communication was ... erm ... interesting, at best. IIRC, CCM OTOH mandates RMI over IIOP and should therefore aid the chances of creating interoperable components - once it condenses from vapour into real products.

Hope this clarifies the situation.
--
Cheers

Pretty standard stuff

[X]

Actually, what you described is very standard stuff in the application server market. It may sound like new coming from Microsoft, but it's not. Most CORBA ORB's will provide you with all this, but you'll find the fastest growing market for this technology is Java2 Enterprise Edition servers like Weblogic and iPlanet Application Server.

Of course, there's the secondary matter about how easy any of these platforms is to actually get something done, and I'd have to say, J2EE wins hands down here. You can download a trial edition of Weblogic from their website. Give it a try.

Re:The question makes no sense

[Tupper]

You mentioned two important features of a product: that it works well and that it is stable.

Obviously, these are important considerations. But there are other important considerations too; for instance: cost, openness, vendor independence, interoperability, platform availability. While the original poster didn't say why he was unhappy with COM+, these issues are negatives for COM+, at least in certain environments. Certainly, they could prompt a "logical" and "professional" person to look for a better alternative.

Cheers, Tupper

This is easy XPCOM!

[jelwell]

This is too easy, use XPCOM - it stands for Cross-Platform COM (Component Object Model) XPCOM [mozilla.org] Documentation. XPCOM is binary compatible with COM, and uses XPIDL - Cross platform Interface Definition Language. XPCOM is everything COM is plus Cross Platform. Don't let anyone tell you to forget about anything like COM for Linux! Mozilla uses (created) XPCOM and is used on all sorts of Unic variants - and the same component can be used on any computing system that the core XPCOM architecture has been ported to. Currently this consists of the main computing platforms - Mac, Windows, Unix and possibly OS/2, Be and others I don't keep track of.
Joseph Elwell.

Look at CORBA

[Def Mango Raygun]

We looked at COM a while ago, before all the COM+ stuff was available and it was seriously brain-dead. Although it may be better now, if you plan on doing any cross platform development, take a very good look at CORBA. We use Visigenic/Borland/Inprise or whatever its called this week. Their marketing is terrible, but the product is great stuff. Adding about 20 lines of code makes it network/cross platform ready. We use it on both Solaris and NT and it's fast and reliable. Just don't get too crazy with lots of embedded objects and remember that each CORBA function call is actually a data transfer over a socket connction. Too many remote calls and the performance degrades. (We get 50ms response on our local network.) Other technologies, like Java RMI, and direct sockets are either slower, don't work, or are a pain in the arse to develop. Forget get about cross platform RMI. And beware the applications server vendors, they can lock you in to there stuff, which can be a pain to program around if it doesn't do what you need.

Not so fast...

[AT]

XPCOM is a very simple framework that lacks lots of the glue that COM provides. I would assume COM+ provides even more. So while XPCOM might be a good starting point, it doesn't really compare to a COM or COM+ framework (yet).

From a mozilla document [mozilla.org]:


COM -- Isn't that a scary Microsoft thing?

No on both counts, actually. COM has its origins in Apollo's NCS system, and was later developed by Digital and Microsoft as part of their OLE/ActiveX architecture. We use a very small subset of COM that we call "XPCOM" ("XP" stands for cross-platform) for the new Plugin API that is essentially a method of using abstract base classes, and 3 simple but powerful methods:

QueryInterface: Deals with interface versioning by using universally unique interface IDs.

AddRef and Release: Deal with reference counting the object so that the system knows when it can deallocate it.

That's it. Using XPCOM in the plugin context is really quite simple. We don't make use of any of the COM factory constructor mechanisms, object aggregation, OLE interfaces, or the registry to find and load components. Plugin DLLs are still searched for and loaded by Mozilla from the plugin directories where they've always been found.

Re:The question makes no sense

[spectecjr]

Obviously, these are important considerations. But there are other important considerations too; for instance: cost, openness, vendor independence, interoperability, platform availability. While the original poster didn't say why he was unhappy with COM+, these issues are negatives for COM+, at least in certain environments. Certainly, they could prompt a "logical" and "professional" person to look for a better alternative.

Which solution you end up with depends on how you weight those factors ; but due diligence would dictate that you at least check all your options.

Si

Re:The question makes no sense

[Omnifarious]

This isn't true. There is a significant cost incurred by vendor lockin. If the vendor of a tool seems to have the idea that you will forever be tied to their platform and tool, then, I would avoid the tool, no matter how good it was.