Alternatives to COM+ 16
_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 (Score:2)
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 (Score:3)
CORBA (Score:2)
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 (Score:1)
COM - Corba (Score:1)
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 (Score:1)
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 (Score:2)
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 (Score:2)
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 (Score:2)
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 (Score:2)
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 (Score:1)
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! (Score:3)
Joseph Elwell.
Look at CORBA (Score:1)
Not so fast... (Score:2)
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 (Score:2)
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 (Score:1)
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.