I just discovered that neither the current ORBacus is free, nor was the
4.0.2 version (although an IONA representative said so ;-). So I am looking
for alternatives to this, and I discovered omniORB, MICO and TAO. I found,
ORBIT2, too, but to me it seems that this one is for C mainly.
I got an omniORB sample running fast, and I now think about doing this with
MICO and TAO, too. Or, can anyone tell me about the crucial differences, if
there are any, or does anyone have a recommendation on which free orb to
use?
--
Best regards, Pi (Ralf Pichocki).
Have you seen this 2005 posting? :
http://groups.google.com/group/comp.object.corba/browse_frm/thread/a5a57b6da4fde4d2/6c1e651d10ad95c1
Here at my company we just have started using omniORB and I'm really
satisfied with it. The mailing list is really helpful, it works well
with Visual Studio (VC8) and what I find really nice is that the IDL
compiler backend is written in python - so easily extendable.
br,
Martin
Each ORB has its strengths and weaknesses, e.g., omniORB is very fast
but doesn't support as many features as TAO, etc. In general, I think
it's fair to say that of the three open-source ORBs you've listed that
TAO
. Supports the most features - including most of CORBA 2.6 + CORBA 3.x.
. Has the largest user base, e.g., over 10k downloads per month
(see http://download.dre.vanderbilt.edu/usage/usage_200807.html for
status on July '08 thus far) and contributors (see
http://www.cs.wustl.edu/~schmidt/ACE-members.html for the list of
over 2,200 contributors)
. Has the most extensive documentation, e.g., see
http://www.dre.vanderbilt.edu/~schmidt/DOC_ROOT/TAO/docs/documentation.html
for info on various documentation sources.
. The broadest commercial support for users who need consulting and/or
support agreements for mission-critical systems, e.g., see
http://www.cs.wustl.edu/~schmidt/commercial-support.html for the
list of companies that support TAO worldwide.
Take care,
Doug
--
Dr. Douglas C. Schmidt Professor and Associate Chair
Electrical Engineering and Computer Science TEL: (615) 343-8197
Vanderbilt University WEB: www.dre.vanderbilt.edu/~schmidt
Nashville, TN 37203 NET: d.sc...@vanderbilt.edu
Thanks a lot for your opinions.
Actually, I just started with omniORB, and I think it runs quite well (ok,
admittedly, I don't like the way its IDL compiler puts everything into one
file, but this is a minor issue). I am somewhat afraid on the other hand, to
evaluate TAO, because my first impression was "very huge" (whereas in our
application, we "only" want to use JAVA access a database backend written in
C++ and some things similar to this.
Thanks again, CU, Pi.
This is very misleading because most people will assume that
"extensive documentation" means "relevant documentation".
The webpage you indicate lists 5 sources of documentation. Let's look
at each of them to see how relevant they are to somebody who wants
to write a CORBA application.
1. Doxygen-generated documentation. From what I can see, 99.9% of this
focusses on implementation details of TAO, and only 0.1% is relevant
to somebody who just wants to use (rather than modify) TAO.
2. OCI TAO Developer's Guide. I read an older version of this. It is
good
but unfortunately costs a few hundred dollars. In practice, I think an
application development team could get by with just one copy to be
shared
between the entire team so the cost is not that big an issue. But is
it
better than the (free) comprehensive manual that comes with omniORB?
In my opinion, no. The omniORB documtantation serves the needs of
omniORB users just as well as the OCI TAO Developer's Guide
serves the needs of TAO users.
3. Remedy TAO Programmer's Guide. This guide is free. I had a quick
look and it seems to be good. A minor gripe is that the pages are
formatted in landscape instead of portrait. I guess you could view
this
as being a competitor's for the OCI TAO Developer's Guide. The omniORB
manual holds its own against both of these TAO manuals.
4. Online ORB Services Documentation. This is a link to a short
webpage
that is of interest to people who want to modify (rather than just
use) TAO.
5. Writing Pluggable Protocols. Again, this is a link to a webpage
that
is of interest to people who want to modify (rather than just use)
TAO.
In summary, of the 5 sources of documentation listed on the webage,
3 are aimed at TAO maintainers and so are irrelevant to TAO users,
and the other two are matched in terms of quality by the omniORB
documentation.
By the way, it's been several years since I looked at MICO, but I
seem to recall that it also had a good quality (and relevant) manual.
Ralf: if you're happy with omniORB then I'd suggest you stick with it.
I work for IONA (makers of Orbacus and Orbix) but have also used
omniORB and TAO. In my experience, no ORB product (whether
open- or closed-source) is perfect, but I do have fond memories
of omniORB being pleasantly simple and easy to work with.
I suggest you visit my website (www.CiaranMcHale.com) and read
the chapters on portability in "CORBA Explained Simply" and
"CORBA Utilities". If you follow the advice in those chapters then it
will make it trivial for you to migrate from omniORB to, say, TAO,
if you ever need to.
Regards,
Ciaran.
> 3. Remedy TAO Programmer's Guide. This guide is free. I had a quick
> look and it seems to be good. A minor gripe is that the pages are
> formatted in landscape instead of portrait. I guess you could view
> this
> as being a competitor's for the OCI TAO Developer's Guide. The omniORB
> manual holds its own against both of these TAO manuals.
We did generate teh document landscape so that it is optimized for screen
reading. Are there more people that would like to see a portrait version, it
is something we could add easily.
Johnny
Question:
maybe someone here have experience
in our tests we found that TAO is 30% slower in massive requests tests
then visibroker
can some one have some kind of info about batch marking tests with
different orbs?
> Question:
> maybe someone here have experience
> in our tests we found that TAO is 30% slower in massive requests tests
> then visibroker
> can some one have some kind of info about batch marking tests with
> different orbs?
Did you build a release and optimized build of TAO. TAO is normally build as
full debug version with no optimizations.
Johnny
That would be the better question... TAO is stable, why isn't the default to optimize
for speed?
-Vic
> That would be the better question... TAO is stable, why isn't the
> default to optimize for speed?
For several reasons:
. Most developers want the default behavior to be "debug mode" so they
can debug their programs easily.
. It's straightforward to compile in "release mode" to get the default
optimizations.
. There are many non-default options that can be tuned depending on
various factors (see TAO_ROOT/docs/performance.html) so no
one-size-fits-all optimization is possible.
Thanks,
Thanks for the additional info!
Besides:
> IONA (makers of Orbacus and Orbix)
Honestly, I suggested my customer to use the ORBacus, but "your people" did
not really make an acceptable offer for licence costs :(.
Actually, they did not make a real offer at all, but "talked around" and
then said they weren't interested...:-o !
If you are interested, I can tell you more on this in a PM.
BTW: IONA Germany told me, too, that ORBacus 4.0.2 would be free to use
commercially - but when I read the licence text, this does not seem to be
true, as it says "commercial use is treated in a different license", but as
OOC does not exist anymore, I don't think there is anything to be learned
about this any more, is there?
(The last question is not very urgent, actually, as it seems to require a
lot of hand work to compile ORBacus 4.0.2. with anything newer than VC6...
> That would be the better question... TAO is stable, why isn't the default
> to optimize
> for speed?
There are just a lot of options, but default it is debug. With optimizations
you can get probably about double speed and 40% smaller footprint then a
default configuration but then you have to disable features and enable
optimization which makes it harder to debug.
Johnny
Doug
If that logic is ok, then it would seem that optimization should be the default since
it will satisfy most users, and it is "just as easy" to specify building in debug for those
many-fewer users who are pushing the envelope and bleeding on the edge.
As far as not being able to guess which optimizations to make, will the average user really
care beyond the choice of -O2 or -03, for example? If you can get a 40% space improvement or double
the speed as has been reported earlier, why wouldn't you want your average user to experience that?