On Thu, 23 Mar 2000, Dan O'Brien wrote:
> We are finding that as we scale up the number of users, this vendors
> CORBA starts running into deadlocks and other blocking issues where
> the server becomes crusted over and quits functioning.
> We are working with the vendor to provide a solution, but we are finding
> ourselves less confident in this particular ORB and are looking to
> make a change.
Before you give the vendor a hard time, it is possible that the problem
is in your code, rather than the vendor's. Of course, not knowing which
vendor and not having seen your code, I can't judge exactly why you are
having problems. Given that you mention a pre-POA ORB, I wouldn't be
surprised to see threading problems though. Some pre-POA ORBs have
threading support that is, shall we say, sub-optimal and, in addition,
the BOA doesn't lend itself to threading all that well either, at least
not compared to the POA.
> We presently use many proprietary extensions of this particular vendor's
> ORB and are looking at ways to move our application platform away from the
> proprietary extensions to using only (mostly) OMG CORBA 2.3 POA interfaces.
> (Even the vendor of our current ORB is even pointing us to their follow on
> product that implements OMG CORBA 2.3 using POA technology.)
> So we are at a cross roads.
> Are the problems we are seeing as we scale up a limitation of the CORBA
> architecture we have chosen? A limitation of CORBA itself?
There is no way to tell without knowing your architecture -- it may well
be contributing to your problems. In general, there are no inherent scalability
limitations in CORBA itself. In particular, with the POA, you can scale
to extremely large numbers of objects in a controlled memory footprint,
and you can take precise control over the performance vs memory consumption
trade-off. But, as with any powerful tool, you can also build something
with abysmal performance -- CORBA can't do your designing for you...
> Are there ORBs known for their scalabilty, performance,
> multi-threaded safeness? Is there some kind of comparison chart?
There are a few benchmarks around. However, I don't recall any benchmarks
that address multi-threading.
> Can we practically achieve vendor independence using POA interfaces and
> wrapping vendor-isms appropriately?
You can get damn close if you choose an appropriate design. For one thing,
the POA is source-code portable. The only things left unspecified are
issues that can be dealt with in your build environment, such as file names,
location of header files, library names, etc. Second, the POA is well-designed
and provides a lot of functionality in a standard way that is essential
for scalable designs (such as servant managers, default servants, decoupling
of the life cycle of servant and reference, etc.)
But even with the POA, you will find vendor extensions. Not because the vendors
are evil and want to lock you in (well, maybe some are ;-), but usually
because some functionality isn't specified. For example, standardized
threading support in the POA is not as good as it could have been. And,
there are other parts of CORBA that are deliberately not standardized (such
as implementation repositories) because standardizing those makes little sense.
> Given the effort to pry fixes out of our current vendor, I'm suggesting the use
> of open source CORBAs like TAO, etc, but my management is concerned with having
> "someone" to beat on when it breaks.
> Are there CORBA vendors that are known for providing sterling support?
Ask around. You will probably find that smaller vendors tend to get much
more favourable judgments than big vendors when it comes to support.
> Can using the open source model for CORBA really work for production level
> applications? Using TAO for example, are their millions of net-heads using it,
> testing it, fixing bugs, providing patches? Or are we really on our own
> and need to invest staff to support it ourselves?
If you have an ORB you need to support yourself, then you are wasting your
time (unless you are an enthusiast and get a kick out of this sort of thing).
An ORB is infrastructure that is supposed to make your life easier, not
harder. You don't expect to have to debug your TCP/IP stack either, do you?
As far as Open Source is concerned, it's been very successful in some instances
(e.g. Linux and the GNU tools), but less successful in others. Basically,
for Open Source to be successful, you have to have something that is
sexy enough to attract developers' interest, and that is large enough to make
a living by providing professional support for it. There also seems
to be a focus for Open Source on tools, rather than end-user applications.
(Yes, I know that's a generalization and that there are exceptions.)
When you look at the vast amount of software out there, and compare it to
the amount of software available as Open Source, there actually isn't all
that much Open Source. That's not really surprising -- for example, I don't
know of an Open Source airline reservation system, or an Open Source
ignition controller for fuel injected cars. (Those things don't make
a lot of sense as Open Source, or at least they don't if you want
to make money off commercial support, either because they don't have wide
enough distribution and are not of general interest, or because they are
too specialized.) Also, a lot of Open Source contributors are motivated by
peer recognition, so the less visible and "sexy" a particular project is,
the less likely it is to attract Open Source contributors.
ORBs sort of qualify and don't qualify as Open Source, I think. They have
the tool and infrastructure aspect, and they are complex enough to
require commercial support. I'm not sure how "sexy" they are these days.
Many of the problems addressed by ORBs are no longer research material, but
are solved problems with known solutions. The research aspect in CORBA lies
in those bits that aren't standardized yet, such as multicast or fault
The main problem I have with Open Source is that, unless it has a very
wide following, such as Linux, there is a risk that the developers/maintainers
lose interest and move to bigger and better things. Sure, you have the source,
so you can take over. However, most accounting software firms are in the
business of doing accounting things, not in the business of maintaining ORBs.
Or, to put this differently, if you are using an Open Source ORB to get
some job done, you probably won't be interested in taking on maintenance
of the ORB, even though you could do that in theory. (Incidentally,
I see this as one of the big fallacies of Open Source proponents -- the
argument that I can always take over and maintain the source myself simply
is unrealistic in most commercial situations, even assuming that I have
People will also argue that Open Source is unlikely to be abandoned. For
something very large, like Linux, I agree that this is unlikely. For smaller
efforts, I'm not so sure. In my twenty years as a programmer, I have seen
plenty of Open Source find its way into the mainstream and disappear without
a trace because the developers lost interest.
So, for managers who like their security blanket, a commercial offering
may well be more attractive than an Open Source one. On the other hand,
Open Source is free, commercial software is not. The vexing thing is
that, often, source code products are technically superior to binary ones.
With ORBacus, we've gone down the middle path: not open source (although
you get the source), but not free either (although free for non-commercial
As always, there is the whole spectrum: from binary-only and run-time
licensing to Open Source with no cost whatsoever, and quite a few
options in between. Where you want to be on that spectrum is up to you and
is a decision only you can make. However, I wouldn't judge the whole
of CORBA by one poor example (whether that is a binary-only commercial
offering, or an Open Source one). There are good and bad binary commercial
products around, just as you can find good and bad Open Source ones.
And, just because you can have the source for something, that most definitely
doesn't mean that it will be poor.
Michi Henning +61 7 3891 5744
Object Oriented Concepts +61 4 1118 2700 (mobile)
Suite 4, 904 Stanley St +61 7 3891 5009 (fax)
East Brisbane 4169 mi...@ooc.com.au