Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.

Dismiss

New Ice documentation available

18 views

Skip to first unread message

Michi Henning

unread,

Jul 10, 2003, 7:47:26 AM7/10/03

Hi,

we've just released a new version of the Ice documentation:

- A new chapter on the server-side run time explains useful
things such as oneway invocations, datagram invocations,
and batched invocations (the last two of which CORBA can't do ;-)

There is also quite a bit of material on how to make servers
scalable using various techniques, such as default servants
and evictors. (CORBA users should have a look and weep at
how simple things can be with properly designed APIs...)

- A new chapter on asynchronous method invocation (AMI) and
asynchronous method dispatch (AMD). AMI works along similar
lines as the CORBA version; AMD has no equivalent in CORBA:
it allows you to suspend processing of a method invocation
in the server to free up a processing thread and to then
later resume processing of that invocation again. This is
very nice if you want to build scalable blocking interfaces
(such as providing a pull model to event consumers) without
tying up thousands of threads. (The pull model for event consumers
can't be made to scale with CORBA, unfortunately.)

You can find the documentation at http://www.zeroc.com/download.html.

Enjoy!

Cheers,

Michi.

--
Michi Henning Ph: +61 4 1118-2700
ZeroC, Inc. http://www.zeroc.com

Gopi Bulusu

unread,

Jul 17, 2003, 5:27:55 AM7/17/03

Michi Henning <mi...@triodia.com> wrote in message news:<Pine.LNX.4.44.030710...@diadora.client.uq.net.au>...

> - A new chapter on the server-side run time explains useful
> things such as oneway invocations, datagram invocations,
> and batched invocations (the last two of which CORBA can't do ;-)
>
> There is also quite a bit of material on how to make servers
> scalable using various techniques, such as default servants
> and evictors. (CORBA users should have a look and weep at
> how simple things can be with properly designed APIs...)

There is nothing const or static about CORBA. It has evolved for more than
a decade and will definitely evolve for years to come. CORBA is a standard,
many CORBA products can go beyond the spec. I think comparing your product
with a standard like CORBA is comparing apples and oranges :-)

Best Regards,
gopi
---

Gopi Kumar Bulusu
Sankhya Technologies Private Limited
http://www.sankhya.com
Tel: +91 891 554 2666
Fax: +91 44 2822 7357

Michi Henning

unread,

Jul 19, 2003, 10:04:42 PM7/19/03

"Gopi Bulusu" <go...@sankhya.com> wrote in message
news:2d87f439.03071...@posting.google.com...

> Michi Henning <mi...@triodia.com> wrote in message
news:<Pine.LNX.4.44.030710...@diadora.client.uq.net.au>...
>

> > There is also quite a bit of material on how to make servers
> > scalable using various techniques, such as default servants
> > and evictors. (CORBA users should have a look and weep at
> > how simple things can be with properly designed APIs...)
>
> There is nothing const or static about CORBA. It has evolved for more than
> a decade and will definitely evolve for years to come.

Having written large sections of the CORBA specification myself, I am aware of
that.
I am also aware of the impossibility to rectify even minor flaws in CORBA, let
alone
the major ones (and, believe me, I have tried).

> CORBA is a standard,
> many CORBA products can go beyond the spec.

Unfortunately, the CORBA standard is stuck in a quagmire, I believe. There has
been
little activity in last two years or so. Specifications are produced that are
never implemented,
and bugs in the specification take ages to fix, or are never fixed at all. What
is worse,
most specifications are the kitchen sink of every feature ever dreamed of by
anyone ever;
the resulting platform and APIs are horrendously complex and take years to get
proficient
at. Having lived and breathed CORBA for nearly a decade, I still have to
consult my own
book when I write CORBA code that is even a little out of the ordinary. It
doesn't have to
be as complex as that. Moreover, the complexity and (mis)feature insanity of
the
specifications hugely complicates the ORB implementation. The result is a run
time that is
far slower and far larger than necessary. (Again, as an ORB implementer of many
years,
I speak from experience.)

Then add the ongoing vendor attrition into the picture, plus the OMG's changed
focus
on MDA instead of getting its middleware fixed, and the picture isn't all that
pleasant.
(If you are interested in more reasons for why I believe that CORBA isn't the
answer,
have a look at the introduction to the Ice documentation at
http://www.zeroc.com/download.html.)

> I think comparing your product
> with a standard like CORBA is comparing apples and oranges :-)

Ice is similar to CORBA in many ways: it gives you language and platform
neutral OO RPC,
just like CORBA. It provides all of the features of CORBA (but does it in ways
that are much
simpler and more efficient), and it adds some features of its own that CORBA
does not provide,
such as interface aggregation, asynchronous method dispatch, UDP transport, and
others. I don't
think that is comparing apples and oranges. In fact, Ice is what CORBA should
have been all
along, but never could be because it is weighed down by its mistakes of the
past and by its
design by committee.

You are right, Ice doesn't have a standards base like CORBA does. But, on the
other hand,
how much has the CORBA standardization really achieved for people? I have been
involved with
several projects that decided to switch ORB implementations at some stage
during development.
In all cases, the experience wasn't pretty:

- The much-lauded source code compatibility in practice does not exist. ORBs
are usually full
of vendor-specific extensions (often not clearly identified as such) that can
make it very difficult
to port existing code to a new ORB.

- The specification is insufficiently tight to guarantee source code
compatibility, even if you are
strictly sticking to code that is based on the standard: for example, header
file names are not
standardized, there is no threading API or even a usable behavior model for
threads, the files
that are produced by an IDL compiler are unspecified in number and name, etc,
etc.

- Large and important parts of what you need to specify CORBA are not
standardized at all:
implementation repositories, configuration of all the services, build
environment, administration,
etc.

The net effect of all this is that there are hundreds of things that are not
addressed in the specification,
but that need to be taken care of when changing ORBs. In practice, people have
to re-engineer
the build environment, administrative tools, and testing tools, not to mention
the various bits
of source code. Given all this, standardization has added comparatively little.

In fact, I would argue that the burden the standard has imposed on the platform
in terms of poor
run-time performance, footprint, and complexity may well overwhelm any of the
benefits: in practice,
once you develop with an ORB from a specific vendor, it is very difficult (and
very expensive) to
get away from that vendor. That then begs the question of where the benefits of
standardization are
to be found.

Ice is proprietary, to be sure, but all the APIs, language mappings, and the
protocol are well
documented, and anyone is welcome to create something that interoperates with
Ice. In return,
I get a platform that is more powerful than CORBA, doesn't take years to learn,
is simple
and coherent, and scales and performs better (and does that in a smaller
footprint). To me,
that makes it worth at least a closer look.

Douglas C. Schmidt

unread,

Jul 20, 2003, 7:36:02 PM7/20/03

Hi Folks,

I just got back from spending a week at the OMG Real-time
Middleware conference and the TAO workshop in Washington DC, which
focused on a variety of topics pertaining to the use of multiple CORBA
ORBs (ORBexpress, TAO, e*ORB, orb2, etc.) for distributed real-time
and embedded (DRE) systems. These were very high energy meetings,
with CORBA users from Boeing, Lockheed Martin, Raytheon, BAE Systems,
BBN, Thales, Siemens, Qualcomm, and many other major companies
attending and presenting material based on their experiences with
CORBA and Real-time CORBA. Many of the topics that Michi brings up
below were discussed at those meetings, so I wanted to provide my
thoughts below.

>> Having written large sections of the CORBA specification myself, I
>> am aware of that. I am also aware of the impossibility to rectify
>> even minor flaws in CORBA, let alone the major ones (and, believe
>> me, I have tried).

There's no question (in my mind) that the CORBA specification and
revision process has flaws. Things do seem to get fixed, however,
albeit not at the rate I'd like to see. Your statement above reminds
me of the classic de-motivational poster
<www.cs.wustl.edu/~schmidt/demotivation.html> that says "You'll always
miss 100% of the shots you don't take - and statistically speaking 99%
of the ones you do!" In other words, if people don't participate in
the CORBA process then it's guaranteed that stuff will not get fixed,
but even being involved doesn't guarantee success.

>> Unfortunately, the CORBA standard is stuck in a quagmire, I
>> believe. There has been little activity in last two years or
>> so.

I disagree, though we may care about different parts of the OMG CORBA
spec. At this point, TAO implements major parts of CORBA 3.0 and
we're focusing our attention on the recent Lightweight CCM
specification <http://www.omg.org/cgi-bin/doc?realtime/2003-05-05> and
the updated Deployment and Configuration spec
<http://www.omg.org/cgi-bin/doc?mars/2003-05-08>. As these
specifications are adopted and implemented, CCM will be a great
approach for DRE systems.

>> Specifications are produced that are never implemented, and bugs in
>> the specification take ages to fix, or are never fixed at all. What
>> is worse, most specifications are the kitchen sink of every feature
>> ever dreamed of by anyone ever; the resulting platform and APIs are
>> horrendously complex and take years to get proficient at.

I think that's largely FUD Michi - I'm surprised to hear you talk like
this - you sound like Don Box or Roger Sessions! At UC Irvine, Wash
U., and Vanderbilt U where I've taught, we regularly teach ugrads and
grads how to program CORBA with C++ in about 6-8 weeks (using your
book ;-)). Sure, there are some dark corners of CORBA and C++, but it
certainly doesn't take *years* to become proficient!

>> Having lived and breathed CORBA for nearly a decade, I still have
>> to consult my own book when I write CORBA code that is even a
>> little out of the ordinary. It doesn't have to be as complex as
>> that.

There's no question that CORBA could be simpler - especially given the
benefit of hindsight (and the lack of SOM compatibility in the early
days ;-)). However, it's also clear that UNIX, C, C++, C#, Perl,
Windows, X-Windows, MFC, ACE, SOAP, COM/DCOM, .NET, Java, J2EE,
Real-time Java, etc. all have accidental complexities and warts that
leave something to be desired. While it would be nice to throw them
all out and start from scratch, that's not always possible/sensible.
Moreover, most large-scale projects have infrastructure teams whose
role is to "hide" the COTS middleware behind their own domain-specific
wrapper facades, so the fact that a new technology is defined to hide
some quirks of existing middleware often doesn't really matter all
that much in practice.

>> Moreover, the complexity and (mis)feature insanity of the
>> specifications hugely complicates the ORB implementation. The
>> result is a run time that is far slower and far larger than
>> necessary.

Perhaps as a result of spending time with Bill Beckwith (OIS) and Sam
Aslam-Mir (PrismTech) last week has corrupted my mind irreparably, but
it seems to me that their ORBs (ORBexpress and e*ORB, respectively)
are REMARKABLY fast and small. In fact, it would amaze me if ICE were
as fast and small as either ORBexpress or e*ORB for DRE systems. I
recommend you contact Gautam Thaker <gth...@atl.lmco.com> and get him
to add comparisons of ICE and e*ORB to his "Middleware Comparator
page" at

http://www.atl.external.lmco.com/projects/QoS/compare/dist_oo_compare2.html

(ORBexpress is already there). This would go a long way to help
substantiate/debunk your claims above.

>> (Again, as an ORB implementer of many years, I speak from
>> experience.)

Not to take anything away from your experience Michi, but the folks
who are implementing the cutting edge Real-time and Embedded CORBA
ORBs have done some AMAZING things. As usual, however, the proof is
in the benchmarks, so let's see if we can get Gautam and his team to
settle this issue for us empirically and objectively.

>> Then add the ongoing vendor attrition into the picture, plus the
>> OMG's changed focus on MDA instead of getting its middleware fixed,
>> and the picture isn't all that pleasant.

Actually, the current situation for CORBA ORBs in the DRE domain is
looking quite pleasant. There are a number of very healthy ORB
vendors (OIS, OCI, PrismTech) whose products (ORBexpress, TAO, e*ORB,
and JacORB) work well and interoperate nicely. Since several of these
ORBs are open-source (TAO and JacORB), there are also very large and
active communities involved in improving many aspects of these ORBs
around the clock and around the world. Check out

http://www.cs.wustl.edu/~cdgill/TAO03/

and

http://www.dre.vanderbilt.edu/scoreboard/

for some examples of these active communities in just the TAO
community alone.

>> (If you are interested in more reasons for why I believe that CORBA
>> isn't the answer, have a look at the introduction to the Ice
>> documentation at http://www.zeroc.com/download.html.)

Michi, again with all due respect, you now work for a company that's
selling a product that's aiming to compete directly with CORBA, so I'm
not the LEAST BIT surprised that you'd no longer believe that CORBA is
the answer!! For some wry irony, BTW, take a look at the arguments
that you had with Roger Sessions when he had a similar "conversion" in
the mid-90s ;-).

>> Ice is similar to CORBA in many ways: it gives you language and
>> platform neutral OO RPC, just like CORBA. It provides all of the
>> features of CORBA (but does it in ways that are much simpler and
>> more efficient),

Let's wait and see what Gautam's experiments show before accepting
that ICE is "much more efficient" than the state-of-the-art DRE ORBs!

>> and it adds some features of its own that CORBA does not provide,
>> such as interface aggregation, asynchronous method dispatch, UDP
>> transport, and others. I don't think that is comparing apples and
>> oranges. In fact, Ice is what CORBA should have been all along, but
>> never could be because it is weighed down by its mistakes of the
>> past and by its design by committee.

I'm not going to argue with you that CORBA couldn't be better.
However, if the history of the past 40+ years tells us anything, it's
that technologies rarely succeed because they are "cleaner" than their
alternatives. If you consider the list I gave above, you'll find that
there are lots of cleaner alternatives (particular for C and UNIX)
that never caught on because users were looking for other properties,
such as portability, interoperability, availability, longevity,
legacy, etc.

>> You are right, Ice doesn't have a standards base like CORBA
>> does. But, on the other hand, how much has the CORBA
>> standardization really achieved for people?

Sigh... You *have* been possessed by the ghost of Don and Roger,
haven't you? ;-)

>> I have been involved with several projects that decided to switch
>> ORB implementations at some stage during development. In all
>> cases, the experience wasn't pretty:

Perhaps that's because people were switching from older versions of
Orbix to newer, standards-compliant ORBs? I agree that this is a
painful process, though one that once done makes life MUCH better for
future migrations.

>> - The much-lauded source code compatibility in practice does not
>> exist. ORBs are usually full of vendor-specific extensions (often
>> not clearly identified as such) that can make it very difficult to
>> port existing code to a new ORB.

Again, this is simply FUD Michi. If you check out

http://www.cs.wustl.edu/~cdgill/TAO03/

and

http://www.omg.org/news/meetings/realtime2003/Program.pdf

you'll see there were talks by Raytheon, BAE Systems, Boeing, and
Lockheed Martin last week describing their experiences developing and
porting MAJOR (i.e., million lines of C++ and CORBA code)
mission-critical DoD combat systems and radio systems using multiple
ORBs. The basic consensus was that as long as you stick with "good"
ORBs (i.e., the ones I mentioned earlier that are compliant with the
CORBA spec) and use available tools (such as CORBA auto-conf
<http://corbaconf.kiev.ua>) the porting process is straightforward.

In fact, in talking with the speakers mentioned above, they said they
are regularly develoing their systems with both ORBexpress and TAO in
order to ensure they are remaining compliant with the standard APIs.
The bottom line is that it's really no harder to develop portable
CORBA applications now than it is to develop portable UNIX and Windows
applications. Ironically, the open-source community has contributed a
considerable amount to simplifying the portability and
interoperability of both operating systems and ORBs.

>> - The specification is insufficiently tight to guarantee source
>> code compatibility, even if you are strictly sticking to code that
>> is based on the standard: for example, header file names are not
>> standardized, there is no threading API or even a usable behavior
>> model for threads, the files that are produced by an IDL compiler
>> are unspecified in number and name, etc, etc.

Give me a break Michi. This is NO different than for UNIX, Windows,
and real-time embedded operating systems, which are MUCH more diverse
than today's leading CORBA ORBs. As usual, there are a
straightforward set of patterns and tools to apply to make this work
fine in practice (not unlike what we've done with ACE, which makes
cross-platform C++ concurrent network programming straightforward).
Again, the CORBA auto-conf tool <http://corbaconf.kiev.ua> makes life
much easier.

>> - Large and important parts of what you need to specify CORBA are
>> not standardized at all: implementation repositories, configuration
>> of all the services, build environment, administration, etc.

The CORBA Component Model is addressing some of these issues - and
there are an increasing number of CCM implementations coming online
(check out Diego's http://www.ditec.um.es/~dsevilla/ccm/ page for more
details). Moreover, it's not really clear what your point is here
since ICE's solutions for all of these capabilities are even less
standardized than CORBA! Moreover, ICE will need to provide many
other non-standard services (e.g., transitions, fault tolerance,
real-time, load balancing, component models, etc.) to compete with the
more advanced CORBA, J2EE, and .NET offerings, so it sounds like
you're largely reinventing the wheel and causing MORE interoperability
and portability problems for the developer and user community!

Given that the distributed computing middleware market is incredibly
crowded, with lots of very good products (many of which are freely
available and commercially supported) it's not really clear what the
value-added is for a proprietary middleware product like ICE that's
not going to have a major 800 pound gorilla company or standards group
to "adopt" and promote it, a la SOAP, J2EE, .NET, CORBA, etc., which
means that it's likely to remain a niche technology.

>> The net effect of all this is that there are hundreds of things
>> that are not addressed in the specification, but that need to be
>> taken care of when changing ORBs.

I'm not sure if the number is "dozens" or "hundreds," but in either
case based on the experiences of the groups at last week's meetings
this problem appears straightforward to solve in practice - especially
once you're using "modern" ORBs.

>> In practice, people have to re-engineer the build environment,
>> administrative tools, and testing tools, not to mention the various
>> bits of source code. Given all this, standardization has added
>> comparatively little.

I disagree - and the examples cited above provide evidence of the
value of standards.

>> In fact, I would argue that the burden the standard has imposed on
>> the platform in terms of poor run-time performance, footprint, and
>> complexity may well overwhelm any of the benefits:

Again, let's see the actual numbers that Gautam's team can produce
before you declare victory ;-). BTW, I'm more than willing to
publically "eat crow" on this if the numbers bear it out!

>> in practice, once you develop with an ORB from a specific vendor,
>> it is very difficult (and very expensive) to get away from that
>> vendor.

Perhaps if you're (1) using Orbix 3.x or earlier or (2) go out of your
way to program to ORB-specific details. But this is now largely a
failure of process, not technology. The tools, patterns, and
techniques for writing portable/interoperable CORBA apps are widely
available (and increasingly used in practice) - so there's no (good)
excuse for not being vendor-independent these days.

>> That then begs the question of where the benefits of
>> standardization are to be found.

Fortunately, this (begged) question is now largely moot, as per the
discussion above ;-)

>> Ice is proprietary, to be sure, but all the APIs, language
>> mappings, and the protocol are well documented, and anyone is
>> welcome to create something that interoperates with Ice. In return,
>> I get a platform that is more powerful than CORBA, doesn't take
>> years to learn, is simple and coherent, and scales and performs
>> better (and does that in a smaller footprint). To me, that makes it
>> worth at least a closer look.

At last something we can agree on Michi! It definitely makes sense to
take a good look at ICE (and everything else that's available to solve
similar problems) - that's what "due diligence" is all about.
Moreover, I'm *certain* that good designers and programmers like you
guys can come up with a cleaner/better distributed object computing
model than CORBA!

My sense, however, is that ICE will have success with the "early
adopter" technologist market, but will have difficulty crossing the
chasm to be a mainstream product at the level of adoption of CORBA,
.NET, SOAP, or J2EE. A good analogy in the OS world would be
something like the Be OS, OS/2, or NextSTEP, which were cool
technologies that were much cleaner than their competition (i.e.,
Windows ;-)), but which didn't catch on in the mainstream market.
Ultimately the mass market of technology users don't select their
tools and platforms because they are "cool" but because they address
other key functional and non-functional forces. I guess Richard
Gabriel really was right in his infamous "Worse is Better" screed...

To wrap up this round of the debate (since I know Michi won't let me
get the last word yet ;-)) let me close with the following. I respect
the work that you ICE folks have done. I think you guys are REALLY
smart, do GREAT work, and I'd like to see you SUCCEED. It bugs me,
however, when you start spewing FUD about CORBA that simply doesn't
hold up under closer inspection. Assuming ICE is as good as you say
it is, you should be able to sell it on its merits, rather than
resorting to Box/Sessions tactics.

Take care,

Doug
--
Dr. Douglas C. Schmidt, Professor TEL: (615) 343-8197
Electrical Engineering and Computer Science FAX: (615) 343-7440
Vanderbilt University WEB: www.cs.wustl.edu/~schmidt/
Nashville, TN 37203 NET: d.sc...@vanderbilt.edu

Marc Laukien

unread,

Jul 20, 2003, 11:17:27 PM7/20/03

Doug,

I'm a bit surprised by the tone of your email. Is it really necessary to
attack Michi like this? Comparisons with the persons you mentioned seem
hardly be appropriate. After all Michi did *a lot* for CORBA, such as
writing parts of an ORB, co-authoring a well-respected CORBA book,
working on many CORBA specs, and last but not least giving a lot of free
CORBA support in this newsgroup. I don't recall any of the other persons
you compared Michi with doing any of this.

In any case, I would like to comment on the "efficiency" aspects. I let
Michi comment on the other aspects of your email.

Efficiency can mean a lot of things. If you mean raw throughput and
latency, then yes, ORBexpress is faster. You might want to have a look at:

http://www.zeroc.com/vbulletin/showthread.php?threadid=27

In one of the postings in this thread, I wrote:

"[The test] shows better performance for Ice for small messages, and
better performance for TAO for large messages. As for OrbExpressRT, I
must admit that we can't reach their performance."

So, I never claimed that Ice is the fastest middleware. After all, it's
not a real-time ORB. It's a multi-purpose ORB, and I'm sure if you
compare it with other multi-purpose ORBs, you will find that Ice will be
one of the fastest. (We are thinking about a Realtime-Ice, but this is
not concrete yet.)

However, efficiency is not only latency and throughput. There are other
factors which are important as well:

- Bandwidth consumption: Ice offers a very compact data encoding format.
Have a look at the Ice protocol chapter for details. For some data
types, the difference between IIOP and the Ice protocol can be huge. And
on top of that, Ice offers protocol compression out of the box. This
means that Ice is also usable for low-bandwidth connections, such as modems.

- Message passing: In many cases, you need to pass through messages,
such as with routers or event distribution services. Ice can do this
much more efficiently than CORBA with IIOP, because requests are
self-contained and in encapsulations.

- There are other "tricks" in Ice to improve efficiency, such as batch
requests (sending several one-way messages in one batch instead of in
lots of little messages). There is no equivalent in CORBA for this.

- Efficiency also means resource consumption. We found that Asynchronous
Message Dispatch is very important for efficient servers. Again, CORBA
doesn't offer anything like this.

- Last but not least you also need efficient data storage. Freeze (our
persistence service) is quite efficient, and is very easy to use.

I also really don't want to start a Ice vs. CORBA flame war. Let me
quote from http://www.zeroc.com/iceVsCorba.html:

"First of all, we neither wish to start a "CORBA vs. Ice" flame war nor
do we want to discredit CORBA. On the contrary, we believe that CORBA
was a great achievement for its time, and obviously Ice borrows many
good ideas from CORBA.

We decided to write this comparison because we expect that many people
will rightfully ask us why they should use Ice instead of CORBA. Our
general answer is, why not try out Ice for yourself? We are certain that
once you've used Ice for some time, you won't ever want to go back to
CORBA. Believe us, it's easy to fall in love with Ice, because of its
beauty and simplicity, its architectural consistency, and last but not
least its vast array of features and tools."

-- Marc

Michi Henning

unread,

Jul 21, 2003, 1:37:35 AM7/21/03

On 20 Jul 2003, Douglas C. Schmidt wrote:

> Michi Henning wrote:

> >> Having written large sections of the CORBA specification myself, I
> >> am aware of that. I am also aware of the impossibility to rectify
> >> even minor flaws in CORBA, let alone the major ones (and, believe
> >> me, I have tried).
>
> There's no question (in my mind) that the CORBA specification and
> revision process has flaws. Things do seem to get fixed, however,
> albeit not at the rate I'd like to see.

Well, depends on what you mean by "getting fixed". For example, IDL
constant expression semantics have been undefined for a long time. The
issue was raised on 15 April 1998 and closed on April 23 2003, five
years later. Of course, the issue hasn't been fixed because there are
still a lot of things unspecified about constant expression evaluation,
such as overflow and coercion semantics, as well as the meaning of the
bitwise operators.

Other examples:

- potential deadlock with POA::deactivate_object() (opened
28 June, 1999, still open)

- Custom marshling for value types makes it impossible for
bridges to operate correctly (opened December 1999, still
open)

- Object::get_policy() not implementable for
portable-interceptor policies (opened 18 November 2000, still
open)

Need I go on? And we haven't even talked about the built-in defects that
no-one ever raises as a defect. Examples abound:

- The ridiculous marshaling rules of IIOP, with padding for no
purpose other than to waste bandwidth.

- The inability to version IIOP properly, due the fact that the
encoding isn't versioned separately from the protocol state
machine. As a result, CORBA cannot interoperate even with
itself. (For example, there is nothing to prevent an Any
containing a fixed-point value to travel to an ORB that
doesn't understand that version of IIOP, with no way to
diagnose the problem other than inexplicable marshaling
errors.)

- The huge internal complexity of IORs which, with their opaque
parts, make marshaling expensive and force creation of services
such as the bootstrap and naming service, who are not needed
at all with a design that avoids this complexity.

- The fact that there still is nothing like a usable security
model an implementation of which that I could buy from a vendor
and then use to securely operate through firewalls.

- The lack of a threading model that would give semantics other
than "the ORB may choose to create more than one thread, or it
may not do that".

- The continuing absence of a scalable event service or a UDP
transport.

- The sillyness of location-forward messages with the
concomitant inability to migrate implementation repositories
when one look at the DNS is sufficient to see that there is a
far better alternative.

- The complexity of the POA specification with its mess of
policies when, in reality, three or four different
implementation techniques are all that needs to be supported
in every application scenario I have ever come across.

- The C++ mapping with it's memory-management and complexity
problems that is a major source of bugs and simply sucks.
(Bjarne Stroustrup has called it "awful.")

- The large number of specifications that exist on paper that I
cannot implement, not buy an implementation for, or not buy an
implementation for from more than one vendor.

The list could be extended considerably.

> Your statement above reminds
> me of the classic de-motivational poster
> <www.cs.wustl.edu/~schmidt/demotivation.html> that says "You'll always
> miss 100% of the shots you don't take - and statistically speaking 99%
> of the ones you do!" In other words, if people don't participate in
> the CORBA process then it's guaranteed that stuff will not get fixed,
> but even being involved doesn't guarantee success.

Yes. A look at the issue list confirms that.

> >> Unfortunately, the CORBA standard is stuck in a quagmire, I
> >> believe. There has been little activity in last two years or
> >> so.
>
> I disagree, though we may care about different parts of the OMG CORBA
> spec. At this point, TAO implements major parts of CORBA 3.0 and
> we're focusing our attention on the recent Lightweight CCM
> specification <http://www.omg.org/cgi-bin/doc?realtime/2003-05-05> and
> the updated Deployment and Configuration spec
> <http://www.omg.org/cgi-bin/doc?mars/2003-05-08>. As these
> specifications are adopted and implemented, CCM will be a great
> approach for DRE systems.

Doug, I haven't been talking about distributed real-time systems, I've
been talking about general-purpose middleware. They are certainly
different. And, it really begs the question: why is it that the CCM
specification was adopted in 1999 and now, in 2003, has to be redone?
Why is it that, as far as I know, therer is not a single commercial
implementation of that specification? Why is it that one of the major
design goals, namely, to allow a third party without access to the ORB
source to implement CCM, was missed? Why is it that the major design hook
for this feature (Object::get_component()) was removed from the specification?

Why is it that so many CORBA specifications are not worth the paper they
are written on and are never implemented? Need I remind you of the Cos
services debacle? Or the much-heralded multicast specification that is
still not implemented, to the best of my knowledge? How much credibility
is there in an organization that continues to publish documents such as
this (despite my best efforts as an Architecture Board member to inject
some reality into the process and to prevent these embarrassing incidents)?

> >> Specifications are produced that are never implemented, and bugs in
> >> the specification take ages to fix, or are never fixed at all. What
> >> is worse, most specifications are the kitchen sink of every feature
> >> ever dreamed of by anyone ever; the resulting platform and APIs are
> >> horrendously complex and take years to get proficient at.
>
> I think that's largely FUD Michi - I'm surprised to hear you talk like
> this - you sound like Don Box or Roger Sessions!

Two things here Doug:

- I don't believe this is FUD. For example, the trader specification is a joke
in terms of its complexity (and never mind the large number of semantic
conflicts that can be caused by policies, with no word in the
specification as how to deal with them). The POA API is well over
twice as large as it needs to be for its functionality because
orthogonal concepts were never worked as cleanly as they should
have been. There are numerous other examples along similar lines. And,
small wonder that most OMG specs are the kitchen sink of complexity:
the only way to get agreement is to accommodate the wishes of just
about every vendor present...

- I believe that there are very few people in the world who can
claim to have worked harder or longer than myself on developing CORBA,
specifying CORBA, teaching CORBA, promoting CORBA, fixing CORBA,
or implementing CORBA. To put me on a level here with Roger Sessions,
(who had a very personal axe to grind with the OMG) is both
inappropriate and in bad taste, IMO.

> At UC Irvine, Wash
> U., and Vanderbilt U where I've taught, we regularly teach ugrads and
> grads how to program CORBA with C++ in about 6-8 weeks (using your
> book ;-)). Sure, there are some dark corners of CORBA and C++, but it
> certainly doesn't take *years* to become proficient!

Well, I have taught CORBA to well over a thousand engineers over the
years, many of whom were highly-experienced professionals with many
years of software development experience. They didn't think it was easy --
they settled on CORBA simply because it was the best thing going for the
job. After nearly a decade of having lived and breathed CORBA, I really
have to look things up in my own book when I write CORBA code. Yes, really.
I simply can't remember the incoherent and complex mess of APIs, memory
management rules, inconsistent naming conventions, and needless
verbosity.

And, forgive me, no matter how good a course you teach or how
good a book Steve and I might have written, no-one learns CORBA in 6-8
weeks to the point where they can create industrial-strength
applications. Distributed computing in general, and CORBA in particular,
are far too complex for that.

> There's no question that CORBA could be simpler - especially given the
> benefit of hindsight (and the lack of SOM compatibility in the early
> days ;-)). However, it's also clear that UNIX, C, C++, C#, Perl,
> Windows, X-Windows, MFC, ACE, SOAP, COM/DCOM, .NET, Java, J2EE,
> Real-time Java, etc. all have accidental complexities and warts that
> leave something to be desired. While it would be nice to throw them
> all out and start from scratch, that's not always possible/sensible.

Well, we think that is possible and sensible. By that argument, we would
have to live with every wart and bad design ever invented by anyone, and
we are certainly not doing that. (How many DOS programs get written
these days? Or how many DCE programs, for that matter? And DCE
proponents had much the same things to say about CORBA when it was
new...)

> Moreover, most large-scale projects have infrastructure teams whose
> role is to "hide" the COTS middleware behind their own domain-specific
> wrapper facades, so the fact that a new technology is defined to hide
> some quirks of existing middleware often doesn't really matter all
> that much in practice.

Hmmm... I can't say I like this line of reasoning. It really boils down
to "Well, we can always put another layer of abstraction on top, so the
bad design of the layer below doesn't matter." Far too much in computing
is done with kind of attitude, to the detriment of the entire industry.

> >> Moreover, the complexity and (mis)feature insanity of the
> >> specifications hugely complicates the ORB implementation. The
> >> result is a run time that is far slower and far larger than
> >> necessary.
>
> Perhaps as a result of spending time with Bill Beckwith (OIS) and Sam
> Aslam-Mir (PrismTech) last week has corrupted my mind irreparably, but
> it seems to me that their ORBs (ORBexpress and e*ORB, respectively)
> are REMARKABLY fast and small. In fact, it would amaze me if ICE were
> as fast and small as either ORBexpress or e*ORB for DRE systems. I
> recommend you contact Gautam Thaker <gth...@atl.lmco.com> and get him
> to add comparisons of ICE and e*ORB to his "Middleware Comparator
> page" at
>
> http://www.atl.external.lmco.com/projects/QoS/compare/dist_oo_compare2.html
>
> (ORBexpress is already there). This would go a long way to help
> substantiate/debunk your claims above.

Doug, please! Comparing a dedicated real-time ORB with a general-purpose
ORB or middleware platform such as Ice is inappropriate, and you know
that. Last time I looked, e-ORB was certainly very fast (and it appears
to be a fine product for its market), but it only provided a small
subset of the CORBA spec, and certainly wasn't standard compliant.

BTW, Gautam has already done some benchmarks on Ice and, for what it's
worth, Ice appears to be remarkably fast. (See
http://www.zeroc.com/vbulletin/showthread.php?s=74b49746368e034316f1d319b163289b&threadid=27 for details.)

> >> (Again, as an ORB implementer of many years, I speak from
> >> experience.)
>
> Not to take anything away from your experience Michi, but the folks
> who are implementing the cutting edge Real-time and Embedded CORBA
> ORBs have done some AMAZING things. As usual, however, the proof is
> in the benchmarks, so let's see if we can get Gautam and his team to
> settle this issue for us empirically and objectively.

Well, if you insist on comparing apples and oranges, of course.
ORBacus/E also is faster than Ice. But ORBacus/E is a dedicated
embedded effort and not fully compliant with the CORBA spec. And
ORBacus/E is unsuitable as a general-purpose middleware, just as many,
if not all, of the embedded and real-time ORBs are.

> >> Then add the ongoing vendor attrition into the picture, plus the
> >> OMG's changed focus on MDA instead of getting its middleware fixed,
> >> and the picture isn't all that pleasant.
>
> Actually, the current situation for CORBA ORBs in the DRE domain is
> looking quite pleasant.

You keep talking about real-time and embedded ORBs, not general-purpose
ORBs. Where are all the general-purpose ORBs? Where is BEA's ORB these
days? Or IBM's? Or Expersoft's? Or Rogue Wave's? How much vendor choice
do I have left when I'm looking for CORBA these days?

> There are a number of very healthy ORB
> vendors (OIS, OCI, PrismTech) whose products (ORBexpress, TAO, e*ORB,
> and JacORB) work well and interoperate nicely. Since several of these
> ORBs are open-source (TAO and JacORB), there are also very large and
> active communities involved in improving many aspects of these ORBs
> around the clock and around the world. Check out
>
> http://www.cs.wustl.edu/~cdgill/TAO03/
>
> and
>
> http://www.dre.vanderbilt.edu/scoreboard/
>
> for some examples of these active communities in just the TAO
> community alone.

Completely agree. In fact, the Open Source communities have definitely
done a lot for CORBA (much more than the commercial vendors, IMO). But I
also believe that, as long as these ORBs adhere to an aging and clumsy
specification, they will never come anywhere near their full potential.

CORBA was a great thing in its day. But the specification process is too
inflexible, and fundamental design problems (such as the inability to
version IIOP properly) make it just about impossible to incorporate
technical improvements into the platform. As a former OMG Architecture
Board member, I can definitely assure you that topics like fixing IIOP
make people's hair stand on end, due to the immense technical and
marketing difficulty of doing so, plus the weight of legacy and backward
compatibility issues.

> >> (If you are interested in more reasons for why I believe that CORBA
> >> isn't the answer, have a look at the introduction to the Ice
> >> documentation at http://www.zeroc.com/download.html.)
>
> Michi, again with all due respect, you now work for a company that's
> selling a product that's aiming to compete directly with CORBA, so I'm
> not the LEAST BIT surprised that you'd no longer believe that CORBA is
> the answer!! For some wry irony, BTW, take a look at the arguments
> that you had with Roger Sessions when he had a similar "conversion" in
> the mid-90s ;-).

Doug, see above -- I believe that comparison with Roger is singularly
inappropriate here. I have spent many years doing CORBA, and I am generally
recognized as one of the world's experts on the topic. And I am sick of
doing things the hard way when they can be so much easier. I am not
trying to throw mud at CORBA. (I personally invested far too much of
myself in CORBA for that). But I want to point out that some of the arguments
for CORBA should be examined more closely: by and large, the benefits of
standardization of CORBA have not been realized. Vendors insist on
adding their own extensions (often incompatible with the specification),
much of what is needed is underspecified, and the much-touted freedom of
choosing a vendor largely does not exist: even with 100% CORBA
compliance, another vendor may not support the platform I need, may not
provide the language mapping I need, may not support the compiler I
need, or may not implement the particular part of the CORBA spec I need.
Realistically, there is little choice of vendor in many situations (not
all situations, I freely admit).

> >> Ice is similar to CORBA in many ways: it gives you language and
> >> platform neutral OO RPC, just like CORBA. It provides all of the
> >> features of CORBA (but does it in ways that are much simpler and
> >> more efficient),
>
> Let's wait and see what Gautam's experiments show before accepting
> that ICE is "much more efficient" than the state-of-the-art DRE ORBs!

Doug, of course Ice is not as efficient as a real-time ORB! Why do you
keep comparing a general-purpose platform with a general-purpose one?
We believe that Ice is faster than any general-purpose ORB. And it
provides that performance with APIs that are a fraction of CORBA's
in complexity, and with a smaller footprint. And, to boot, it provides
features that neither general-purpose nor DRE CORBA implementations can
provide: a persistence service that is incredibly easy to use,
asynchronous method dispatch, an efficient protocol that doesn't waste
bandwidth, compression on the wire, security, etc. (Where is CORBA's security?
Please don't tell me about the firewall spec which, apart from the
complexity of administering all this machinery, requires every firwall
vendor in the world to make extensive changes to their product -- how
realistic is that?)

> I'm not going to argue with you that CORBA couldn't be better.
> However, if the history of the past 40+ years tells us anything, it's
> that technologies rarely succeed because they are "cleaner" than their
> alternatives. If you consider the list I gave above, you'll find that
> there are lots of cleaner alternatives (particular for C and UNIX)
> that never caught on because users were looking for other properties,
> such as portability, interoperability, availability, longevity,
> legacy, etc.

Right. Technical excellence alone is (unfortunately) rarely enough. Yet,
it does matter. If it didn't, we'd all still be using DCE or raw
sockets, and CORBA would never have happened either.

> >> You are right, Ice doesn't have a standards base like CORBA
> >> does. But, on the other hand, how much has the CORBA
> >> standardization really achieved for people?
>
> Sigh... You *have* been possessed by the ghost of Don and Roger,
> haven't you? ;-)

I don't think this answers my question. Again, how much has the CORBA
standardization really achieved for people? Not a lot, IMO.

> >> I have been involved with several projects that decided to switch
> >> ORB implementations at some stage during development. In all
> >> cases, the experience wasn't pretty:
>
> Perhaps that's because people were switching from older versions of
> Orbix to newer, standards-compliant ORBs?

No, I'm not talking about BOA-to-POA transitions here, I'm talking
switching from things such as Orbix 2000 to ORBacus, or Visibroker to
TAO.

> I agree that this is a
> painful process, though one that once done makes life MUCH better for
> future migrations.

Well, why is it painful if things are supposedly so well standardized?
You mean painful because of the BOA? But the BOA was a standard too!
Bidirectional IIOP and CORBA security were standards too, as I recall. What
has become of those?

> >> - The much-lauded source code compatibility in practice does not
> >> exist. ORBs are usually full of vendor-specific extensions (often
> >> not clearly identified as such) that can make it very difficult to
> >> port existing code to a new ORB.
>
> Again, this is simply FUD Michi. If you check out
>
> http://www.cs.wustl.edu/~cdgill/TAO03/
>
> and
>
> http://www.omg.org/news/meetings/realtime2003/Program.pdf

No, that's not FUD, that is first-hand experience I have gathered over the
years. The amount of effort to simply change a Clearcase-based
development environment alone to a different ORB is staggering. And we
haven't talked about the need to use different tools to administer the
whole thing, the changes in testing procedures, the changes in
deployment of services, etc. This things impose a considerable cost.

> you'll see there were talks by Raytheon, BAE Systems, Boeing, and
> Lockheed Martin last week describing their experiences developing and
> porting MAJOR (i.e., million lines of C++ and CORBA code)
> mission-critical DoD combat systems and radio systems using multiple
> ORBs. The basic consensus was that as long as you stick with "good"
> ORBs (i.e., the ones I mentioned earlier that are compliant with the
> CORBA spec) and use available tools (such as CORBA auto-conf
> <http://corbaconf.kiev.ua>) the porting process is straightforward.

Doable? Yes. Straightforward? In some cases. Cheap? Never.

> In fact, in talking with the speakers mentioned above, they said they
> are regularly develoing their systems with both ORBexpress and TAO in
> order to ensure they are remaining compliant with the standard APIs.

Well, if they really were compliant, I wouldn't have to develop for two
ORBs in parallel, just to be sure, would I?

> The bottom line is that it's really no harder to develop portable
> CORBA applications now than it is to develop portable UNIX and Windows
> applications.

Right. And that is far too hard. It shouldn't be that hard, and it need
not be, as Ice demonstrates.

> Ironically, the open-source community has contributed a
> considerable amount to simplifying the portability and
> interoperability of both operating systems and ORBs.

I think we both agree that without the open-source community, this
industry would be in an even bigger mess than it is actually in!
It is sad though to see so much creativity and energy being spent on
something with so many deep-seated problems.

> >> - The specification is insufficiently tight to guarantee source
> >> code compatibility, even if you are strictly sticking to code that
> >> is based on the standard: for example, header file names are not
> >> standardized, there is no threading API or even a usable behavior
> >> model for threads, the files that are produced by an IDL compiler
> >> are unspecified in number and name, etc, etc.
>
> Give me a break Michi. This is NO different than for UNIX, Windows,
> and real-time embedded operating systems, which are MUCH more diverse
> than today's leading CORBA ORBs.

Excuse me? Does this make it right or acceptable? Just because it's as
bad as other things, I have to put up with that? That doesn't make sense
to me.

> As usual, there are a
> straightforward set of patterns and tools to apply to make this work
> fine in practice (not unlike what we've done with ACE, which makes
> cross-platform C++ concurrent network programming straightforward).
> Again, the CORBA auto-conf tool <http://corbaconf.kiev.ua> makes life
> much easier.

We don't seem to have spoken to the same people, or seem to have
interpreted their messages differently. As far as I am concerned, if I
need an auto-conf tool to write code for more than one middleware
platform, there is something wrong with the middleware. Installing and
using the tool doesn't come at zero cost, and I shouldn't need such a
tool in the first place.

> >> - Large and important parts of what you need to specify CORBA are
> >> not standardized at all: implementation repositories, configuration
> >> of all the services, build environment, administration, etc.
>
> The CORBA Component Model is addressing some of these issues - and
> there are an increasing number of CCM implementations coming online
> (check out Diego's http://www.ditec.um.es/~dsevilla/ccm/ page for more
> details). Moreover, it's not really clear what your point is here
> since ICE's solutions for all of these capabilities are even less
> standardized than CORBA! Moreover, ICE will need to provide many
> other non-standard services (e.g., transitions, fault tolerance,
> real-time, load balancing, component models, etc.) to compete with the
> more advanced CORBA, J2EE, and .NET offerings, so it sounds like
> you're largely reinventing the wheel and causing MORE interoperability
> and portability problems for the developer and user community!

Hmmm... How many CORBA vendors offer a product that provides even half of
all these things? Last time I looked, there wasn't a single
commercial vendor that would provide CCM, load balancing, transactions,
and fault tolerance. (Pick any two, and you just might be lucky.)
Just because there is a CORBA specification for something, that doesn't
mean that it exists, that I can buy it, or that I can buy from the
vendor I need to buy it from and for the platform I need it to run on.

Ice does what CORBA does, but better. For many people, that alone is
sufficient reason to use it. Whether CORBA is more advanced is something
that is open to debate, IMO. It really depends on which angle I look at
it from. The Ice core leaves the CORBA core behind in terms of usability
and functionality, IMO. If I look at the transaction service (oops, how
many vendors can I buy an implementation of that from?), or the sheer
weight of the numerous other specifications, certainly, Ice looses. As
far as saying that we are causing yet more interoperability and
portability problems is concerned, I don't think that makes sense. By
that argument, anyone who innovates anything can be accused of the same.

> Given that the distributed computing middleware market is incredibly
> crowded, with lots of very good products (many of which are freely
> available and commercially supported) it's not really clear what the
> value-added is for a proprietary middleware product like ICE that's
> not going to have a major 800 pound gorilla company or standards group
> to "adopt" and promote it, a la SOAP, J2EE, .NET, CORBA, etc., which
> means that it's likely to remain a niche technology.

Well, that might happen, we'll just have to wait and see. Personally, I
am much happier to work on something that is slick and elegant, instead
of cumbersome and clumsy. And, currently, I would call SOAP, J2EE, .NET, and
CORBA niche technologies too: none of them is ubiquitous. If we have
room for four RPC platforms, surely there must be room for a fifth?

> >> The net effect of all this is that there are hundreds of things
> >> that are not addressed in the specification, but that need to be
> >> taken care of when changing ORBs.
>
> I'm not sure if the number is "dozens" or "hundreds," but in either
> case based on the experiences of the groups at last week's meetings
> this problem appears straightforward to solve in practice - especially
> once you're using "modern" ORBs.

That I really would call a fallacy. The lack of a threading model in
CORBA is definitely not straightforward to solve in practice, otherwise
it would have been solved years ago. Neither is a solution to the
dreadful C++ mapping straightforward because, years ago, when I
suggested to do something about this, I realized that there was *no
chance whatsoever* to get that job done. Fixing IIOP? Forget it. Or the
mess of character set negotiation that still doesn't work among many
ORBs? A single vendor has consistently blocked any and all moves in the
OMG to throw out this mess and use Unicode instead. As a result,
cusomers are still burdened with this when a perfectly
reasonable and proven technical solution is readily available.

None of these problems are "straightforward" to solve. In fact, many of
them are impossible to solve, due to the political nature of the OMG,
the legacy problem, and the drag of backward compatibility and vendor
apathy.

> >> In practice, people have to re-engineer the build environment,
> >> administrative tools, and testing tools, not to mention the various
> >> bits of source code. Given all this, standardization has added
> >> comparatively little.
>
> I disagree - and the examples cited above provide evidence of the
> value of standards.

I think we just will have to disagree then. Most certainly, my
experiences have been nowhere near as rosy.

> >> In fact, I would argue that the burden the standard has imposed on
> >> the platform in terms of poor run-time performance, footprint, and
> >> complexity may well overwhelm any of the benefits:
>
> Again, let's see the actual numbers that Gautam's team can produce
> before you declare victory ;-). BTW, I'm more than willing to
> publically "eat crow" on this if the numbers bear it out!

Well, as I said above, some numbers are in. Ice certainly stacks up
quite well.

> >> in practice, once you develop with an ORB from a specific vendor,
> >> it is very difficult (and very expensive) to get away from that
> >> vendor.
>
> Perhaps if you're (1) using Orbix 3.x or earlier or (2) go out of your
> way to program to ORB-specific details. But this is now largely a
> failure of process, not technology. The tools, patterns, and
> techniques for writing portable/interoperable CORBA apps are widely
> available (and increasingly used in practice) - so there's no (good)
> excuse for not being vendor-independent these days.

Actually, I think there are several good excuses:

- Developer ignorance. It is not reasonable to expect developers
to be conversant with the spec to the degree required to steer
away from non-portable or vendor-specific constructs.

- Overhead. Why should I have to worry about all these extra
layers of patterns, tools, and techniques just to get portable
code? Why can't the API be portable, period? (And Doug,
really, if CORBA is so portable, what exactly is it that all
these patterns, tools, and techniques are achieving?)

- Cost. All the extra patterns, tools, and techniques have a
cost, both financial, and in terms of complexity, footprint,
and performance.

> >> That then begs the question of where the benefits of
> >> standardization are to be found.
>
> Fortunately, this (begged) question is now largely moot, as per the
> discussion above ;-)

Well, I don't think it is. The dream of interoperable and portable
software has by and large not been realized by CORBA. Maybe that isn't
CORBA's fault -- maybe the dream is unrealistic. I just spoke to a large
company who was forced by the demise of a commercial CORBA vendor to
switch ORBs. The story they told was very painful, and they were greatly
disillusioned by the way their investment in standardized technology had
failed to pay off. The cost was large for that company, both financially
and in terms of development effort, defects, and down time. Doug, these
people would laugh in your face if you told them that the issue is moot!

Thanks! We believe that Ice is better, period. It will never be all
things to all people, just as no other technology is. But, if you are
looking for a simple, efficient, and reliable technology for RPC, Ice
leaves CORBA in the dust. To some people, that matters more than
anything.

> My sense, however, is that ICE will have success with the "early
> adopter" technologist market, but will have difficulty crossing the
> chasm to be a mainstream product at the level of adoption of CORBA,
> .NET, SOAP, or J2EE.

That is very well possible. And, if that's what happens, suits me fine
-- we aren't interested in world domination, but in quality technology.
We do provide that and leave world domination to other people :-)

> A good analogy in the OS world would be
> something like the Be OS, OS/2, or NextSTEP, which were cool
> technologies that were much cleaner than their competition (i.e.,
> Windows ;-)), but which didn't catch on in the mainstream market.
> Ultimately the mass market of technology users don't select their
> tools and platforms because they are "cool" but because they address
> other key functional and non-functional forces. I guess Richard
> Gabriel really was right in his infamous "Worse is Better" screed...

Yes, I read that too -- most excellent essay. But, as I said, we are not
interested in world domination. Just making a living is quite sufficient :-)

> To wrap up this round of the debate (since I know Michi won't let me
> get the last word yet ;-)) let me close with the following. I respect
> the work that you ICE folks have done. I think you guys are REALLY
> smart, do GREAT work, and I'd like to see you SUCCEED. It bugs me,
> however, when you start spewing FUD about CORBA that simply doesn't
> hold up under closer inspection. Assuming ICE is as good as you say
> it is, you should be able to sell it on its merits, rather than
> resorting to Box/Sessions tactics.

Again, these aren't Box/Session tactics. The concerns I raised are real
in my opinion, are technically well founded, and are not FUD. They are
born of many years of very intensive work on CORBA, and many years of
consulting to customers. If I wanted to spread FUD, I'd write an article
for one of the trade rags instead of posting here. Ice offers an
alternative to CORBA that may be suitable for many people because
it is well possible that the arguments in support of CORBA don't stand
up under closer examination. In such cases, Ice is definitely worth a
look.

And no, I of course wasn't going to let you have the last word ;-)

How about we talk about this at JAOO? Steve Vinoski, Doug Lea, Bjarne
Stroustrup, and Jim Coplien will all be there too. Should make for a
lively evening over a few beers :-)

Gopi Bulusu

unread,

Jul 21, 2003, 1:59:04 AM7/21/03

"Michi Henning" <mi...@triodia.com> wrote in message news:<_MmSa.4709$OM3....@news-server.bigpond.net.au>...
!

> (lines deleted)

> little activity in last two years or so. Specifications are produced that are
> never implemented,

I believe that the process of standardization at OMG naturally leads
to
implemented specs. I can say this for sure, because we have
participated
in quite a few standardization efforts at OMG and have implemented the
same specs that we worked on. Naturally, there are always exceptions
(and exceptions
prove the rule :-)

> (lines deleted)

> at. Having lived and breathed CORBA for nearly a decade, I still have to
> consult my own
> book when I write CORBA code that is even a little out of the ordinary. It

That's certainly what a book is for. Can you expect an author of a
100,000 word
english dictionary to remember every word of that book ?

> specifications hugely complicates the ORB implementation. The result is a run
> time that is
> far slower and far larger than necessary. (Again, as an ORB implementer of many
> years,
> I speak from experience.)

I work for an ORB vendor myself, and our product SANKHYA Varadhi is
both small and fast, and believe me, there is very good competition
out there in the market.

> > I think comparing your product
> > with a standard like CORBA is comparing apples and oranges :-)
>
> Ice is similar to CORBA in many ways: it gives you language and platform
> neutral OO RPC,
> just like CORBA. It provides all of the features of CORBA (but does it in ways
> that are much
> simpler and more efficient), and it adds some features of its own that CORBA
> does not provide,
> such as interface aggregation, asynchronous method dispatch, UDP transport, and
> others. I don't
> think that is comparing apples and oranges. In fact, Ice is what CORBA should
> have been all
> along, but never could be because it is weighed down by its mistakes of the
> past and by its
> design by committee.

Taking the example of UDP support, many CORBA ORBs support UDP
transport !
Stating a particular product supports UDP, and CORBA does not support
UDP,
is clearly comparing apples and orranges.

apm

unread,

Jul 21, 2003, 7:32:54 AM7/21/03

sch...@macarena.cs.wustl.edu (Douglas C. Schmidt) wrote in message news:<bff912$n...@macarena.cs.wustl.edu>...

> Many of the topics that Michi brings up
> below were discussed at those meetings, so I wanted to provide my
> thoughts below.
>
> >> Having written large sections of the CORBA specification myself, I
> >> am aware of that. I am also aware of the impossibility to rectify
> >> even minor flaws in CORBA, let alone the major ones (and, believe
> >> me, I have tried).
>
> There's no question (in my mind) that the CORBA specification and
> revision process has flaws. Things do seem to get fixed, however,
> albeit not at the rate I'd like to see.

I agree with Michi. IMO it does not help to say that the spec process
is flawed. All processes are flawed. But the CORBA spec process is
more than flawed. The OMG moves at a glacial pace and is driven by
vendors rather than leading the way.

Again, I agree with Michi because of which parts the spec CORBA
developers care about, i.e essential services such as notification and
persistence.

> >> Specifications are produced that are never implemented, and bugs in
> >> the specification take ages to fix, or are never fixed at all.

This is my experience too. It is very fustrating. No wonder ICE was
developed. ICE is not without its problems but I think that ICE was
born partly BECAUSE of these CORBA problems.

> >> What is worse, most specifications are the kitchen sink of every feature
> >> ever dreamed of by anyone ever; the resulting platform and APIs are
> >> horrendously complex and take years to get proficient at.
>
> I think that's largely FUD Michi

I don't think so. I'm glad he said it. I think that other CORBA
developers feel the same way. I have spoken to several CORBA
developers contracting for merchant banks in London and this is just
what I find people think of CORBA. I still like CORBA despite the
problems but IMO these are real problems. I recommend CORBA because
IMO there is nothing suitable to replace it with yet. I tried ICE and
whilst it is a noble effort and initially seems a great improvement,
it does not seem ready for commercial use yet due to inadequate
support on Solaris (I am hopeful this will change soon though and some
Solaris porting work has been done recently to which I contributed).
But all in the CORBA garden is not rosy.

> - I'm surprised to hear you talk like
> this -

I'm glad. It needed saying.

> Sure, there are some dark corners of CORBA and C++, but it
> certainly doesn't take *years* to become proficient!

Well maybe it doesn't take years now, but for us old timers who
remember the BOA and CORBA-I it seems like years.

> However, it's also clear that UNIX, C, C++, C#, Perl,
> Windows, X-Windows, MFC, ACE, SOAP, COM/DCOM, .NET, Java, J2EE,
> Real-time Java, etc. all have accidental complexities and warts that
> leave something to be desired.

But I don't think that is what is being said. We are not talking about
minor pimples here and there, we are talking about great ugly warts
with hairs growing out of them (e.g the lack of support for std C++
types such as the STL string and vectors).

> Moreover, most large-scale projects have infrastructure teams whose
> role is to "hide" the COTS middleware behind their own domain-specific
> wrapper facades,

Yes, I have done this many times, but I have done it because there is
so much verbiage that needs to be hidden, for example most people
write a wrapper for the Name Service that hides the complexity of
exception handling for exceptions that are very common, such as the
need to rebind, and re-form context names on the fly.

I also agree with this. In fact I would say that CORBA is very well
known for having issues in the dissemination of larga volumes of
streaming real time data. ACE is a better ORB than most in this
department but that is thanks to ACE, it is no thanks to CORBA. And
the OMG have had to listen to ACE to realise what problems ACE has
come up against, the OMG did not lead the way.

> Perhaps as a result of spending time with Bill Beckwith (OIS) and Sam
> Aslam-Mir (PrismTech) last week has corrupted my mind irreparably, but
> it seems to me that their ORBs (ORBexpress and e*ORB, respectively)
> are REMARKABLY fast and small.

Well this does seem like good news. Do you have a URL?

> Not to take anything away from your experience Michi, but the folks
> who are implementing the cutting edge Real-time and Embedded CORBA
> ORBs have done some AMAZING things.

Well maybe they have but it's no thanks to the OMG and no thanks to
CORBA standards. And these improvements tend to be missing from
commercial ORBA such as VisiBroker and Orbix.

> >> Then add the ongoing vendor attrition into the picture, plus the
> >> OMG's changed focus on MDA instead of getting its middleware fixed,
> >> and the picture isn't all that pleasant.

I'm glad that was said too. If you go to the OMG web site one sees
that CORBA is very much de-emphasised. I think this has led to some
thinking that the OMG is not interested anymore. Certainly evolution
(or lack of it) now seems to be driven soley by commercial interest
(e.g bindings for other languages such as Eiffel).

> Michi, again with all due respect, you now work for a company that's
> selling a product that's aiming to compete directly with CORBA, so I'm
> not the LEAST BIT surprised that you'd no longer believe that CORBA is
> the answer!!

It's a pity in a way that Michi was the one to say all this coz it's
obvious that the statement would be made that he is biased. Of course
he is, but he is not alone in these views. And he has been a major
contributor to CORBA. This is why I thought I would respond. I am just
an ordinary CORBA developer and I think Michi has hit the nail on the
head.

[ praise for ICE snipped ]

> Let's wait and see what Gautam's experiments show before accepting
> that ICE is "much more efficient" than the state-of-the-art DRE ORBs!

Fair point.

> >> You are right, Ice doesn't have a standards base like CORBA
> >> does. But, on the other hand, how much has the CORBA
> >> standardization really achieved for people?

I think standardization is important and this is a strength of CORBA,
that it is a std. I have discussed this with the ICE developers before
on the ICE forum, that it is, IMO, desirable for ICE to be std-ized at
some point. I raised the issue because of the name, ICE which is
already taken as an internet std (for something completely unrelated
to CORBA-ish facilities).

In my experience this is because commercial ORBs only had the BOA for
a very long time.

The vendors, as always, are keen to find ways to lock customers in.
Often this is done by providing proprietary extensions that fix holes
in the std (e.g Orbix intercepors before interceptors became official,
loading balancing, which has still not been fully addressed, and
security issues such as object hijacking through direct binding to
IORs).

> Again, this is simply FUD Michi.

I beg to differ.

well that's just the trouble isn't it. The compliant ORBs are not the
market leaders so the PHBs will not go with them. Instead developers
are forced to use ORBs such as Orbix.

I agree. This does complicate the build process, especially for things
like the generated filenames. I find I build up pre-amble and
post-amble Makefile includes that form rules for each ORB. This is a
pain in the neck.

>
> Give me a break Michi. This is NO different than for UNIX, Windows,
> and real-time embedded operating systems

Maybe, but that's no excuse.

I agree with Michi's criticism of CORBA std-isation problems but agree
with Doug that if ICE is to address the issue then it should be
thinking about std-isation in the future.

> Moreover, ICE will need to provide many
> other non-standard services (e.g., transitions, fault tolerance,
> real-time, load balancing, component models, etc.) to compete with the
> more advanced CORBA, J2EE, and .NET offerings,

But so many CORBA developers want these to be part of CORBA and have
to turn to proprietary vendor extensions.

> so it sounds like
> you're largely reinventing the wheel and causing MORE interoperability
> and portability problems for the developer and user community!

Interoperability/portability would be solved by ICE std-isation.

I fear that ICE may remain niche but this would be a pity. If ICE
addresses OS portability (e.g a wide range of POSIX flavours and
compilers, including older compilers) and std-isation, then I think
ICE could give CORBA a run for its money.

Yes, I find that the main problem with portability is vendor ORBs are
not compliant with the stds. But the stds are missing some important
things like std filename conventions for code generated by the IDL
compiler.

> >> Ice is proprietary, to be sure, but all the APIs, language
> >> mappings, and the protocol are well documented, and anyone is
> >> welcome to create something that interoperates with Ice. In return,
> >> I get a platform that is more powerful than CORBA, doesn't take
> >> years to learn, is simple and coherent, and scales and performs
> >> better (and does that in a smaller footprint). To me, that makes it
> >> worth at least a closer look.
>
> At last something we can agree on Michi! It definitely makes sense to
> take a good look at ICE (and everything else that's available to solve
> similar problems) - that's what "due diligence" is all about.
> Moreover, I'm *certain* that good designers and programmers like you
> guys can come up with a cleaner/better distributed object computing
> model than CORBA!
>
> My sense, however, is that ICE will have success with the "early
> adopter" technologist market, but will have difficulty crossing the
> chasm to be a mainstream product at the level of adoption of CORBA,
> .NET, SOAP, or J2EE. A good analogy in the OS world would be
> something like the Be OS, OS/2, or NextSTEP, which were cool
> technologies that were much cleaner than their competition (i.e.,
> Windows ;-)), but which didn't catch on in the mainstream market.

I fear that ICE may not catch on but it's not to do with coolness.
It's to do with being supported in commercial development envrionments
with old versions of Unix and old compilers. I get the impression that
ICE was developed primarily using Linux and the GNU compiler, then
ported to Windoze. I found terrible portability problems when I tried
to get ICE up and running on Solaris 8 using the Forte compiler. The
older Sparcworks compiler wouldn't stand a chance.

Pardon me but as a CORBA developer I think that what Michi says about
CORBA is spot on.

Regards,

Andrew Marlow.

Marc Laukien

unread,

Jul 21, 2003, 8:10:14 AM7/21/03

Hello,

>
> I agree with Michi's criticism of CORBA std-isation problems but agree
> with Doug that if ICE is to address the issue then it should be
> thinking about std-isation in the future.

We from ZeroC would really love to see Ice (or under some other name, if
Ice is already taken) as a standard.

However, several years ago, when we spoke to this with the OMG (as in
"with important members of the OMG"), they made it pretty clear to us
that they are not interested in developing a "next-generation CORBA".
Instead, they wanted to push their MDA stuff. I doubt that they have
changed their opinion, so I don't think the OMG would be a good
organization for such standardization. Besides, I really don't want to
get into this "design by politics" again.

Ideally, we would like to set up an Ice standardization organization,
with many contributing members, but I think it's too early for this.

-- Marc

Marc Laukien

unread,

Jul 21, 2003, 8:32:21 AM7/21/03

> I believe that the process of standardization at OMG naturally leads
> to
> implemented specs. I can say this for sure, because we have
> participated
> in quite a few standardization efforts at OMG and have implemented the
> same specs that we worked on. Naturally, there are always exceptions
> (and exceptions
> prove the rule :-)

And I can say for sure that this is rarely the case. I'm pretty sure if
we do a count of specifications, we will find more that have not been
implemented (as in implemented and supported by a vendor) than
specifications that have been implemented.

If you implemented the specs you worked on in the OMG, then you belong
to a minority, as we once did.

>>at. Having lived and breathed CORBA for nearly a decade, I still have to
>>consult my own
>>book when I write CORBA code that is even a little out of the ordinary. It
>
>
> That's certainly what a book is for. Can you expect an author of a
> 100,000 word

> english dictionary o remember every word of that book ?

No, but I can expect somebody after years of training to speak English
without having to look permanently into a dictionary. Having to look up
something here and then is no big deal, but for CORBA, and especially
the C++ language mapping, you have to look up all the time. Heck, I
*implemented* a CORBA ORB and the C++ mapping, but still always had to
look up the mapping rules!

-- Marc

Dilip

unread,

Jul 21, 2003, 3:01:03 PM7/21/03

sch...@macarena.cs.wustl.edu (Douglas C. Schmidt) wrote in message

> [snipped...]

> I think that's largely FUD Michi - I'm surprised to hear you talk like
> this - you sound like Don Box or Roger Sessions!

I won't list them all but more than 4 times in your mail you have
lumped Roger Sessions and Don Box together in the same breath. Are
you simply being flippant? Because FUD slinging doesn't belong to the
exclusive domain of people who compete with CORBA you know...

--Dilip

Dilip

unread,

Jul 21, 2003, 3:11:35 PM7/21/03

Marc Laukien <ma...@zeroc.com> wrote in message news:<y7idnd_YiJn...@speakeasy.net>...

> Doug,
>
> I'm a bit surprised by the tone of your email. Is it really necessary to
> attack Michi like this? Comparisons with the persons you mentioned seem
> hardly be appropriate. After all Michi did *a lot* for CORBA, such as
> writing parts of an ORB, co-authoring a well-respected CORBA book,
> working on many CORBA specs, and last but not least giving a lot of free
> CORBA support in this newsgroup. I don't recall any of the other persons
> you compared Michi with doing any of this.

Other people have posted humongous and complete technical rebuttals.
I'd just like to point out something w.r.t Don Box. I live in the MS
world and in our world he is The Guru. I can't sit and watch while
people make grossly unsupported statements like the ones you and Doug
are making. For ex:

* Don Box did MORE THAN a LOT for COM.
* At the peak of the DCOM/CORBA wars, there was simply only one person
in the world who could recite the COM specification when his mind was
altered with thumb screws - Don Box
* Don Box wrote the only book in COM that explained the 'why', rather
than the 'how' of COM (Essential COM)
* Don Box posted literally thousands and thousands of explanations in
COM news groups (just search for the comp.ms-windows.* groups) and
more importantly discuss.microsoft.com (ATL/DCOM discussion lists)

I don't know anything about Roger Sessions other than his
www.objectwatch.com.

I would appreciate if people can just stick to technical content
instead of character assasinations.

someone like Doung Schmidt sinking to depths like this makes me sad...

--Dilip

Douglas C. Schmidt

unread,

Jul 21, 2003, 3:30:27 PM7/21/03

Hi Dilip,

Don Box and I were officemates in grad school at UC Irvine and
worked in the same research group (pity our poor thesis advisor, who
had to broker many of our heated technical debates over the years
;-)). I've known him since 1990 and he's a good friend of mine. He's
a brilliant guy whose made a lot of great contributions to distributed
object/component technology. He's also a wonderful purveyor of FUD
pertaining to stuff that isn't related to the technologies he's
working on, as anyone who knows him well will attest to.

It's perfectly possible to be a purveyor of FUD *and* a great
contributor to technology - in fact, it may be a prerequisite in these
market-driven times we live in. That doesn't change the fact that FUD
is still FUD, and needs to be labeled and treated as such. I'll reply
to the other postings as time permits, but I didn't want anyone to
think I was misrepresenting Don Box, who is a great guy, a top-notch
developer, and a compelling pied piper ;-)

Take care,

Doug

>> Other people have posted humongous and complete technical rebuttals.
>> I'd just like to point out something w.r.t Don Box. I live in the MS
>> world and in our world he is The Guru. I can't sit and watch while
>> people make grossly unsupported statements like the ones you and Doug
>> are making. For ex:
>>
>> * Don Box did MORE THAN a LOT for COM.
>> * At the peak of the DCOM/CORBA wars, there was simply only one person
>> in the world who could recite the COM specification when his mind was
>> altered with thumb screws - Don Box
>> * Don Box wrote the only book in COM that explained the 'why', rather
>> than the 'how' of COM (Essential COM)
>> * Don Box posted literally thousands and thousands of explanations in
>> COM news groups (just search for the comp.ms-windows.* groups) and
>> more importantly discuss.microsoft.com (ATL/DCOM discussion lists)
>>
>> I don't know anything about Roger Sessions other than his
>> www.objectwatch.com.
>>
>> I would appreciate if people can just stick to technical content
>> instead of character assasinations.
>>
>> someone like Doung Schmidt sinking to depths like this makes me sad...
>>
>> --Dilip

Marc Laukien

unread,

Jul 21, 2003, 4:48:18 PM7/21/03

Dilip wrote:
> Marc Laukien <ma...@zeroc.com> wrote in message news:<y7idnd_YiJn...@speakeasy.net>...
>
>>Doug,
>>
>>I'm a bit surprised by the tone of your email. Is it really necessary to
>>attack Michi like this? Comparisons with the persons you mentioned seem
>>hardly be appropriate. After all Michi did *a lot* for CORBA, such as
>>writing parts of an ORB, co-authoring a well-respected CORBA book,
>>working on many CORBA specs, and last but not least giving a lot of free
>>CORBA support in this newsgroup. I don't recall any of the other persons
>>you compared Michi with doing any of this.
>
>
> Other people have posted humongous and complete technical rebuttals.
> I'd just like to point out something w.r.t Don Box. I live in the MS
> world and in our world he is The Guru. I can't sit and watch while
> people make grossly unsupported statements like the ones you and Doug
> are making. For ex:

I didn't mean to say anything negative about Don Box. I only wanted to
point out that these comparisons seem to be very inappropriate. And I
fully agree with you that we should stick to technical issues and not
character assasinations!

-- Marc

Frank Pilhofer

unread,

Jul 21, 2003, 8:43:19 PM7/21/03

Michi Henning <mi...@triodia.com> wrote:
>
> Unfortunately, the CORBA standard is stuck in a quagmire, I believe.
> There has been little activity in last two years or so. Specifications
> are produced that are never implemented, and bugs in the specification
> take ages to fix, or are never fixed at all.
>

Hi all,

this is certainly an interesting and lively discussion. As always,
I think that the truth lies (what a wonderful oxymoron) somewhere
inbetween.

On the one hand you have specs for which backwards compatibility is
paramount, and you end up with mammoths like X11 or CORBA. On the other
hand, you have specs that try to be slick and trendy, and .NET or Ice
is what you get out of it - software that doesn't interoperate with
anything but itself, not even its predecessors (like (D)COM, RIP).

Including the kitchen sink does have its benefits and drawbacks, and
in this respect I'd like to compare CORBA with another specification
that is reasonably well accepted today - ISO C++. How long did it take
them to publish the spec, something like 15 years? And I find myself
fishing for the C++ spec all the time, to look up name and signature
for that template that I know exists somehwere, only to find that my
C++ compiler doesn't agree, and even if it does, I know that the
program probably won't port well until another 10 years have passed.

I agree that the final ISO C++ spec is a more wholesome read than
CORBA, and the OMG can certainly learn from its process.

Once I read a Stroustroup quote that within C++, there is a much
simpler, easier and more powerful language trying to hatch out; I
think the same is true with CORBA.

Let's not forget the benefits that CORBA gives us. GIOP/IIOP is about
the best there is, it's widely accepted, compact (even though you can
have religious discussions over padding that never matches in-memory
padding when you need it), and reasonably easy to implement. That the
IIOP version number to the GIOP version number is unfortunate, but
not such a big deal.

Interoperability between ORBs is not an issue these days. The wide
acceptance of Open Source ORBs like Mico, TAO, and easily accessible
ORBs like ORBacus certainly did the trick here.

Even source code compatiblity isn't so bad, once you get past the
header file anomalies (fortunately, at least all Open Source ORBs
allow you to configure header file suffices) and follow the good
advice in Michi's book, you're almost there.

So I think that at this central core, CORBA is sound and healthy,
even if that argument only applies to like 10% of the current volumes
that call themselves CORBA spec.

I completely agree with Michi on the C++ mapping part, it's awful,
and I wouldn't be surprised if that alone scared many developers into
the arms of Soap - or Ice, for that matter. But I don't think that this
should be pinned on the OMG as a failure, it was also a practical matter
of making the mapping work with at-the-time (early 90's) C++ compiler
implementations.

I love the simplicity of Ice's C++ mapping, and getting some of the
same for CORBA would be wonderful. I'd like to see Ice being based on
GIOP for interoperability, and its C++ mapping submitted to the OMG as
the future C++ language mapping 2.0 for CORBA. That would go a long way
in making CORBA more appealing. I know I'm dreaming here.

On top of that, add an EOA Easy Object Adapter that uses simple names
as object keys (so that you can easily figure out the corbaloc: address),
and add a simple async messaging mechanism (like "safe oneways"). Get
bidir GIOP finally right. For the enterprise market, run it all on IIOP
over SSL by default (i.e. make it as easy as accessing a https: web
page), and add a Transaction service. Now I'm in Wonderland.

Yes, there's plenty of things that are wrong with parts of the CORBA
specification(s). Sometimes it's good to take a step back and publish
a version 2.0 specification, taking into account all you learned when
applying version 1.0, and not making the same mistakes again. In effect,
that is what the embedded systems domain is doing at the moment, trying
to focus on the pieces that CORBA does really well, removing add-on
features like the kitchen sink. And I think CORBA will greatly benefit
from these efforts.

Maybe this will help breathe some momentum back into the OMG, which
was, I agree, somewhat left stumbling and mumbling after all vendors
left the arena for Web Services.

I also have high hopes for component-based development, where you
interconnect components into higher-level assemblies. This design
paradigm is not a CORBA exclusive, but CCM, once you get past its
more intimidating chapters, takes the idea the farthest. Lightweight
CCM, however unfortunate the name (it should be called CCM, and the
current spec should be Persistent and Transactional Component Model
or something like that) should make that even more accessible. And I
think that it will see early adoption by Open Source ORBs (by coinci-
dence, MicoCCM pretty much exactly implements the Lightweight CCM
subset already, as does OpenCCM); I already hear embedded systems
engineers screaming for commercial(ly supported) implementations.

So there's lots to be done, but I am not yet convinced that there's
only darkness glooming ahead. CCM is a start, but CORBA could also use
an infusion of all the good ideas in Ice, Web Services, Erlang, etc.
Yet it still does a decent job at making servers interoperate.

Frank

--
Frank Pilhofer ........................................... f...@fpx.de
If most people said what's on their minds, they'd be speechless.
- Alfred E. Neuman

Gopi Bulusu

unread,

Jul 22, 2003, 1:39:42 AM7/22/03

Marc Laukien <ma...@zeroc.com> wrote in message news:<X2GdnTBQ3dL...@speakeasy.net>...

something here and then is no big deal, but for CORBA, and especially
> the C++ language mapping, you have to look up all the time. Heck, I
> *implemented* a CORBA ORB and the C++ mapping, but still always had to
> look up the mapping rules!

I implemented parts of our CORBA ORB (and several C++ compilers) too
;-) If you are saying that a person implementing an ORB needs to look
up the spec all the time, that's exactly the reason why the spec
exists.

If you are saying that a C++/CORBA programmer has to look up the spec
all the time, then there is a serious problem. I completely agree that
many of the C++ mapping rules are "not-intuitive" for C++ programmers
who use and understand the ISO specification. One has to note that
CORBA's C++ mapping rules predate
ISO C++ and may infact have contributed to the C++ standardization
effort (indirectly).

Typically, many CORBA ORB implementors never actually develop CORBA
programs
and vice-versa. This is true for people developing compilers,
operating systems,
data base management systems or other system software. As a result
they tend
to over-emphasize the role of programming, and under-emphasize the
role of
architecture and design. Large and complex systems need a sound
architecture
on which they can be built. CORBA provides precisely that to
enterprise application developers.

This does not in any way mean that CORBA is only for complex systems.
Even
the least experienced C++ developers can very quickly develop simple
CORBA
applications, if they are using a CORBA product, designed and
developed keeping in view the usability of the product. Simple ready
to run sample source code, good documentation and tutorials will go a
long way in ensuring that CORBA
can be used for the simplest of software systems. Most people who
downloaded our ORB (Varadhi) were able to build and run their first
CORBA/C++ program within 5 minutes !

Michi Henning

unread,

Jul 22, 2003, 7:45:21 AM7/22/03

"apm" <ap...@student.open.ac.uk> wrote in message
news:d1a33011.03072...@posting.google.com...

>
> I fear that ICE may not catch on but it's not to do with coolness.
> It's to do with being supported in commercial development envrionments
> with old versions of Unix and old compilers. I get the impression that
> ICE was developed primarily using Linux and the GNU compiler, then
> ported to Windoze. I found terrible portability problems when I tried
> to get ICE up and running on Solaris 8 using the Forte compiler. The
> older Sparcworks compiler wouldn't stand a chance.

Hi Andrew,

yes, we found those problems too :-( It's back to the old days
of ORBacus again: back then, the Sun compiler gave us more
problems than the compilers for all the other platforms combined.
We've ported Ice to Solaris 9 and the Sun CC 5.4 compiler at
patch level 111711-04 or later. (Earlier versions didn't make the
grade, I'm afraid.) We'd love to support earlier versions but, to
be honest, we are helpless when confronted with a compiler that
compiles a language with only a passing resemblance to C++.
(And we can't afford to do major reengineering of our product
just to accommodate a language that is almost, but not quite,
entirely unlike C++... ;-)

For what it's worth, people have ported Ice to FreeBSD, Mac OS X,
and HP-UX without major problems, and the code compiles with both
VC++ 6 and VC++ .NET, so we are quite confident that most of the
code that tends to tickle compiler bugs has been ironed out now.

Michi Henning

unread,

Jul 22, 2003, 8:06:36 AM7/22/03

"Gopi Bulusu" <go...@sankhya.com> wrote in message

news:2d87f439.03072...@posting.google.com...

> "Michi Henning" <mi...@triodia.com> wrote in message
news:<_MmSa.4709$OM3....@news-server.bigpond.net.au>...
> !
>
> > (lines deleted)
> > little activity in last two years or so. Specifications are produced that
are
> > never implemented,
>
> I believe that the process of standardization at OMG naturally leads
> to
> implemented specs. I can say this for sure, because we have
> participated
> in quite a few standardization efforts at OMG and have implemented the
> same specs that we worked on. Naturally, there are always exceptions
> (and exceptions
> prove the rule :-)

Well, this does not agree with my observations. As a highly
active OMG member since 1996, and as former chair of
the C++ RTF and a former Architecture Board member, I can
confidently assure you that the majority of specifications that
are submitted for adoption have not been implemented. In fact,
the majority of specifications that were submitted for many years
could never have been implemented because they contained invalid
IDL constructs (not to mention other, more serious defects).
(It was only during my time as an AB member that people
seemed to finally accept that, if they showed up yet one more
time with fantasy IDL that wouldn't even compile, I'd show them
where the door is yet again...)

Having participated in a number of standards submissions myself,
both during my time at DSTC and my time at OOC, I was
surprised time and time again when I learned that we were the only
ones who had bother to implement what we submitted...

And, given the number of published specifications, and the number
of products I can buy that actually implement those specifications,
I am doubtful about your claim too. Just take a look at the CosServices.
Some of these are useful, but the majority are simply useless. Gems
like the Query Service, Relationship Service, Life Cycle Service,
and Collection Service show that, at best, those specifications are
useless (and I'm being kind here).

Would you like more examples?
The Persistent Object Service spec that was so embarrassing, it
had to be withdrawn; the bidirectional IIOP spec that could
never be made to work and was withdrawn; the original security
attempt that turned out to be unimplementable; the mimimum
CORBA spec that misses the mark a margin so wide, it isn't funny
(and, yes, I was involved in that one on the side lines -- there wasn't
an implementation of anything, just theoretical musings in phone
conferences). There are more examples along the same lines.

> > (lines deleted)
> > at. Having lived and breathed CORBA for nearly a decade, I still have to
> > consult my own
> > book when I write CORBA code that is even a little out of the ordinary. It
>
> That's certainly what a book is for. Can you expect an author of a
> 100,000 word
> english dictionary to remember every word of that book ?

No, certainly not. But as a world-recognized expert on CORBA, and after
having used and implemented it daily for many years, I would think that I
could remember what I need to know. Sadly, this isn't so. Maybe there is
something wrong with my memory (but then, lots of other people seem to have
the same problems, so I don't think so).

> > specifications hugely complicates the ORB implementation. The result is a
run
> > time that is
> > far slower and far larger than necessary. (Again, as an ORB implementer of
many
> > years,
> > I speak from experience.)
>
> I work for an ORB vendor myself, and our product SANKHYA Varadhi is
> both small and fast, and believe me, there is very good competition
> out there in the market.

I do not doubt that you have built a fine product. But I also do
not doubt that, if your product wouldn't have to jump through
all the unnecessary hoops imposed by the specification,
it would be even smaller and even faster.

> Taking the example of UDP support, many CORBA ORBs support UDP
> transport !

Many? I'm surprised to hear that -- a few at most, I would have thought.
Regardless, so what? There is no specification for CORBA over UDP,
which means that all these ORBs are just as proprietary as Ice is. Where
is the benefit of CORBA then?

> Stating a particular product supports UDP, and CORBA does not support
> UDP,
> is clearly comparing apples and orranges.

CORBA, by definition, does not support UDP. This is an inarguable fact:
there is no UDP specification for CORBA. There may be CORBA
implementations that offer UDP as a proprietary add-on, sure. But that
add-on isn't CORBA. (And, yes, I'm aware of the mult-cast specification,
having worked on parts of that myself. To me, that isn't UDP because
multi-cast is conceptually very different. But the point may well be moot
because, to the best of my knowledge, no-one has bothered to implement
that one either...)

Michi Henning

unread,

Jul 22, 2003, 8:24:48 AM7/22/03

"Gopi Bulusu" <go...@sankhya.com> wrote in message

news:2d87f439.03072...@posting.google.com...

>
> If you are saying that a C++/CORBA programmer has to look up the spec
> all the time, then there is a serious problem. I completely agree that
> many of the C++ mapping rules are "not-intuitive" for C++ programmers
> who use and understand the ISO specification. One has to note that
> CORBA's C++ mapping rules predate
> ISO C++

Well, the CORBA C++ mapping and the ISO C++ specification
effort proceeded concurrently.

> and may infact have contributed to the C++ standardization
> effort (indirectly).

No, fortunately not. If the current mess of the CORBA C++ mapping
had been able to influence the ISO C++ standard, C++ would be a
dead language by now :-( Fortunately, the people who worked on
ISO C++ standardization were, on average, much better at C++
than the ones who worked on the CORBA C++ mapping.

> Typically, many CORBA ORB implementors never actually develop CORBA
> programs
> and vice-versa. This is true for people developing compilers,
> operating systems,
> data base management systems or other system software.

Too true, sadly. The designers of so many systems are so good
at what they are doing that there is absolutely no need to ever
use their own product. That's why we have VCRs that even a PhD
in Computer Science cannot get to record a program on Wednesday
evening next week on channel 10, that's why we have coffee pots with
spouts that dribble, and that's why we have a CORBA Naming Service
that throws an exception because I dared to look up a name in the
service that isn't in there...

> As a result
> they tend
> to over-emphasize the role of programming, and under-emphasize the
> role of
> architecture and design. Large and complex systems need a sound
> architecture
> on which they can be built. CORBA provides precisely that to
> enterprise application developers.

Well, it provides an architecture. Lots of ideas in that architecture are
nice. To call the end result "sound" is going too far though, IMO.
CORBA is as least as much the result of political and commercial
maneuvering among a large number of vendors who detest each
other as it is the result of serious technical experts who tried to find
the best possible solution. The result is a weird hash of different
technical, political, and commercial goals that usually all pull in
different directions. It's definitely possible to do better.

> This does not in any way mean that CORBA is only for complex systems.
> Even
> the least experienced C++ developers can very quickly develop simple
> CORBA
> applications, if they are using a CORBA product, designed and
> developed keeping in view the usability of the product.

I cannot support this argument. After many years of CORBA, I know
that anyone can knock up a simple client server application after a
few hours, no problem. But I also know that, to build something that is
robust, scales well, and performs well, a lot of experience is necessary.
I have seen quite a number of projects that shot themselves in the foot
something terrible due to lack of that experience. (To some extent, this
is true for all distributed systems, I believe -- distributed systems aren't
easy to get right, period. But CORBA does its share to make it even
harder at times, and unnecessarily so.)

> Simple ready
> to run sample source code, good documentation and tutorials will go a
> long way in ensuring that CORBA
> can be used for the simplest of software systems. Most people who
> downloaded our ORB (Varadhi) were able to build and run their first
> CORBA/C++ program within 5 minutes !

Yes. Most people who never have seen C in their entire life can produce
"Hello World!" in five minutes too. So what? That says nothing about
their ability to produce something that is a real application, or how
long it will take them to be able to do that.

Michi Henning

unread,

Jul 22, 2003, 8:55:23 AM7/22/03

"Frank Pilhofer" <f...@fpx.de> wrote in message
news:slrnbhp2...@ariel.fpx.de...

> As always,
> I think that the truth lies (what a wonderful oxymoron) somewhere
> inbetween.

Wonderful, I hadn't come across that one before, thanks! :-)

> Interoperability between ORBs is not an issue these days. The wide
> acceptance of Open Source ORBs like Mico, TAO, and easily accessible
> ORBs like ORBacus certainly did the trick here.

Hmmm... I think this is true if you leave out value types and codeset
negotiation. With those two in, I'm not at all sure.

> Even source code compatiblity isn't so bad, once you get past the
> header file anomalies (fortunately, at least all Open Source ORBs
> allow you to configure header file suffices) and follow the good
> advice in Michi's book, you're almost there.

Yes. But pray that you can tell the difference between the old typecode
semantics and the new ones, or the old DynamicAny and the new one,
and that you never, ever ignore the return value of an operation that
returns a variable-length value, or that you always remember to use
a _var type (except for those few situations where the callee retains
ownership of the memory and using a _var type will cause a core dump)...
This is ridiculous, really. Why should I have to burden my brain with
all this? I got enough on my hands implementing my application
without also having to accommodate arcane APIs all the time.

> So I think that at this central core, CORBA is sound and healthy,
> even if that argument only applies to like 10% of the current volumes
> that call themselves CORBA spec.

That's an interesting comment, isn't it? The corollary then would be that
CORBA is unsound and unhealthy when you consider the other 90%
percent of what currently calls itself the CORBA spec?

> I completely agree with Michi on the C++ mapping part, it's awful,
> and I wouldn't be surprised if that alone scared many developers into
> the arms of Soap - or Ice, for that matter. But I don't think that this
> should be pinned on the OMG as a failure, it was also a practical matter
> of making the mapping work with at-the-time (early 90's) C++ compiler
> implementations.

To be fair, getting a mapping off the ground back then, before ISO C++
was available, was a hard ask. But then again, there was an alternative
mapping submitted by Hyperdesk at the time. Coincidentally, that mapping
was quite similar in flavor (and memory-management safety) to the Ice
C++ mapping. Sadly, the Hyperdesk mapping was rejected on political
grounds and factional infighting as well as on (in hindsight, entirely
inappropriate and misguided) performance grounds.

> I love the simplicity of Ice's C++ mapping, and getting some of the
> same for CORBA would be wonderful. I'd like to see Ice being based on
> GIOP for interoperability, and its C++ mapping submitted to the OMG as
> the future C++ language mapping 2.0 for CORBA. That would go a long way
> in making CORBA more appealing. I know I'm dreaming here.

A better C++ mapping for CORBA certainly would be very nice. But it
won't fix all the other things that need fixing. And, of course, as a customer,
what are you going to do? Throw out all the old code? Or maintain two
code bases side by side? Or keep the old code for the old applications
and write all the new applications using the new mapping? (Never mind
that this means that, when my programmers originally only had to remember
one bad mapping, they now have to remember two, never mind how good
the second one.) And what are you going to do as an ORB vendor?
Maintain both mappings for the next ten years? Or force yet another
"tough choice" on the customer and leave them in the lurch with their
legacy code?

As a customer, for that matter, am I going to put up with yet another
drastic and very expensive API change along the lines of the BOA/POA
debacle? Frank, I appreciate the compliment about the Ice mapping, but
I really think that a very important point is being missed here: there are
many customers who are already at the end of their tether with the ongoing
instability of CORBA. These customers won't have inifinite amounts of
patience.

> On top of that, add an EOA Easy Object Adapter that uses simple names
> as object keys (so that you can easily figure out the corbaloc: address),
> and add a simple async messaging mechanism (like "safe oneways"). Get
> bidir GIOP finally right. For the enterprise market, run it all on IIOP
> over SSL by default (i.e. make it as easy as accessing a https: web
> page), and add a Transaction service. Now I'm in Wonderland.

Right. I can safely guarantee that, by the time all the necessary incompatible
changes will have been made, there won't be a single CORBA customer
left.

> Yes, there's plenty of things that are wrong with parts of the CORBA
> specification(s). Sometimes it's good to take a step back and publish
> a version 2.0 specification, taking into account all you learned when
> applying version 1.0, and not making the same mistakes again. In effect,
> that is what the embedded systems domain is doing at the moment, trying
> to focus on the pieces that CORBA does really well, removing add-on
> features like the kitchen sink. And I think CORBA will greatly benefit
> from these efforts.

Yes. Would have been nice though to get it a bit more right a bit earlier.
After all, customers were sold on the safety that standardization would
give them, and how their investment would be protected...

> Maybe this will help breathe some momentum back into the OMG, which
> was, I agree, somewhat left stumbling and mumbling after all vendors
> left the arena for Web Services.

Good luck to them. Looks like OASIS, W3C, and WS-I have done little
but to go for each others' throats lately. And MS and Sun have started
yet another holy jihad, this time over WS-ReliableMessaging. Truly
confidence-inspiring for the customer. (But I guess this time they are
better off: they have three organizations they can choose to back,
instead of a single one where they can choose to back different
bickering factions...)

> I also have high hopes for component-based development, where you
> interconnect components into higher-level assemblies. This design
> paradigm is not a CORBA exclusive, but CCM, once you get past its
> more intimidating chapters, takes the idea the farthest. Lightweight
> CCM, however unfortunate the name (it should be called CCM, and the
> current spec should be Persistent and Transactional Component Model
> or something like that) should make that even more accessible. And I
> think that it will see early adoption by Open Source ORBs (by coinci-
> dence, MicoCCM pretty much exactly implements the Lightweight CCM
> subset already, as does OpenCCM); I already hear embedded systems
> engineers screaming for commercial(ly supported) implementations.

I don't want to pour too much water on CCM but, I'm afraid, its major
problem is that it was about five years too late. (Apart from, yet again,
being the kitchen sink of every half-baked idea ever.) I think I'm safe
in suggesting that CCM won't change CORBA's fortunes. And your
sentence about "its more intimidating chapters" is telling, isn't it? Why
should it be intimidating to drop a bit of code into a container? The
idea is simple in concept -- why can't it be simple in execution?

> So there's lots to be done, but I am not yet convinced that there's
> only darkness glooming ahead. CCM is a start, but CORBA could also use
> an infusion of all the good ideas in Ice, Web Services, Erlang, etc.
> Yet it still does a decent job at making servers interoperate.

Frank, I think you are much more idealistic than I am. I have fought
for many years until I nearly dropped to get things fixed in the OMG
that were of a purely technical nature and in no way controversial,
either politically or commercially. And yet, I have failed on many of
these even so. (I won't even start talking about the more controversial
things that I would have liked to fix -- see Marc's comments about
the suggestion to do a "better CORBA".) In my opinion, there is no
way to change the technical course of CORBA, even if it were
technically possible, let alone commercially. I honestly don't believe that
this will ever happen. (If I'm wrong, the better for all of us distributed
system developers, but I'm very, very skeptical.)

apm

unread,

Jul 22, 2003, 12:47:36 PM7/22/03

"Michi Henning" <mi...@triodia.com> wrote in message news:<lt9Ta.8438$OM3...@news-server.bigpond.net.au>...

> "apm" <ap...@student.open.ac.uk> wrote in message
> news:d1a33011.03072...@posting.google.com...
> >
> > I fear that ICE may not catch on but it's not to do with coolness.
> > It's to do with being supported in commercial development envrionments
> > with old versions of Unix and old compilers. I get the impression that
> > ICE was developed primarily using Linux and the GNU compiler, then
> > ported to Windoze. I found terrible portability problems when I tried
> > to get ICE up and running on Solaris 8 using the Forte compiler. The
> > older Sparcworks compiler wouldn't stand a chance.
>
> Hi Andrew,
>
> yes, we found those problems too :-( It's back to the old days
> of ORBacus again:

I know, but at least ORBacus worked around the problems.
I know it's not nice to have to alter perfectly good
code just because a compiler is crappy, but such is
life sometimes.

> We've ported Ice to Solaris 9 and the Sun CC 5.4 compiler at
> patch level 111711-04 or later.

I know, I was there :-)

>(Earlier versions didn't make the
> grade, I'm afraid.)

Well, that's just it. If you look at ORBs such
as ORBacus and ACE they do take the trouble to work
with a wide range of compilers including ones
that are quite terrible. The problems I had with
Forte 6.2 were only a couple of patches away from
what you ported to. This is a pity, IMO.

> We'd love to support earlier versions but, to
> be honest, we are helpless when confronted with a compiler that
> compiles a language with only a passing resemblance to C++.
> (And we can't afford to do major reengineering of our product
> just to accommodate a language that is almost, but not quite,
> entirely unlike C++... ;-)

I am suprised at this considering the commercial aim of ICE.
In my experience it is quite rare for commercial development
environments to have the latest greatest compiler.

I know what you mean about having to twist the constructs
you've used, especially the use of STL algorithms and the
use of functors, but the price is that ICE is not going
to be as available as these other ORBs are for commercial use.

-Andrew

Rob

unread,

Jul 22, 2003, 2:35:53 PM7/22/03

Michi,

Very impressive work. If anything, hopefully the improvements
your team has made will be a nice motivation for enhancements in
CORBA as well. (Just like C# has been for Java and vice-versa!)

I did have one question though,
I've looked over the documentation for ICE and noticed that the
non-intel (Big Endian) machines like Sparcs, MIPs, IBM and such
are kind of treated like redheaded stepchildren. One thing I thought
was very right about GIOP was the receiver makes right concept.
Whether you were an Intel or a Sparc shop, CORBA would
communicate at maximum efficiency. With ICE it appears that
Intel would be favored over non-intel machines in terms
of marshalling performance. Is this correct?

Thanks,

Rob Ratcliff

Michi Henning <mi...@triodia.com> wrote in message news:<Pine.LNX.4.44.030710...@diadora.client.uq.net.au>...

Michi Henning

unread,

Jul 22, 2003, 5:27:27 PM7/22/03

"Rob" <rrr...@futuretek.com> wrote in message
news:ea0043d9.03072...@posting.google.com...

> Michi,
>
> Very impressive work. If anything, hopefully the improvements
> your team has made will be a nice motivation for enhancements in
> CORBA as well. (Just like C# has been for Java and vice-versa!)
>
> I did have one question though,
> I've looked over the documentation for ICE and noticed that the
> non-intel (Big Endian) machines like Sparcs, MIPs, IBM and such
> are kind of treated like redheaded stepchildren. One thing I thought
> was very right about GIOP was the receiver makes right concept.
> Whether you were an Intel or a Sparc shop, CORBA would
> communicate at maximum efficiency. With ICE it appears that
> Intel would be favored over non-intel machines in terms
> of marshalling performance. Is this correct?

It looks like that on the surface, but actually isn't so. In the old days
of DCE and slow machines, doing "receiver-makes-it-right" made
sense because the cost of byte-swapping compared to the overall
cost was significant. That is also what motivated padding the data
on the wire to try and keep it aligned with address boundaries for
common CPUs. Given the speed of today's CPUs, this does make
sense anymore though: Ice doesn't pad the data at all. Everything
is byte aligned, that is, Ice favours bandwidth over marshaling cost.
But, given that the data isn't padded anyway, there is no point
in trying to use "receiver-makes-it-right" either because, as we copy
the data out of the transport buffers, we might as well byte-swap it,
if necessary. The extra cost is essentially zero compared to the overall
cost of marshaling.

Overall, the design makes sense: over WAN connections, the padding
and alignment just get in the way and becomes the performance-limiting
factor because the overall throughput is throttled by bandwidth limitations.
Over fast LANs, it doesn't matter because, even though the bandwidth
is just about inifinite, there are many, many other issues that
affect performance, such as thread context switches, lock contention,
trap rate into and out of the kernel, and those issues carry more weight
than byte ordering.

What it boils down to is that padding and endian-ness gain nothing other
than complexity. Avoiding the "receiver-makes-it-right" approach also
also the adavantage that requests can be forwarded as blobs of binary
data. This is important for intermediate processes (such as an event
service) that pick a request off the wire and then re-send it to a number
of receivers. By having a fixed byte order, the intermediate can just
blindly read and write binary blobs and there is no need for the
intermediary to unmarshal and remarshal anything. The only place where
byte swapping takes place is in the ultimate receiver that actually unmarshals
and uses the data.

So, the Ice protocol gets the most performance possible for the least
complexity possible: on WANs, bandwidth matters, and Ice minimizes
that. On LANs, the bottlenecks are entirely elsewhere, so "receiver-makes-
it-right" doesn't buy us anything.

Frank Pilhofer

unread,

Jul 22, 2003, 9:28:03 PM7/22/03

Michi Henning <mi...@triodia.com> wrote:
> "Frank Pilhofer" <f...@fpx.de> wrote in message

> > So I think that at this central core, CORBA is sound and healthy,
> > even if that argument only applies to like 10% of the current volumes
> > that call themselves CORBA spec.
>
> That's an interesting comment, isn't it? The corollary then would be that
> CORBA is unsound and unhealthy when you consider the other 90%
> percent of what currently calls itself the CORBA spec?
>

Basically, I wasn't making any kind of statement on the other 90%,
since I don't know 80% of all CORBA specs. (I decided to weasel out
on that one.) I am certainly aware of specs with numerous problems
(CCM comes to mind) and specs that are nothing but a problem.

The picture looks a bit brighter when you consider available specs
only, ignoring adopted specs that were never implemented. (And I
wouldn't mind if the OMG enforced this policy a bit more harshly.)

>
> A better C++ mapping for CORBA certainly would be very nice. But it
> won't fix all the other things that need fixing. And, of course, as
> a customer, what are you going to do? Throw out all the old code? Or
> maintain two code bases side by side? Or keep the old code for the
> old applications and write all the new applications using the new
> mapping?
>

I think the same applies to migrating from CORBA to Web Services or Ice.

>
> Frank, I think you are much more idealistic than I am. I have fought
> for many years until I nearly dropped to get things fixed in the OMG
>

Well, I haven't spent as much time in the OMG as you did, so maybe I
have yet to be as discouraged.

I agree that sitting down and getting cross-vendor standards good and
right is hard. It's a full time job, and these days, too few companies
expend software architects to work on OMG specs all day - and if they
do, some may be frustrated that they're being slowed down by other
company reps that might not be as accessible for discussions.

However, you could also argue that bypassing the process and publishing
something on your own is the easy way out.

Frank

--
Frank Pilhofer ........................................... f...@fpx.de

Most people don't act stupid, it's the real thing! - A. E. Neuman

Ruslan Shevchenko

unread,

Jul 22, 2003, 10:17:47 PM7/22/03

>
> Well, depends on what you mean by "getting fixed". For example, IDL
> constant expression semantics have been undefined for a long time. The
> issue was raised on 15 April 1998 and closed on April 23 2003, five
> years later. Of course, the issue hasn't been fixed because there are

It's quite good :( For example - C++ wchar_t semantics is still
undefined from 1992. But in each C++ compiler/library we have own
wchar_t implementation
with own semantics.

....

>
>
> The list could be extended considerably.
>

Yes. But I think that such list can be prepared for each non-trivial
technology with long lifetime.

>
>
> > There's no question that CORBA could be simpler - especially given the
> > benefit of hindsight (and the lack of SOM compatibility in the early
> > days ;-)). However, it's also clear that UNIX, C, C++, C#, Perl,
> > Windows, X-Windows, MFC, ACE, SOAP, COM/DCOM, .NET, Java, J2EE,
> > Real-time Java, etc. all have accidental complexities and warts that
> > leave something to be desired. While it would be nice to throw them
> > all out and start from scratch, that's not always possible/sensible.
>
> Well, we think that is possible and sensible. By that argument, we would
> have to live with every wart and bad design ever invented by anyone, and
> we are certainly not doing that. (How many DOS programs get written
> these days? Or how many DCE programs, for that matter? And DCE
> proponents had much the same things to say about CORBA when it was
> new...)
>

true. From other side: where are LISP Machines, postscript displays,
HTTP/NG ? Why functional programming is not dominated ?

Tecnical evolution depends not from technical elegance but from some
other reasons, in some cases non-technical ('to be in right place in
right time'.)

Most of today-s technologies are nightware. Can you imagine something
more ugly, than HTML/DHTML/JavaScript interface generated partially
from
template, partially by println statements from Java backend ?
But most of general-purpose development in the world use this.

> > Moreover, most large-scale projects have infrastructure teams whose
> > role is to "hide" the COTS middleware behind their own domain-specific
> > wrapper facades, so the fact that a new technology is defined to hide
> > some quirks of existing middleware often doesn't really matter all
> > that much in practice.
>
> Hmmm... I can't say I like this line of reasoning. It really boils down
> to "Well, we can always put another layer of abstraction on top, so the
> bad design of the layer below doesn't matter." Far too much in computing
> is done with kind of attitude, to the detriment of the entire industry.
>

I ca say about our projects - it's works.

> > >> Moreover, the complexity and (mis)feature insanity of the
> > >> specifications hugely complicates the ORB implementation. The
> > >> result is a run time that is far slower and far larger than
> > >> necessary.
> >

Who care, if you work not in area of embedded systems ?

> CORBA was a great thing in its day. But the specification process is too
> inflexible, and fundamental design problems (such as the inability to
> version IIOP properly) make it just about impossible to incorporate
> technical improvements into the platform. As a former OMG Architecture
> Board member, I can definitely assure you that topics like fixing IIOP
> make people's hair stand on end, due to the immense technical and
> marketing difficulty of doing so, plus the weight of legacy and backward
> compatibility issues.
>

yes. but the same would be with any protocol.
And how you see ICE from few years from now ?
For example - look's at ICE mapping of strings to C++. std::string
in utf8.
By now dominating idiom for unicode in C++ is use std::wstring,
becouse std::string in utf8 is quite non-regular, most of standard
string methods, such as x.find_first_of() is non-functional for
utf8-encoded strings.
So, at some time you will have decison: switch to wchar_t and broke
depended code, or have fundamental flaw in future ?
O'key, can you imagine list of such problems durning next 10 years ?

> > >> (If you are interested in more reasons for why I believe that CORBA
> > >> isn't the answer, have a look at the introduction to the Ice
> > >> documentation at http://www.zeroc.com/download.html.)
> >

> > >> Ice is similar to CORBA in many ways: it gives you language and
> > >> platform neutral OO RPC, just like CORBA. It provides all of the
> > >> features of CORBA (but does it in ways that are much simpler and
> > >> more efficient),
> >

But to be succesfull, technology must not be 'better CORBA' but
'more than CORBA' or 'other then CORBA'.

Of course, this is in contradiction with technical quality
('fix bug before developing something new'), but sorry -- we live in
the
real world.

> ....

>
> No, I'm not talking about BOA-to-POA transitions here, I'm talking
> switching from things such as Orbix 2000 to ORBacus, or Visibroker to
> TAO.
>

Strange. I was involved in VisiBroker/TAO translation, of course we
touch
source code of target system in many places, but in general it was not
very
hard.

> > I agree that this is a
> > painful process, though one that once done makes life MUCH better for
> > future migrations.
>
> Well, why is it painful if things are supposedly so well standardized?
> You mean painful because of the BOA? But the BOA was a standard too!
> Bidirectional IIOP and CORBA security were standards too, as I recall. What
> has become of those?
>
> > >> - The much-lauded source code compatibility in practice does not
> > >> exist. ORBs are usually full of vendor-specific extensions (often
> > >> not clearly identified as such) that can make it very difficult to
> > >> port existing code to a new ORB.
> >

(Currently our cbroker compiles with 6 different ORB.)
We have one near 1 MLOC project, which can work with 3 ORB.

>
> > As usual, there are a
> > straightforward set of patterns and tools to apply to make this work
> > fine in practice (not unlike what we've done with ACE, which makes
> > cross-platform C++ concurrent network programming straightforward).
> > Again, the CORBA auto-conf tool <http://corbaconf.kiev.ua> makes life
> > much easier.
>
> We don't seem to have spoken to the same people, or seem to have
> interpreted their messages differently. As far as I am concerned, if I
> need an auto-conf tool to write code for more than one middleware
> platform, there is something wrong with the middleware. Installing and

Hmm. let's do mental experiment:
imagine that some group receive documentaion for protocol and language
mapping and decide to write own ICE implementation. I can guarantuee,
than after this we will needed in something like ice-conf ;)

> Well, I don't think it is. The dream of interoperable and portable
> software has by and large not been realized by CORBA. Maybe that isn't
> CORBA's fault -- maybe the dream is unrealistic. I just spoke to a large

More second, than first. But CORBA is a step.

I hope that ICE will find good market segment, but not in mainstream.
For a pity, that it was possible to refactor CORBA, but this was not
to be
done. Looks like 'design by commite' fault.

As for me, I enjoy reading ICE documentation and think to do something
with it (when I will have free time), but from business point of view,
when we need to choose - what distributed technology to use in typical
business system, I'm afraid that in many cases, the answer is steel
CORBA or J2EE.

But if I would program something totally new, not locked to existing
infrastructure -- I will think about ICE quite seriously.

Michi Henning

unread,

Jul 23, 2003, 12:06:21 AM7/23/03

On Wed, 23 Jul 2003, Frank Pilhofer wrote:

> Basically, I wasn't making any kind of statement on the other 90%,
> since I don't know 80% of all CORBA specs. (I decided to weasel out
> on that one.) I am certainly aware of specs with numerous problems
> (CCM comes to mind) and specs that are nothing but a problem.

Right. BTW -- I don't know all of the other 90% either. (I suspect that
no-one does). But I'm not having difficulty in finding serious problems
in the bits that I do know.

> The picture looks a bit brighter when you consider available specs
> only, ignoring adopted specs that were never implemented. (And I
> wouldn't mind if the OMG enforced this policy a bit more harshly.)

Right, it certainly does look brighter that way. On the other hand,
there are plenty of problems with even those. As far as enforcing the
policy more, don't I wish. I suspect that any organization that permits
specifications to be published that do not have a reference
implementation will suffer the same problems, no matter how well
organized: it's simply too difficult to spot the flaws in a
specification unless people have actually gone through the pain of
implementing and using it.

> > A better C++ mapping for CORBA certainly would be very nice. But it
> > won't fix all the other things that need fixing. And, of course, as
> > a customer, what are you going to do? Throw out all the old code? Or
> > maintain two code bases side by side? Or keep the old code for the
> > old applications and write all the new applications using the new
> > mapping?
> >
>
> I think the same applies to migrating from CORBA to Web Services or Ice.

Most assuredly, yes. The way new technologies grow is through customers
who don't have much in terms of legacy code and are therefore free to
try something new. That was the case with CORBA as well when it started
out. Of course, Ice, just like CORBA, will become old technology
eventually. That's inevitable because nothing lasts forever. In the mean
time, those customers that adopt Ice get a fresh start and aren't
burdened by a lot of historical baggage (but, of course, will be in ten
or so years time, just as anyone else is who uses any kind of
computing technology).

> I agree that sitting down and getting cross-vendor standards good and
> right is hard. It's a full time job, and these days, too few companies
> expend software architects to work on OMG specs all day - and if they
> do, some may be frustrated that they're being slowed down by other
> company reps that might not be as accessible for discussions.

Yes, it's hard. It's hard enough technically, and impossibly hard
commercially and politically. Years in the OMG forced me to accept this.
To expect commercial competitors to sit around the table like lambs and
simply share the pie is naive: it won't ever happen.

Maybe that is one reason for why so many excellent software products
were produced by a very small number of people, and why there are so few
excellent software products that were produced by a very large number of
people or a consortium. (Open Source projects seems to be the one exception
but, even there, it seems that those Open Source projects that are
substantially done by an initially small number of people are more
successful than those that are started as a large-scale effort from
scratch.) Quite possibly, the only way to keep architectural and design
coherence is to keep the number of contributors small until the
architecture and the design are solid enough to withstand the pushing and
prodding of large numbers of contributors. (That's another way of saying that
too many cooks spoil the broth...)

> However, you could also argue that bypassing the process and publishing
> something on your own is the easy way out.

In some ways, yes. Ice isn't burdened by politics, design-by-committe,
or legacy issues, so it is far easier to be technically excellent with
Ice than it is with CORBA. But I wouldn't exactly call it the easy way
out. The investment and risks are great. For me personally, it would
have been safer and financially more astute to stick with CORBA. But I
got sick of fighting a losing battle...

Michi Henning

unread,

Jul 23, 2003, 12:43:29 AM7/23/03

On 22 Jul 2003, Ruslan Shevchenko wrote:

> true. From other side: where are LISP Machines, postscript displays,
> HTTP/NG ? Why functional programming is not dominated ?

Oh boy, we could be here forever talking about this :-) HTTP/NG is
really a pity though: that was one elegant piece of work. Would have
been so nice if that had been adopted for both the Web and CORBA back
then. The computing landscape would surely look different today if that
had happened.

> Tecnical evolution depends not from technical elegance but from some
> other reasons, in some cases non-technical ('to be in right place in
> right time'.)

Completely agree. A lot of dominant technologies are partly due to
historical accident. That's true for non-computing technologies as much
as computing ones, I believe.

> Most of today-s technologies are nightware. Can you imagine something
> more ugly, than HTML/DHTML/JavaScript interface generated partially
> from
> template, partially by println statements from Java backend ?

I think I can, but I admit, your example is a contender for one of the
top spots :-)

> > > Moreover, most large-scale projects have infrastructure teams whose
> > > role is to "hide" the COTS middleware behind their own domain-specific
> > > wrapper facades, so the fact that a new technology is defined to hide
> > > some quirks of existing middleware often doesn't really matter all
> > > that much in practice.
> >
> > Hmmm... I can't say I like this line of reasoning. It really boils down
> > to "Well, we can always put another layer of abstraction on top, so the
> > bad design of the layer below doesn't matter." Far too much in computing
> > is done with kind of attitude, to the detriment of the entire industry.
> >
> I ca say about our projects - it's works.

I have no doubt about that. We use layering in software all the time to
get to higher levels of abstraction. It grates on me though when a layer
is introduced purely to hide the ugliness of the layer below it. That's
just a waste of computing cycles and person power. (One of my pet
theories is that computing would have far fewer layers if people paid
more attention to API design.)

> > > >> Moreover, the complexity and (mis)feature insanity of the
> > > >> specifications hugely complicates the ORB implementation. The
> > > >> result is a run time that is far slower and far larger than
> > > >> necessary.
> > >
>
> Who care, if you work not in area of embedded systems ?

It really depends on the situation. In many cases, performance simply
isn't an issue and it doesn't matter. In other cases, it is important.
Quite often, as little as a 30% difference in performance can make or
break the commercial success of a product. And generally, given all else
being equal, the better performing product tends to win. (Some part of
this is due to a general obsession with performance -- it seems to be
one of the very few measuring sticks that everyone can agree on. Even
when performance doesn't matter at all, as for someone who uses their
computer exclusively to do non-performance sensitive things, people
still tend to ask "which one is faster" and buy that. I guess we've
educated our users over many years to behave that way...)

> > CORBA was a great thing in its day. But the specification process is too
> > inflexible, and fundamental design problems (such as the inability to
> > version IIOP properly) make it just about impossible to incorporate
> > technical improvements into the platform. As a former OMG Architecture
> > Board member, I can definitely assure you that topics like fixing IIOP
> > make people's hair stand on end, due to the immense technical and
> > marketing difficulty of doing so, plus the weight of legacy and backward
> > compatibility issues.
>
> yes. but the same would be with any protocol.

Actually, no. Much of the difficulty with IIOP stems from three facts:

1) The encoding rules are not separately versioned from the
protocol state machine. This means that the two cannot be
versioned independently and that no change can ever be
introduced to the encoding in a backward-compatible way.

2) Encapsulations do not carry their own version number. This
means that data using a newer encoding can tunnel to places
that only understand the older encoding, with no clear way of
diagnosing the problem, other than random unmarshaling
errors. (This is the case with all the IDL data types that
were added over time, such as fixed types, wide characters,
or value types. If any of these gets sent to an older
implementation that doesn't understand these types inside an
encapsulation, you get unmarshaling errors, with no real
indication as to what really went wrong.)

3) Not everything that should be encapsulated is encapsulated.
For example, the data part of an Any value is not
encapsulated. This is inefficient, because the only way to
pull and Any off the wire is to unmarshal it. In turn, that
prevents an intermediate process, such as an event service,
from running at a version level that is lower than any of its
connected parties. This makes it very difficult to phase in
version changes gradually.

These problems make it hard to touch any part of IIOP without breaking
something or other. (Despite taking great care, all updates to IIOP had
to be revised after the initial published version because there was
something or other that was overlooked.) The Ice protocol avoids those
versioning problems. That's not to say that changing a protocol or
encoding version is painless. But at least, there are well-defined
semantics associated with such version changes, and the design guarantees
that version mismatches will be caught and diagnosed as such, and that
backward compatibility won't be lost. That's certainly a better picture
than for IIOP.

> And how you see ICE from few years from now ?
> For example - look's at ICE mapping of strings to C++. std::string
> in utf8.
> By now dominating idiom for unicode in C++ is use std::wstring,
> becouse std::string in utf8 is quite non-regular, most of standard
> string methods, such as x.find_first_of() is non-functional for
> utf8-encoded strings.
> So, at some time you will have decison: switch to wchar_t and broke
> depended code, or have fundamental flaw in future ?

Right. There was a trade-off between using wchar_t and its associated
memory overheads and UTF-8. We decided on UTF-8, despite the issues you
mention.

> O'key, can you imagine list of such problems durning next 10 years ?

There will be problems, no doubt, as there will be for any other
technology. How long will CORBA's list of problems be 10 years from now?

> But to be succesfull, technology must not be 'better CORBA' but
> 'more than CORBA' or 'other then CORBA'.

Ice does quite a few things that CORBA doesn't do, and those things that
CORBA can do, Ice does equally well or better, I believe. At least for some
people, that may be a sufficient reason to give Ice a closer look.

> > No, I'm not talking about BOA-to-POA transitions here, I'm talking
> > switching from things such as Orbix 2000 to ORBacus, or Visibroker to
> > TAO.
> >
>
> Strange. I was involved in VisiBroker/TAO translation, of course we
> touch
> source code of target system in many places, but in general it was not
> very
> hard.

It very much depends on how much code there is, how the build environment
is put together, how well the code was written in the first place, how
experienced the people are, how many vendor-specific extensions were
used, etc. There are lots of variables. To be fair, I've also seen
transitions that were fairly painless. For those, the people who wrote
the code were experienced and managed to avoid a lot of the pitfalls
up-front. (These were generally not people who were using CORBA for the
first time, or with only one ORB.) The point is that, despite
standardization, the pitfalls are still there. It would be a lot nicer
and cheaper if they weren't.

> > > >> - The much-lauded source code compatibility in practice does not
> > > >> exist. ORBs are usually full of vendor-specific extensions (often
> > > >> not clearly identified as such) that can make it very difficult to
> > > >> port existing code to a new ORB.
> > >
>
> (Currently our cbroker compiles with 6 different ORB.)
> We have one near 1 MLOC project, which can work with 3 ORB.

I have no doubt that this is true. But getting there isn't as easy as it
should be. (And I'm sure you didn't get this portability without thought,
effort, additional tools, and expense.)

> Hmm. let's do mental experiment:
> imagine that some group receive documentaion for protocol and language
> mapping and decide to write own ICE implementation. I can guarantuee,
> than after this we will needed in something like ice-conf ;)

Good point. For Java, they most likely wouldn't. For C++, it's harder
to nail everything down, but I think it could be done without such a tool
too.

> > Well, I don't think it is. The dream of interoperable and portable
> > software has by and large not been realized by CORBA. Maybe that isn't
> > CORBA's fault -- maybe the dream is unrealistic. I just spoke to a large
>
> More second, than first. But CORBA is a step.

Most definitely. Ice is the next one :-)

> I hope that ICE will find good market segment, but not in mainstream.
> For a pity, that it was possible to refactor CORBA, but this was not
> to be
> done. Looks like 'design by commite' fault.
>
> As for me, I enjoy reading ICE documentation and think to do something
> with it (when I will have free time), but from business point of view,
> when we need to choose - what distributed technology to use in typical
> business system, I'm afraid that in many cases, the answer is steel
> CORBA or J2EE.

For sure. There are projects for which Ice is a good choice, and there
are ones (currently more) for which it isn't. That doesn't mean this
balance can't change some time in the future.

> But if I would program something totally new, not locked to existing
> infrastructure -- I will think about ICE quite seriously.

Thanks! I hope you'll have fun with it. Please let us know if you have
any feedback. You can join in on the forum on our website.

nos...@logcode.com

unread,

Jul 23, 2003, 2:52:46 AM7/23/03

"Michi Henning" <mi...@triodia.com> writes:
[...lots of details snipped...]

> So, the Ice protocol gets the most performance possible for the least
> complexity possible: on WANs, bandwidth matters, and Ice minimizes
> that. On LANs, the bottlenecks are entirely elsewhere, so "receiver-makes-
> it-right" doesn't buy us anything.

This sounds intuitively right but do you (or anyone else) have any benchmarks
to back it up?
--
Orjan Petersson, Logcode SARL
The email address in the From: header is valid

Michi Henning

unread,

Jul 23, 2003, 4:07:06 AM7/23/03

On 23 Jul 2003 nos...@logcode.com wrote:

> "Michi Henning" <mi...@triodia.com> writes:
> [...lots of details snipped...]
> > So, the Ice protocol gets the most performance possible for the least
> > complexity possible: on WANs, bandwidth matters, and Ice minimizes
> > that. On LANs, the bottlenecks are entirely elsewhere, so "receiver-makes-
> > it-right" doesn't buy us anything.
> This sounds intuitively right but do you (or anyone else) have any benchmarks
> to back it up?

We tried it. Depending on the exact implementation, you may get a very
minor improvement if you avoid byte swapping. But that improvement is
easily swamped by other factors. In particular, it is noticeable only if
there is a lot of data to swap per request. But, in that case, the
operation implementation will do something with the data, which is
typically orders of magnitude more expensive than the byte swapping, so
the cost of byte swapping disappears in the noise. Things like threading
models and lock contention also distort the picture -- it's not a simple
"this is faster than that" situation. (Remember that the Ice protocol is
byte-aligned for all data types. So, if an int arrives on the wire, we
copy it out of the transport buffer byte-for-byte anyway. Whether the copy
is done in forward or reverse order makes no difference.)

Another example is that, on WANs, we get substantially better
performance with compression enabled because the limiting factor is
bandwidth. On the other hand, on high-speed LANs, compression actually
slows things down: the CPU cycles spent doing the compression/uncompression
cost more than just throwing the data onto the wire in uncompressed form.

Marc Laukien

unread,

Jul 23, 2003, 4:59:50 AM7/23/03

Ruslan Shevchenko wrote:
> [...]

> By now dominating idiom for unicode in C++ is use std::wstring,
> becouse std::string in utf8 is quite non-regular, most of standard
> string methods, such as x.find_first_of() is non-functional for
> utf8-encoded strings.
> So, at some time you will have decison: switch to wchar_t and broke
> depended code, or have fundamental flaw in future ?
> O'key, can you imagine list of such problems durning next 10 years ?
>

You can actually use both, because we offer conversion from UTF-16
std::wstring to UTF-8 std::string (and vice versa). Using std::string
seemed like the best overall choice for us for the standard Ice C++
mapping of a string.

Note that there is no string and wstring in Slice (Slice = the IDL of
Ice). We only have string. Having two string types in an interface
definition language doesn't make sense to me. Why would I want to decide
if I want to use string or wstring in the interface definition? That's
really a mapping issue only, and not relevant for an interface definition.

Besides, thanks to the metadata approach in Slice, we can always add a
metadata directive like "cpp:wstring", which instructs the Slice
translators to map string to std::wstring instead of std::string.
(Selectively, to that no old code breaks.)

> [...]

> As for me, I enjoy reading ICE documentation and think to do something
> with it (when I will have free time), but from business point of view,
> when we need to choose - what distributed technology to use in typical
> business system, I'm afraid that in many cases, the answer is steel
> CORBA or J2EE.
>
> But if I would program something totally new, not locked to existing
> infrastructure -- I will think about ICE quite seriously.
>

Thanks. I really think people should simply have a look at the Ice
documentation and judge for themselves. Again, we don't want to start an
Ice vs. CORBA flamewar, but we do want to show that there are modern
alternatives to CORBA. If somebody starts a new project, then he can
make an informed decision about whether to use Ice or CORBA.

-- Marc

Marc Laukien

unread,

Jul 23, 2003, 5:17:12 AM7/23/03

nos...@logcode.com wrote:
> "Michi Henning" <mi...@triodia.com> writes:
> [...lots of details snipped...]
>
>>So, the Ice protocol gets the most performance possible for the least
>>complexity possible: on WANs, bandwidth matters, and Ice minimizes
>>that. On LANs, the bottlenecks are entirely elsewhere, so "receiver-makes-
>>it-right" doesn't buy us anything.
>
> This sounds intuitively right but do you (or anyone else) have any benchmarks
> to back it up?

We have proof of how much more compact the Ice encoding compared to IIOP
is. From page 476 of the Ice documentation:

Sequence of CDR Size Ice Size Extra cost
100 Strings of CDR
of Length

0 804 101 696%
4 1204 501 140%
8 1604 901 78%
16 2004 1701 18%

Note that this is without compression. If you switch on compression,
then the difference is of course much more than that.

As for latency and throughput, there are so many other factors which are
important, and some of the real-time CORBA vendors did a great job with
making their ORB very, very fast (like ORBexpress). Ice is not (yet) as
fast as these very-high-speed ORBs (but we are working on that), but I'm
sure if you compare it with multi-purpose ORBs, you will find that Ice
is faster than most of them.

There is a thread on our message board about performance which you might
find interesting. See:

http://www.zeroc.com/vbulletin/showthread.php?threadid=27

-- Marc

Steve Vinoski

unread,

Jul 23, 2003, 9:04:20 AM7/23/03

"Michi Henning" <mi...@triodia.com> wrote in message news:<k2aTa.8550$OM3....@news-server.bigpond.net.au>...

> Fortunately, the people who worked on
> ISO C++ standardization were, on average, much better at C++
> than the ones who worked on the CORBA C++ mapping.

Ignoring the personal nature of the above malignment for the moment, I can
say that the statement is completely untrue.

The C++ mapping was largely put together by three people: Doug Lea, Mark
Linton, and me. Doug and Mark were true pioneers in C++, writing some of the
first significant libraries and frameworks in the language. I also have a
"little" expertise in C++; by 1994 I had been using the language for 6 years
and had written tons of code in that time, including some very early
embedded C++. The three of us put the mapping together as a compromise
between two camps within the OMG who were no longer on speaking terms. Our
hands were tied as to how the mapping could look technically. The only way
to improve the resulting mapping would have been to iron out the political
differences first, which we as technical people did not have the skills or
positions to do, and which would have taken quite awhile, as it had already
taken two years to get to the point in 1994 where we wrote the compromise mapping.

There's also the little matter of the poor quality of the C++ compilers that
were around at that time. I was still studying generated code from the
compilers then, just as early users of compilers had done 20 years prior,
because I would regularly find serious bugs in them. Finding portable C++
constructs then was a lot of work.

CORBA has been, and continues to be, a huge success as both a technical
standard and a commercial platform. It just celebrated its 12th birthday.
You can whinge/whine about little technical problems in it all you want --
don't you have anything better to do, honestly? -- but that won't change the
fact some of the largest and most mission-critical systems out there are
CORBA-based. Every time you make a phone call, for example, you're touching
a CORBA-based system somewhere. I'm fairly certain, OTOH, that Ice will melt
and run down the drain long before it reaches 12.

--steve

--
Steve Vinoski vinoski at iona.com
Chief Engineer, Product Innovation
IONA Technologies http://www.iona.com/hyplan/vinoski/
200 West St. Waltham, MA USA 02451

Steve Vinoski

unread,

Jul 23, 2003, 9:12:33 AM7/23/03

"Michi Henning" <mi...@triodia.com> wrote in message news:<%uaTa.8626$OM3....@news-server.bigpond.net.au>...

> To be fair, getting a mapping off the ground back then, before ISO C++
> was available, was a hard ask. But then again, there was an alternative
> mapping submitted by Hyperdesk at the time. Coincidentally, that mapping
> was quite similar in flavor (and memory-management safety) to the Ice
> C++ mapping. Sadly, the Hyperdesk mapping was rejected on political
> grounds and factional infighting as well as on (in hindsight, entirely
> inappropriate and misguided) performance grounds.

Bzzt. Wrong again. You're using performance results of today to judge the
performance results in 1993. I can tell you for a fact that the HyperDesk
mapping in 1993 was 4-5 times slower than the standardized mapping, due to
the overhead of reference counting. Several of us independently measured it,
and we all agreed on the results. We were there, you weren't. Compilers and
multithreading support have since vastly improved to the point where this
performance overhead is greatly reduced.

Another interesting note about the HyperDesk mapping is that the guy who
designed it now regularly uses approaches embodied by the OMG C++ mapping,
such as avoiding ref counts and passing ownership around, to ensure that his
C++ code is as fast as possible. And his code is damn fast. I know all this
because he and I have worked together for the past 10 years. He currently
sits right next to me.

Steve Vinoski

unread,

Jul 23, 2003, 9:15:58 AM7/23/03

"Michi Henning" <mi...@triodia.com> wrote in message news:<gN9Ta.8495$OM3...@news-server.bigpond.net.au>...

> But as a world-recognized expert on CORBA, and after
> having used and implemented it daily for many years, I would think that I
> could remember what I need to know. Sadly, this isn't so. Maybe there is
> something wrong with my memory (but then, lots of other people seem to have
> the same problems, so I don't think so).

It's true that the C++ mapping is more difficult than it should be,
but c'mon Michi, if you have to look up the rules every time you write
a program, then you really must have a memory problem. We both know
you're exaggerating. I never look up any of those rules -- they're
actually fairly easy to remember, much easier than most people
realize. For the odd cases, such as the ownership retaining operations
associated with TypeCodes and DII interfaces, a quick look at the
signature tells me what I need to know. If you honestly have to use
our book to look up the rules every time you write an application, it
begs the question of how you wrote those parts of the book in the
first place!

So you were able to make a more compact, easier-to-use, and totally
proprietary and non-standard C++ mapping, all without any of the
overhead of consensus building, standards bodies, or existing products
and applications, almost ten years after the OMG C++ mapping was
written. Wow. That's underwhelming. Pretty much any reader of this
newsgroup could do the same. And what would that get them? Yet another
piece of proprietary middleware -- just what the world needs.

Michi Henning

unread,

Jul 23, 2003, 9:39:55 AM7/23/03

"Steve Vinoski" <vin...@ieee.org> wrote in message
news:6c2690b5.03072...@posting.google.com...

> "Michi Henning" <mi...@triodia.com> wrote in message
news:<k2aTa.8550$OM3....@news-server.bigpond.net.au>...
> > Fortunately, the people who worked on
> > ISO C++ standardization were, on average, much better at C++
> > than the ones who worked on the CORBA C++ mapping.
>
> Ignoring the personal nature of the above malignment for the moment, I can
> say that the statement is completely untrue.

Steve, as I said to you in private e-mail, that wasn't a personal attack on
you.
But, I admit, I got carried away with the above comment, so I apologize and
withdraw it -- it was over the top. To the best of my knowledge, it is true
though
that the CORBA C++ mapping and the ISO C++ standard had no influence on
each other.

> There's also the little matter of the poor quality of the C++ compilers that
> were around at that time. I was still studying generated code from the
> compilers then, just as early users of compilers had done 20 years prior,
> because I would regularly find serious bugs in them. Finding portable C++
> constructs then was a lot of work.

As I said earlier, doing a mapping in those days was a hard ask, without having
the benefit of ISO C++ features. But memory management issues could have been
dealt with in a far better way, even back then. (I'll reply to your other post
on this
separately.)

> CORBA has been, and continues to be, a huge success as both a technical
> standard and a commercial platform. It just celebrated its 12th birthday.
> You can whinge/whine about little technical problems in it all you want --
> don't you have anything better to do, honestly? --

I don't see the technical problems with CORBA as little (and the
C++ mapping is only a part of the problems.) I've mentioned many
of them in previous posts, so I won't repeat them here again.

> but that won't change the
> fact some of the largest and most mission-critical systems out there are
> CORBA-based. Every time you make a phone call, for example, you're touching
> a CORBA-based system somewhere.

I'm sure that is true. Just as it is probably true that I'm touching some COBOL
system every time with go to an automatic teller machine. So what? We've
written mission-critical system in just about every computing technology and
language
there ever was, starting with machine code and working our way up from there.
That's a testament to human ingenuity and patience, not a testament to the
particular technology that was used at the time. (A long time ago, people built
the pyramids without anything that we would call technology today. Same thing:
it's a tribute to the people much more than the technology.)

> I'm fairly certain, OTOH, that Ice will melt
> and run down the drain long before it reaches 12.

Dunno -- I guess we'll have to wait at most 12 years to find out :-)

Marc Laukien

unread,

Jul 23, 2003, 9:48:09 AM7/23/03

Steve Vinoski wrote:
> CORBA has been, and continues to be, a huge success as both a technical
> standard and a commercial platform. It just celebrated its 12th birthday.
> You can whinge/whine about little technical problems in it all you want --
> don't you have anything better to do, honestly? -- but that won't change the
> fact some of the largest and most mission-critical systems out there are
> CORBA-based. Every time you make a phone call, for example, you're touching
> a CORBA-based system somewhere. I'm fairly certain, OTOH, that Ice will melt
> and run down the drain long before it reaches 12.
>

If you write something like this about Ice, I have to respond.

It is very clear to me that CORBA is slowly dying. Certainly, it will
never go away completely, and I also don't dispute at all that CORBA is
deployed in many mission critical systems (just like mainframes and
cobol programs). But I see very little traction in the CORBA world
anymore. Fact is, that there are much fewer dollars invested in CORBA
than this used to be the case, both by vendors and customers. And not
only due to the poor economy, no, CORBA had an overproportional rapid
decline in the last years. Some CORBA vendors even tried to downplay the
fact that they are CORBA vendors. And the OMG now focuses much more on
MDA than on CORBA.

Given this situation, I believe that Ice has a brilliant future. I can
tell you from the many companies that are currently evaluating Ice, or
already building it in their next-generation product, that there is a
lot of interest in a new, easy-to-learn, "technical middleware" platform.

Of course, your opinion might differ, and ultimately only time will tell.

-- Marc

Michi Henning

unread,

Jul 23, 2003, 9:55:05 AM7/23/03

"Steve Vinoski" <vin...@ieee.org> wrote in message

news:6c2690b5.0307...@posting.google.com...

>
> It's true that the C++ mapping is more difficult than it should be,
> but c'mon Michi, if you have to look up the rules every time you write
> a program, then you really must have a memory problem. We both know
> you're exaggerating.

Well, there a lot of things I do remember, of course, but I frequently
find myself having to look things up. That's just how it is.

> I never look up any of those rules -- they're
> actually fairly easy to remember, much easier than most people
> realize.

Not too hard to remember, no. It's just all the damn little exceptions
to rules that keep tripping me up. Just think of

ref->foo(bar());

where bar() returns something that I want to pass to foo(). If bar()
returns a variable-length value, I leak memory. Not nice. Similar:

cout << ref->bar() << endl;

Again, that's a memory leak. Or just

ref->bar();

That's a memory leak too. It's easy to make that mistake, and quite
difficult to find it.

> For the odd cases, such as the ownership retaining operations
> associated with TypeCodes and DII interfaces, a quick look at the
> signature tells me what I need to know.

Sure, I know how to find out too. But, when I write code, and stare at
a statement I've just written, and I'm not sure yet again whether I should
or shouldn't deallocate the return value, and then have to go and look it
up, I'm annoyed. Why should I have to even worry about this sort of thing?

> If you honestly have to use
> our book to look up the rules every time you write an application, it
> begs the question of how you wrote those parts of the book in the
> first place!

One wonders, yes :-)

> So you were able to make a more compact, easier-to-use, and totally
> proprietary and non-standard C++ mapping, all without any of the
> overhead of consensus building, standards bodies, or existing products
> and applications, almost ten years after the OMG C++ mapping was
> written. Wow. That's underwhelming.

Well, yes, it doesn't take a mental giant to do it, just some experience. But
we
did it, when nobody else did. The result is an easy-to-use C++ mapping that
is free from memory management pitfalls and inconsistencies (quite apart
from all the other nice things that Ice does). To me, that's a step in the
right direction.

> Pretty much any reader of this
> newsgroup could do the same. And what would that get them? Yet another
> piece of proprietary middleware -- just what the world needs.

Maybe so. It also gets rid of all those pesky little memory leaks though, and
the lost half-hour figuring out why the program isn't working right due to
memory corruption. Maybe that's not what the world needs -- time will tell.

Ice will be interesting to some people. That's good enough for us.
(As I said earlier, we are happy to leave world domination to others :-)

Marc Laukien

unread,

Jul 23, 2003, 10:02:17 AM7/23/03

Steve Vinoski wrote:
> So you were able to make a more compact, easier-to-use, and totally
> proprietary and non-standard C++ mapping, all without any of the
> overhead of consensus building, standards bodies, or existing products
> and applications, almost ten years after the OMG C++ mapping was
> written. Wow. That's underwhelming. Pretty much any reader of this
> newsgroup could do the same. And what would that get them? Yet another
> piece of proprietary middleware -- just what the world needs.

Yes, the world definitely needs this. I know of so many C++ developers
who don't use CORBA simply because of the terrible C++ mapping.

By the way, I agree with you that writing a good C++ mapping isn't so
hard. This makes it even more confusing to me why there is no new C++
mapping for CORBA. The only answer I can think of is that neither the
CORBA vendors nor the OMG care.

Besides, Ice is not proprietary. It is available under the GPL. We only
charge for licenses if somebody doesn't want to make their programs
available under GPL-like terms. See http://www.zeroc.com/licensing.html

-- Marc

Michi Henning

unread,

Jul 23, 2003, 10:22:21 AM7/23/03

"Steve Vinoski" <vin...@ieee.org> wrote in message

news:6c2690b5.03072...@posting.google.com...

> "Michi Henning" <mi...@triodia.com> wrote in message
news:<%uaTa.8626$OM3....@news-server.bigpond.net.au>...
> >

> > Sadly, the Hyperdesk mapping was rejected on political
> > grounds and factional infighting as well as on (in hindsight, entirely
> > inappropriate and misguided) performance grounds.
>
> Bzzt. Wrong again. You're using performance results of today to judge the
> performance results in 1993. I can tell you for a fact that the HyperDesk
> mapping in 1993 was 4-5 times slower than the standardized mapping, due to
> the overhead of reference counting. Several of us independently measured it,
> and we all agreed on the results. We were there, you weren't. Compilers and
> multithreading support have since vastly improved to the point where this
> performance overhead is greatly reduced.

Hmmm... I'm having problems with this (as I mentioned to you about two years
ago).
Here is my reasoning:

- If I benchmark a mapping and only measure the code that is part of the
mapping then
the mapping will be the faster the less work it does. So, if I have a
low-level mapping,
I'll get good performance numbers. But that only is true if I only focus on
the mapping.
In other words, if the mapping forces the calling application code to
allocate and
deallocate memory, then the cost of that should logically be counted as part
of the
cost of the mapping, even though the allocation and deallocation takes place
in
application code. In other words, a higher-level mapping that hides memory
management has to do all the same things that, with a low-level mapping, are
made
the responsibility of application code. Ergo, the low-level and high-level
mapping
should run at almost the same speed (ignoring threading issues for the
moment).

- I find it hard to see how reference counting can be as expensive as that. I
was
part of the team that implemented kernel threads (POSIX draft 4) when I
worked
for Pyramid Technology in the early nineties. Even back then, we had mutexes
implemented that could be acquired without trapping into the kernel or
the scheduler if the lock wasn't under contention. A mutex could
be acquired in two instructions each, entirely in user mode. (Please, don't
hold
me to the precise instruction count, it's been too long -- it might have been
three
instructions. The point is, the cost of acquiring and releasing a lock that
wasn't under contention was very, very small. When the lock was under
contention, it got more expensive, of course, because that forces a
context switch.)

Given that, I find it hard to see how reference counting alone can account
for
such a large performance difference. What's the total cost of reference
counting? Something like a function call, dereferencing a pointer,
doing an increment, and aquiring and releasing the lock. Compared to
the cost of calling the memory allocator, that's nothing. So, I honestly
do not see what could be causing a factor of four to five in performance
difference, unless the lock implementation is terrible.

Regardless of what it was like back then, the same arguments certainly don't
apply today. If you look at the Ice source code, you will see that Ice
internally
uses the same constructs that are used for the application APIs, that is,
everything
is passed by value and reference counted (thread-safe, of course). The
performance
impact is negligible except for a small handful of really performance-critical
places.
And for those, we still use the same reference-counted pass-by-value mechanism.
We use things such as lazy initialization and caching to get the performance we
need instead of falling back to raw pointers.

Overall, this approach works really well. There are no memory management issues
in Ice simply because no-one has to do memory management. This does wonders
for the clarity of the code, the defect count, programmer sanity, and
development
time.

> Another interesting note about the HyperDesk mapping is that the guy who
> designed it now regularly uses approaches embodied by the OMG C++ mapping,
> such as avoiding ref counts and passing ownership around, to ensure that his
> C++ code is as fast as possible. And his code is damn fast. I know all this
> because he and I have worked together for the past 10 years. He currently
> sits right next to me.

Sure, I know whom you speak of (hi Bob! :-) Yes, when I have some really
performance-critical piece of code where I absolutely must squeeze the last
ounce of performance and every CPU cycle counts, I resort to techniques such
as that too. They definitely have their place. However, worrying about the cost
of that when I'm just about to go on the wire and make a remote procedure call
that takes orders of magnitude longer to run than a local procedure call, the
handful of lost cycles doesn't matter. (In case you wonder, yes, Ice uses
collocation optimizations, so calls that are in the same address space and
use the same communicator are very fast -- admittedly not as fast as an
ordinary function call though.)

Steve Vinoski

unread,

Jul 23, 2003, 4:06:42 PM7/23/03

"Michi Henning" <mi...@triodia.com> wrote in message news:<xSwTa.10402$OM3....@news-server.bigpond.net.au>...

> "Steve Vinoski" <vin...@ieee.org> wrote in message
> news:6c2690b5.03072...@posting.google.com...
> > "Michi Henning" <mi...@triodia.com> wrote in message
> news:<%uaTa.8626$OM3....@news-server.bigpond.net.au>...
> > >
> > > Sadly, the Hyperdesk mapping was rejected on political
> > > grounds and factional infighting as well as on (in hindsight, entirely
> > > inappropriate and misguided) performance grounds.
> >
> > Bzzt. Wrong again. You're using performance results of today to judge the
> > performance results in 1993. I can tell you for a fact that the HyperDesk
> > mapping in 1993 was 4-5 times slower than the standardized mapping, due to
> > the overhead of reference counting. Several of us independently measured it,
> > and we all agreed on the results. We were there, you weren't. Compilers and
> > multithreading support have since vastly improved to the point where this
> > performance overhead is greatly reduced.
>
> Hmmm... I'm having problems with this (as I mentioned to you about two years
> ago).
> Here is my reasoning:

[snip]

A crucial aspect that you're missing from your reasoning is that one
of the original applications for the C++ mapping was going to be a
non-distributed system. I'm talking about Fresco, an X Windows System
toolkit/framework that Mark Linton was working on. Mark was using IDL
to ensure that Fresco interfaces were as "pure" as possible (an
approach with which I agree strongly -- IONA's Adaptive Runtime
Technology (ART) takes the same approach). In a local-only
environment, the overhead of reference counting was indeed too much,
as our tests proved.

You could argue that putting requirements for non-distributed systems
on the C++ mapping was inappropriate, given that CORBA is expected to
be used far more often in distributed environments than in local ones,
but the relatively recent addition of the "local" IDL keyword
(finally!) is proof that there is and always has been demand for such
support.

In the whole scheme of things, this whole thread is ridiculous. You're
greatly exaggerating problems with CORBA, to a level that I personally
consider irresponsible, only to call attention to your new software.
Someone new to CORBA reading your postings would think that the
world's best CORBA expert would have a better chance of winning a
lottery than getting a CORBA application working!

There is no such thing as a perfect standard. As standards go, CORBA
has been wildly successful despite its relatively minor technical
problems (which, again, you have *greatly* exaggerated), and it
remains wildly successful. There are new CORBA projects kicking off
every day. The topics of many of the papers presented in distributed
technology conferences such as DOA and Middleware are based on CORBA,
which means that much research is based on CORBA, which in turn means
that CORBA will be around for years to come. Some have claimed the
CORBA market is declining, but nobody, not even the analysts, actually
has the numbers to back that up, and surely such numbers would have to
somehow take into account the strong proliferation of open source
CORBA systems. My own opinion, based on visits to existing customers
and prospective new customers, is that the CORBA market remains
vibrant and strong.

Michi Henning

unread,

Jul 23, 2003, 8:01:07 PM7/23/03

"Steve Vinoski" <vin...@ieee.org> wrote in message
news:6c2690b5.03072...@posting.google.com...
> "Michi Henning" <mi...@triodia.com> wrote in message

news:<xSwTa.10402$OM3....@news-server.bigpond.net.au>...

> >
> > Hmmm... I'm having problems with this (as I mentioned to you about two
years
> > ago).
> > Here is my reasoning:
> [snip]
>
> A crucial aspect that you're missing from your reasoning is that one
> of the original applications for the C++ mapping was going to be a
> non-distributed system. I'm talking about Fresco, an X Windows System
> toolkit/framework that Mark Linton was working on. Mark was using IDL
> to ensure that Fresco interfaces were as "pure" as possible (an
> approach with which I agree strongly -- IONA's Adaptive Runtime
> Technology (ART) takes the same approach). In a local-only
> environment, the overhead of reference counting was indeed too much,
> as our tests proved.
>
> You could argue that putting requirements for non-distributed systems
> on the C++ mapping was inappropriate, given that CORBA is expected to
> be used far more often in distributed environments than in local ones,
> but the relatively recent addition of the "local" IDL keyword
> (finally!) is proof that there is and always has been demand for such
> support.

Hmmm... The question is whether this isn't using the 5% case
to justify the clumsy API that the 95% case suffers from as a result. To
me, it seems the wrong trade-off to force the majority of developers into
the memory-management problems that are inherent in the mapping
just because of local interfaces. It probably would have been better
to have a separate style of API specifically for local interfaces and
to cater to the more common (non-local) case. The separate API
could be triggered by IDL annotations, a configuration file, compiler
switches, or similar.

I agree that there are situations where there is demand for collocated
calls. The CORBA run time itself has such a need, as is demonstrated
by the various attempts at this in the CORBA spec over the years
(PIDL, locality-constrained objects, local interfaces). As far as I know
though, there is still no standard C++ mapping for how to implement
local interfaces, so I guess local interfaces don't help developers yet.

> In the whole scheme of things, this whole thread is ridiculous. You're
> greatly exaggerating problems with CORBA, to a level that I personally
> consider irresponsible, only to call attention to your new software.
> Someone new to CORBA reading your postings would think that the
> world's best CORBA expert would have a better chance of winning a
> lottery than getting a CORBA application working!

No, it's not quite as bad as that :-) I do manage to write the odd CORBA
application that actually works :-) I just find myself having to work
far harder doing it than necessary.

> There is no such thing as a perfect standard. As standards go, CORBA
> has been wildly successful despite its relatively minor technical
> problems (which, again, you have *greatly* exaggerated), and it
> remains wildly successful.

Well, I have listed quite a lot examples of poor design, unnecessary
complexity, etc. This isn't just about the C++ mapping. It's about the
botched naming service, the botched protocol, the overly complex
POA API, the lack of threading semantics, the non-scalability of
the event service, the lack of a UDP transport, the lack of interface
aggregation, the fantasy specifications that are published, and so on.
Of course, I can design and engineer around all of these, and lots
of existing CORBA applications are proof of that.
But I shouldn't have to.

I vividly remember telling my students during my courses things such
as "don't do that, it will hurt you", and "keep away from this, it's poorly
designed", and "sorry, I don't know why this is so clumsy, I didn't write
that part of the spec." And our book has lots of advice along similar
lines. Every time such a wrinkle rears its head, using CORBA gets
a little bit harder. Any one of these things taken in isolation doesn't look
that bad. But when I put them all together, the picture that emerges isn't
all that pretty.

> There are new CORBA projects kicking off
> every day. The topics of many of the papers presented in distributed
> technology conferences such as DOA and Middleware are based on CORBA,
> which means that much research is based on CORBA, which in turn means
> that CORBA will be around for years to come.

Absolutely, I have no doubt of that. Lots of technologies hang
around for a long time, for a variety of good and pragmatic reasons.
That doesn't mean that they are the only technologies, that they are suitable
for
everything, that there mightn't be better alternatives available in some cases,
or that they should be used forever. (I used to typeset all my documents
using troff. It was a fine program in its day because, without it, I
couldn't have typeset anything at all. Once Framemaker became
available, I used that because it was so much quicker and simpler.

Steve Vinoski

unread,

Jul 23, 2003, 10:55:33 PM7/23/03

This is a really long posting, but I've preserved it all, and have
added my follow-up at the very bottom. Once you read my follow-up,
you'll know why I preserved everything. Sorry in advance for the
length of this message.

Michi Henning <mi...@triodia.com> wrote in message news:<Pine.LNX.4.44.030721...@diadora.client.uq.net.au>...
> On 20 Jul 2003, Douglas C. Schmidt wrote:
>
> > Michi Henning wrote:
>
> > >> Having written large sections of the CORBA specification myself, I
> > >> am aware of that. I am also aware of the impossibility to rectify
> > >> even minor flaws in CORBA, let alone the major ones (and, believe
> > >> me, I have tried).
> >
> > There's no question (in my mind) that the CORBA specification and
> > revision process has flaws. Things do seem to get fixed, however,
> > albeit not at the rate I'd like to see.

> still a lot of things unspecified about constant expression evaluation,
> such as overflow and coercion semantics, as well as the meaning of the
> bitwise operators.
>
> Other examples:
>
> - potential deadlock with POA::deactivate_object() (opened
> 28 June, 1999, still open)
>
> - Custom marshling for value types makes it impossible for
> bridges to operate correctly (opened December 1999, still
> open)
>
> - Object::get_policy() not implementable for
> portable-interceptor policies (opened 18 November 2000, still
> open)
>
> Need I go on? And we haven't even talked about the built-in defects that
> no-one ever raises as a defect. Examples abound:
>
> - The ridiculous marshaling rules of IIOP, with padding for no
> purpose other than to waste bandwidth.
>
> - The inability to version IIOP properly, due the fact that the
> encoding isn't versioned separately from the protocol state
> machine. As a result, CORBA cannot interoperate even with
> itself. (For example, there is nothing to prevent an Any
> containing a fixed-point value to travel to an ORB that
> doesn't understand that version of IIOP, with no way to
> diagnose the problem other than inexplicable marshaling
> errors.)
>
> - The huge internal complexity of IORs which, with their opaque
> parts, make marshaling expensive and force creation of services
> such as the bootstrap and naming service, who are not needed
> at all with a design that avoids this complexity.
>
> - The fact that there still is nothing like a usable security
> model an implementation of which that I could buy from a vendor
> and then use to securely operate through firewalls.
>
> - The lack of a threading model that would give semantics other
> than "the ORB may choose to create more than one thread, or it
> may not do that".
>
> - The continuing absence of a scalable event service or a UDP
> transport.
>
> - The sillyness of location-forward messages with the
> concomitant inability to migrate implementation repositories
> when one look at the DNS is sufficient to see that there is a
> far better alternative.
>
> - The complexity of the POA specification with its mess of
> policies when, in reality, three or four different
> implementation techniques are all that needs to be supported
> in every application scenario I have ever come across.
>
> - The C++ mapping with it's memory-management and complexity
> problems that is a major source of bugs and simply sucks.
> (Bjarne Stroustrup has called it "awful.")
>
> - The large number of specifications that exist on paper that I
> cannot implement, not buy an implementation for, or not buy an
> implementation for from more than one vendor.

>
> The list could be extended considerably.
>

> > Your statement above reminds
> > me of the classic de-motivational poster
> > <www.cs.wustl.edu/~schmidt/demotivation.html> that says "You'll always
> > miss 100% of the shots you don't take - and statistically speaking 99%
> > of the ones you do!" In other words, if people don't participate in
> > the CORBA process then it's guaranteed that stuff will not get fixed,
> > but even being involved doesn't guarantee success.
>
> Yes. A look at the issue list confirms that.
>
> > >> Unfortunately, the CORBA standard is stuck in a quagmire, I
> > >> believe. There has been little activity in last two years or
> > >> so.
> >
> > I disagree, though we may care about different parts of the OMG CORBA
> > spec. At this point, TAO implements major parts of CORBA 3.0 and
> > we're focusing our attention on the recent Lightweight CCM
> > specification <http://www.omg.org/cgi-bin/doc?realtime/2003-05-05> and
> > the updated Deployment and Configuration spec
> > <http://www.omg.org/cgi-bin/doc?mars/2003-05-08>. As these
> > specifications are adopted and implemented, CCM will be a great
> > approach for DRE systems.
>
> Doug, I haven't been talking about distributed real-time systems, I've
> been talking about general-purpose middleware. They are certainly
> different. And, it really begs the question: why is it that the CCM
> specification was adopted in 1999 and now, in 2003, has to be redone?
> Why is it that, as far as I know, therer is not a single commercial
> implementation of that specification? Why is it that one of the major
> design goals, namely, to allow a third party without access to the ORB
> source to implement CCM, was missed? Why is it that the major design hook
> for this feature (Object::get_component()) was removed from the specification?
>
> Why is it that so many CORBA specifications are not worth the paper they
> are written on and are never implemented? Need I remind you of the Cos
> services debacle? Or the much-heralded multicast specification that is
> still not implemented, to the best of my knowledge? How much credibility
> is there in an organization that continues to publish documents such as
> this (despite my best efforts as an Architecture Board member to inject
> some reality into the process and to prevent these embarrassing incidents)?
>
> > >> Specifications are produced that are never implemented, and bugs in
> > >> the specification take ages to fix, or are never fixed at all. What
> > >> is worse, most specifications are the kitchen sink of every feature
> > >> ever dreamed of by anyone ever; the resulting platform and APIs are
> > >> horrendously complex and take years to get proficient at.
> >
> > I think that's largely FUD Michi - I'm surprised to hear you talk like
> > this - you sound like Don Box or Roger Sessions!
>
> Two things here Doug:
>
> - I don't believe this is FUD. For example, the trader specification is a joke
> in terms of its complexity (and never mind the large number of semantic
> conflicts that can be caused by policies, with no word in the
> specification as how to deal with them). The POA API is well over
> twice as large as it needs to be for its functionality because
> orthogonal concepts were never worked as cleanly as they should
> have been. There are numerous other examples along similar lines. And,
> small wonder that most OMG specs are the kitchen sink of complexity:
> the only way to get agreement is to accommodate the wishes of just
> about every vendor present...
>
> - I believe that there are very few people in the world who can
> claim to have worked harder or longer than myself on developing CORBA,
> specifying CORBA, teaching CORBA, promoting CORBA, fixing CORBA,
> or implementing CORBA. To put me on a level here with Roger Sessions,
> (who had a very personal axe to grind with the OMG) is both
> inappropriate and in bad taste, IMO.
>
> > At UC Irvine, Wash
> > U., and Vanderbilt U where I've taught, we regularly teach ugrads and
> > grads how to program CORBA with C++ in about 6-8 weeks (using your
> > book ;-)). Sure, there are some dark corners of CORBA and C++, but it
> > certainly doesn't take *years* to become proficient!
>
> Well, I have taught CORBA to well over a thousand engineers over the
> years, many of whom were highly-experienced professionals with many
> years of software development experience. They didn't think it was easy --
> they settled on CORBA simply because it was the best thing going for the
> job. After nearly a decade of having lived and breathed CORBA, I really
> have to look things up in my own book when I write CORBA code. Yes, really.
> I simply can't remember the incoherent and complex mess of APIs, memory
> management rules, inconsistent naming conventions, and needless
> verbosity.
>
> And, forgive me, no matter how good a course you teach or how
> good a book Steve and I might have written, no-one learns CORBA in 6-8
> weeks to the point where they can create industrial-strength
> applications. Distributed computing in general, and CORBA in particular,
> are far too complex for that.

>
> > There's no question that CORBA could be simpler - especially given the
> > benefit of hindsight (and the lack of SOM compatibility in the early
> > days ;-)). However, it's also clear that UNIX, C, C++, C#, Perl,
> > Windows, X-Windows, MFC, ACE, SOAP, COM/DCOM, .NET, Java, J2EE,
> > Real-time Java, etc. all have accidental complexities and warts that
> > leave something to be desired. While it would be nice to throw them
> > all out and start from scratch, that's not always possible/sensible.
>
> Well, we think that is possible and sensible. By that argument, we would
> have to live with every wart and bad design ever invented by anyone, and
> we are certainly not doing that. (How many DOS programs get written
> these days? Or how many DCE programs, for that matter? And DCE
> proponents had much the same things to say about CORBA when it was
> new...)
>

> > Perhaps as a result of spending time with Bill Beckwith (OIS) and Sam
> > Aslam-Mir (PrismTech) last week has corrupted my mind irreparably, but
> > it seems to me that their ORBs (ORBexpress and e*ORB, respectively)
> > are REMARKABLY fast and small. In fact, it would amaze me if ICE were
> > as fast and small as either ORBexpress or e*ORB for DRE systems. I
> > recommend you contact Gautam Thaker <gth...@atl.lmco.com> and get him
> > to add comparisons of ICE and e*ORB to his "Middleware Comparator
> > page" at
> >
> > http://www.atl.external.lmco.com/projects/QoS/compare/dist_oo_compare2.html
> >
> > (ORBexpress is already there). This would go a long way to help
> > substantiate/debunk your claims above.
>
> Doug, please! Comparing a dedicated real-time ORB with a general-purpose
> ORB or middleware platform such as Ice is inappropriate, and you know
> that. Last time I looked, e-ORB was certainly very fast (and it appears
> to be a fine product for its market), but it only provided a small
> subset of the CORBA spec, and certainly wasn't standard compliant.
>
> BTW, Gautam has already done some benchmarks on Ice and, for what it's
> worth, Ice appears to be remarkably fast. (See
> http://www.zeroc.com/vbulletin/showthread.php?s=74b49746368e034316f1d319b163289b&threadid=27 for details.)

>
> > >> (Again, as an ORB implementer of many years, I speak from
> > >> experience.)
> >

> > Not to take anything away from your experience Michi, but the folks
> > who are implementing the cutting edge Real-time and Embedded CORBA
> > ORBs have done some AMAZING things. As usual, however, the proof is
> > in the benchmarks, so let's see if we can get Gautam and his team to
> > settle this issue for us empirically and objectively.
>
> Well, if you insist on comparing apples and oranges, of course.
> ORBacus/E also is faster than Ice. But ORBacus/E is a dedicated
> embedded effort and not fully compliant with the CORBA spec. And
> ORBacus/E is unsuitable as a general-purpose middleware, just as many,
> if not all, of the embedded and real-time ORBs are.
>
> > >> Then add the ongoing vendor attrition into the picture, plus the
> > >> OMG's changed focus on MDA instead of getting its middleware fixed,
> > >> and the picture isn't all that pleasant.
> >
> > Actually, the current situation for CORBA ORBs in the DRE domain is
> > looking quite pleasant.
>
> You keep talking about real-time and embedded ORBs, not general-purpose
> ORBs. Where are all the general-purpose ORBs? Where is BEA's ORB these
> days? Or IBM's? Or Expersoft's? Or Rogue Wave's? How much vendor choice
> do I have left when I'm looking for CORBA these days?
>
> > There are a number of very healthy ORB
> > vendors (OIS, OCI, PrismTech) whose products (ORBexpress, TAO, e*ORB,
> > and JacORB) work well and interoperate nicely. Since several of these
> > ORBs are open-source (TAO and JacORB), there are also very large and
> > active communities involved in improving many aspects of these ORBs
> > around the clock and around the world. Check out
> >
> > http://www.cs.wustl.edu/~cdgill/TAO03/
> >
> > and
> >
> > http://www.dre.vanderbilt.edu/scoreboard/
> >
> > for some examples of these active communities in just the TAO
> > community alone.
>
> Completely agree. In fact, the Open Source communities have definitely
> done a lot for CORBA (much more than the commercial vendors, IMO). But I
> also believe that, as long as these ORBs adhere to an aging and clumsy
> specification, they will never come anywhere near their full potential.

>
> CORBA was a great thing in its day. But the specification process is too
> inflexible, and fundamental design problems (such as the inability to
> version IIOP properly) make it just about impossible to incorporate
> technical improvements into the platform. As a former OMG Architecture
> Board member, I can definitely assure you that topics like fixing IIOP
> make people's hair stand on end, due to the immense technical and
> marketing difficulty of doing so, plus the weight of legacy and backward
> compatibility issues.
>

> > Michi, again with all due respect, you now work for a company that's
> > selling a product that's aiming to compete directly with CORBA, so I'm
> > not the LEAST BIT surprised that you'd no longer believe that CORBA is
> > the answer!! For some wry irony, BTW, take a look at the arguments
> > that you had with Roger Sessions when he had a similar "conversion" in
> > the mid-90s ;-).
>
> Doug, see above -- I believe that comparison with Roger is singularly
> inappropriate here. I have spent many years doing CORBA, and I am generally
> recognized as one of the world's experts on the topic. And I am sick of
> doing things the hard way when they can be so much easier. I am not
> trying to throw mud at CORBA. (I personally invested far too much of
> myself in CORBA for that). But I want to point out that some of the arguments
> for CORBA should be examined more closely: by and large, the benefits of
> standardization of CORBA have not been realized. Vendors insist on
> adding their own extensions (often incompatible with the specification),
> much of what is needed is underspecified, and the much-touted freedom of
> choosing a vendor largely does not exist: even with 100% CORBA
> compliance, another vendor may not support the platform I need, may not
> provide the language mapping I need, may not support the compiler I
> need, or may not implement the particular part of the CORBA spec I need.
> Realistically, there is little choice of vendor in many situations (not
> all situations, I freely admit).

>
> > >> Ice is similar to CORBA in many ways: it gives you language and
> > >> platform neutral OO RPC, just like CORBA. It provides all of the
> > >> features of CORBA (but does it in ways that are much simpler and
> > >> more efficient),
> >

> > Let's wait and see what Gautam's experiments show before accepting
> > that ICE is "much more efficient" than the state-of-the-art DRE ORBs!
>
> Doug, of course Ice is not as efficient as a real-time ORB! Why do you
> keep comparing a general-purpose platform with a general-purpose one?
> We believe that Ice is faster than any general-purpose ORB. And it
> provides that performance with APIs that are a fraction of CORBA's
> in complexity, and with a smaller footprint. And, to boot, it provides
> features that neither general-purpose nor DRE CORBA implementations can
> provide: a persistence service that is incredibly easy to use,
> asynchronous method dispatch, an efficient protocol that doesn't waste
> bandwidth, compression on the wire, security, etc. (Where is CORBA's security?
> Please don't tell me about the firewall spec which, apart from the
> complexity of administering all this machinery, requires every firwall
> vendor in the world to make extensive changes to their product -- how
> realistic is that?)
>
> > I'm not going to argue with you that CORBA couldn't be better.
> > However, if the history of the past 40+ years tells us anything, it's
> > that technologies rarely succeed because they are "cleaner" than their
> > alternatives. If you consider the list I gave above, you'll find that
> > there are lots of cleaner alternatives (particular for C and UNIX)
> > that never caught on because users were looking for other properties,
> > such as portability, interoperability, availability, longevity,
> > legacy, etc.
>
> Right. Technical excellence alone is (unfortunately) rarely enough. Yet,
> it does matter. If it didn't, we'd all still be using DCE or raw
> sockets, and CORBA would never have happened either.
>
> > >> You are right, Ice doesn't have a standards base like CORBA
> > >> does. But, on the other hand, how much has the CORBA
> > >> standardization really achieved for people?
> >
> > Sigh... You *have* been possessed by the ghost of Don and Roger,
> > haven't you? ;-)
>
> I don't think this answers my question. Again, how much has the CORBA
> standardization really achieved for people? Not a lot, IMO.
>
> > >> I have been involved with several projects that decided to switch
> > >> ORB implementations at some stage during development. In all
> > >> cases, the experience wasn't pretty:
> >
> > Perhaps that's because people were switching from older versions of
> > Orbix to newer, standards-compliant ORBs?

>
> No, I'm not talking about BOA-to-POA transitions here, I'm talking
> switching from things such as Orbix 2000 to ORBacus, or Visibroker to
> TAO.
>

> > >> - The much-lauded source code compatibility in practice does not
> > >> exist. ORBs are usually full of vendor-specific extensions (often
> > >> not clearly identified as such) that can make it very difficult to
> > >> port existing code to a new ORB.
> >

> > Again, this is simply FUD Michi. If you check out
> >
> > http://www.cs.wustl.edu/~cdgill/TAO03/
> >
> > and
> >
> > http://www.omg.org/news/meetings/realtime2003/Program.pdf
>
> No, that's not FUD, that is first-hand experience I have gathered over the
> years. The amount of effort to simply change a Clearcase-based
> development environment alone to a different ORB is staggering. And we
> haven't talked about the need to use different tools to administer the
> whole thing, the changes in testing procedures, the changes in
> deployment of services, etc. This things impose a considerable cost.
>
> > you'll see there were talks by Raytheon, BAE Systems, Boeing, and
> > Lockheed Martin last week describing their experiences developing and
> > porting MAJOR (i.e., million lines of C++ and CORBA code)
> > mission-critical DoD combat systems and radio systems using multiple
> > ORBs. The basic consensus was that as long as you stick with "good"
> > ORBs (i.e., the ones I mentioned earlier that are compliant with the
> > CORBA spec) and use available tools (such as CORBA auto-conf
> > <http://corbaconf.kiev.ua>) the porting process is straightforward.
>
> Doable? Yes. Straightforward? In some cases. Cheap? Never.
>
> > In fact, in talking with the speakers mentioned above, they said they
> > are regularly develoing their systems with both ORBexpress and TAO in
> > order to ensure they are remaining compliant with the standard APIs.
>
> Well, if they really were compliant, I wouldn't have to develop for two
> ORBs in parallel, just to be sure, would I?
>
> > The bottom line is that it's really no harder to develop portable
> > CORBA applications now than it is to develop portable UNIX and Windows
> > applications.
>
> Right. And that is far too hard. It shouldn't be that hard, and it need
> not be, as Ice demonstrates.
>
> > Ironically, the open-source community has contributed a
> > considerable amount to simplifying the portability and
> > interoperability of both operating systems and ORBs.
>
> I think we both agree that without the open-source community, this
> industry would be in an even bigger mess than it is actually in!
> It is sad though to see so much creativity and energy being spent on
> something with so many deep-seated problems.
>
> > >> - The specification is insufficiently tight to guarantee source
> > >> code compatibility, even if you are strictly sticking to code that
> > >> is based on the standard: for example, header file names are not
> > >> standardized, there is no threading API or even a usable behavior
> > >> model for threads, the files that are produced by an IDL compiler
> > >> are unspecified in number and name, etc, etc.
> >
> > Give me a break Michi. This is NO different than for UNIX, Windows,
> > and real-time embedded operating systems, which are MUCH more diverse
> > than today's leading CORBA ORBs.
>
> Excuse me? Does this make it right or acceptable? Just because it's as
> bad as other things, I have to put up with that? That doesn't make sense
> to me.
>

> > As usual, there are a
> > straightforward set of patterns and tools to apply to make this work
> > fine in practice (not unlike what we've done with ACE, which makes
> > cross-platform C++ concurrent network programming straightforward).
> > Again, the CORBA auto-conf tool <http://corbaconf.kiev.ua> makes life
> > much easier.
>
> We don't seem to have spoken to the same people, or seem to have
> interpreted their messages differently. As far as I am concerned, if I
> need an auto-conf tool to write code for more than one middleware

> platform, there is something wrong with the middleware. Installing and
> using the tool doesn't come at zero cost, and I shouldn't need such a
> tool in the first place.
>
> > >> - Large and important parts of what you need to specify CORBA are
> > >> not standardized at all: implementation repositories, configuration
> > >> of all the services, build environment, administration, etc.
> >
> > The CORBA Component Model is addressing some of these issues - and
> > there are an increasing number of CCM implementations coming online
> > (check out Diego's http://www.ditec.um.es/~dsevilla/ccm/ page for more
> > details). Moreover, it's not really clear what your point is here
> > since ICE's solutions for all of these capabilities are even less
> > standardized than CORBA! Moreover, ICE will need to provide many
> > other non-standard services (e.g., transitions, fault tolerance,
> > real-time, load balancing, component models, etc.) to compete with the
> > more advanced CORBA, J2EE, and .NET offerings, so it sounds like
> > you're largely reinventing the wheel and causing MORE interoperability
> > and portability problems for the developer and user community!
>
> Hmmm... How many CORBA vendors offer a product that provides even half of
> all these things? Last time I looked, there wasn't a single
> commercial vendor that would provide CCM, load balancing, transactions,
> and fault tolerance. (Pick any two, and you just might be lucky.)
> Just because there is a CORBA specification for something, that doesn't
> mean that it exists, that I can buy it, or that I can buy from the
> vendor I need to buy it from and for the platform I need it to run on.
>
> Ice does what CORBA does, but better. For many people, that alone is
> sufficient reason to use it. Whether CORBA is more advanced is something
> that is open to debate, IMO. It really depends on which angle I look at
> it from. The Ice core leaves the CORBA core behind in terms of usability
> and functionality, IMO. If I look at the transaction service (oops, how
> many vendors can I buy an implementation of that from?), or the sheer
> weight of the numerous other specifications, certainly, Ice looses. As
> far as saying that we are causing yet more interoperability and
> portability problems is concerned, I don't think that makes sense. By
> that argument, anyone who innovates anything can be accused of the same.
>
> > Given that the distributed computing middleware market is incredibly
> > crowded, with lots of very good products (many of which are freely
> > available and commercially supported) it's not really clear what the
> > value-added is for a proprietary middleware product like ICE that's
> > not going to have a major 800 pound gorilla company or standards group
> > to "adopt" and promote it, a la SOAP, J2EE, .NET, CORBA, etc., which
> > means that it's likely to remain a niche technology.
>
> Well, that might happen, we'll just have to wait and see. Personally, I
> am much happier to work on something that is slick and elegant, instead
> of cumbersome and clumsy. And, currently, I would call SOAP, J2EE, .NET, and
> CORBA niche technologies too: none of them is ubiquitous. If we have
> room for four RPC platforms, surely there must be room for a fifth?
>
> > >> The net effect of all this is that there are hundreds of things
> > >> that are not addressed in the specification, but that need to be
> > >> taken care of when changing ORBs.
> >
> > I'm not sure if the number is "dozens" or "hundreds," but in either
> > case based on the experiences of the groups at last week's meetings
> > this problem appears straightforward to solve in practice - especially
> > once you're using "modern" ORBs.
>
> That I really would call a fallacy. The lack of a threading model in
> CORBA is definitely not straightforward to solve in practice, otherwise
> it would have been solved years ago. Neither is a solution to the
> dreadful C++ mapping straightforward because, years ago, when I
> suggested to do something about this, I realized that there was *no
> chance whatsoever* to get that job done. Fixing IIOP? Forget it. Or the
> mess of character set negotiation that still doesn't work among many
> ORBs? A single vendor has consistently blocked any and all moves in the
> OMG to throw out this mess and use Unicode instead. As a result,
> cusomers are still burdened with this when a perfectly
> reasonable and proven technical solution is readily available.
>
> None of these problems are "straightforward" to solve. In fact, many of
> them are impossible to solve, due to the political nature of the OMG,
> the legacy problem, and the drag of backward compatibility and vendor
> apathy.
>
> > >> In practice, people have to re-engineer the build environment,
> > >> administrative tools, and testing tools, not to mention the various
> > >> bits of source code. Given all this, standardization has added
> > >> comparatively little.
> >
> > I disagree - and the examples cited above provide evidence of the
> > value of standards.
>
> I think we just will have to disagree then. Most certainly, my
> experiences have been nowhere near as rosy.
>
> > >> In fact, I would argue that the burden the standard has imposed on
> > >> the platform in terms of poor run-time performance, footprint, and
> > >> complexity may well overwhelm any of the benefits:
> >
> > Again, let's see the actual numbers that Gautam's team can produce
> > before you declare victory ;-). BTW, I'm more than willing to
> > publically "eat crow" on this if the numbers bear it out!
>
> Well, as I said above, some numbers are in. Ice certainly stacks up
> quite well.
>
> > >> in practice, once you develop with an ORB from a specific vendor,
> > >> it is very difficult (and very expensive) to get away from that
> > >> vendor.
> >
> > Perhaps if you're (1) using Orbix 3.x or earlier or (2) go out of your
> > way to program to ORB-specific details. But this is now largely a
> > failure of process, not technology. The tools, patterns, and
> > techniques for writing portable/interoperable CORBA apps are widely
> > available (and increasingly used in practice) - so there's no (good)
> > excuse for not being vendor-independent these days.
>
> Actually, I think there are several good excuses:
>
> - Developer ignorance. It is not reasonable to expect developers
> to be conversant with the spec to the degree required to steer
> away from non-portable or vendor-specific constructs.
>
> - Overhead. Why should I have to worry about all these extra
> layers of patterns, tools, and techniques just to get portable
> code? Why can't the API be portable, period? (And Doug,
> really, if CORBA is so portable, what exactly is it that all
> these patterns, tools, and techniques are achieving?)
>
> - Cost. All the extra patterns, tools, and techniques have a
> cost, both financial, and in terms of complexity, footprint,
> and performance.
>
> > >> That then begs the question of where the benefits of
> > >> standardization are to be found.
> >
> > Fortunately, this (begged) question is now largely moot, as per the
> > discussion above ;-)

>
> Well, I don't think it is. The dream of interoperable and portable
> software has by and large not been realized by CORBA. Maybe that isn't
> CORBA's fault -- maybe the dream is unrealistic. I just spoke to a large

> company who was forced by the demise of a commercial CORBA vendor to
> switch ORBs. The story they told was very painful, and they were greatly
> disillusioned by the way their investment in standardized technology had
> failed to pay off. The cost was large for that company, both financially
> and in terms of development effort, defects, and down time. Doug, these
> people would laugh in your face if you told them that the issue is moot!

> > A good analogy in the OS world would be
> > something like the Be OS, OS/2, or NextSTEP, which were cool
> > technologies that were much cleaner than their competition (i.e.,
> > Windows ;-)), but which didn't catch on in the mainstream market.
> > Ultimately the mass market of technology users don't select their
> > tools and platforms because they are "cool" but because they address
> > other key functional and non-functional forces. I guess Richard
> > Gabriel really was right in his infamous "Worse is Better" screed...
>
> Yes, I read that too -- most excellent essay. But, as I said, we are not
> interested in world domination. Just making a living is quite sufficient :-)
>
> > To wrap up this round of the debate (since I know Michi won't let me
> > get the last word yet ;-)) let me close with the following. I respect
> > the work that you ICE folks have done. I think you guys are REALLY
> > smart, do GREAT work, and I'd like to see you SUCCEED. It bugs me,
> > however, when you start spewing FUD about CORBA that simply doesn't
> > hold up under closer inspection. Assuming ICE is as good as you say
> > it is, you should be able to sell it on its merits, rather than
> > resorting to Box/Sessions tactics.
>
> Again, these aren't Box/Session tactics. The concerns I raised are real
> in my opinion, are technically well founded, and are not FUD. They are
> born of many years of very intensive work on CORBA, and many years of
> consulting to customers. If I wanted to spread FUD, I'd write an article
> for one of the trade rags instead of posting here. Ice offers an
> alternative to CORBA that may be suitable for many people because
> it is well possible that the arguments in support of CORBA don't stand
> up under closer examination. In such cases, Ice is definitely worth a
> look.
>
> And no, I of course wasn't going to let you have the last word ;-)
>
> How about we talk about this at JAOO? Steve Vinoski, Doug Lea, Bjarne
> Stroustrup, and Jim Coplien will all be there too. Should make for a
> lively evening over a few beers :-)

Michi, you've stated some very negative things about CORBA above and
elsewhere in this thread. However, given the following quotes from
you, which turned up in a simple search through comp.object.corba from
the past few years, how do you explain your sudden about-face?

06/27/2002:

"Right now, CORBA *is* the future of middleware. I'm not aware of any
other middleware that would come even close in portability, platform
support, features, performance, or multi-vendor support. It will be a
minimum of six or seven years before any other middleware platform
will be able to match that."

08/28/2001:

"Well, I find it difficult to see how CORBA can be dead. What is more
likely happening is that CORBA well and truly has reached the stage
where it is mature and works. Unfortunately, there is a strong
tendency in this industry to discard anything that works and instead
go off to chase something that might work in three years' time.

CORBA is still the most feature-rich and mature distribution
technology in existence. It's fast, reliable, runs on everything on
the planet, supports all major programming languages, is available
from a large number of vendors, is based on an open standard, and is
growing by leaps and bounds."

02/17/2000:

"CORBA is simple at the core, but there are lots of details to worry
about. That's not the fault of CORBA, but the fault of distributed
systems. They are, by nature, more complex than non-distributed ones."

09/27/2000:

"The upshot is that, to the best of my knowledge, there simply isn't
anything that comes anywhere near CORBA's flexibility, range of
functionality, convenience, platform support, etc. Further, as far as
I can see, there is nothing on the horizon that could take CORBA's
place. It seems that CORBA's success is assured for many years to
come. And, most certainly, the CORBA user base is growing, not
shrinking"

07/19/1999:

"I agree that CORBA has shortcomings. Anything of that degree of
complexity will have shortcomings, that's inevitable. But, on the
upside, pretty much anyone can contribute toward improving the
situation...And, while CORBA has shortcomings, let's not forget that
there is a much longer list of things it does extremely well. It's no
accident that CORBA is as popular as it is..."

11/09/1999:

"If you want multi-platform or multi-language distributed computing,
CORBA is pretty much the only viable choice in existence."

Which Michi are we to believe?

Michi Henning

unread,

Jul 23, 2003, 11:57:26 PM7/23/03

On 23 Jul 2003, Steve Vinoski wrote:

> This is a really long posting, but I've preserved it all, and have
> added my follow-up at the very bottom. Once you read my follow-up,
> you'll know why I preserved everything. Sorry in advance for the
> length of this message.

Oh boy, was it really necessary to quote all that to make the point that
I said differently in the past? I would have thought that I'm thoroughly
on record for that, given around 7,500 postings to comp.object.corba
over the past few years, plus a book on CORBA.

We've built something that's better and simpler than CORBA, so I've
changed my mind. Simple :-)

I think we've taken this thread as far as it will go without having
it completely degenerate into quoting and counter-quoting -- we
are getting very close to what would have to be considered a flame war,
which generally has no place in a newsgroup. And I think we have each
thoroughly established our respective opinions :-)

So, why don't we bring it back to a technical level? I'm really interested
in talking about the relative merits and trade-offs of the two technologies.
(Some of the marshaling considerations that came up earlier were
interesting, for example.) Other readers might get something out of that
too.

Christopher Browne

unread,

Jul 24, 2003, 12:54:56 AM7/24/03

In the last exciting episode, Michi Henning <mi...@triodia.com> wrote:
> So, why don't we bring it back to a technical level? I'm really interested
> in talking about the relative merits and trade-offs of the two technologies.
> (Some of the marshaling considerations that came up earlier were
> interesting, for example.) Other readers might get something out of that
> too.

That is indeed an interesting part of it.

Your presentation turns on its ear many of the traditional performance
assumptions surrounding marshalling, which was most interesting.

If there were implementations out there for other languages (Perl?
Python? Lisp?), I'd be more interested; as it stands, CORBA still
supports a boatload more languages and environments.
--
"cbbrowne","@","ntlug.org"
http://cbbrowne.com/info/sgml.html
"Politics is not a bad profession. If you succeed there are many
rewards, if you disgrace yourself you can always write a book."
-- Ronald Reagan

Michi Henning

unread,

Jul 24, 2003, 1:14:53 AM7/24/03

On 24 Jul 2003, Christopher Browne wrote:

> If there were implementations out there for other languages (Perl?
> Python? Lisp?), I'd be more interested; as it stands, CORBA still
> supports a boatload more languages and environments.

Yep, definitely. But we'll get there eventually. We are currently working
on a PHP mapping, which will be nice for web-related work.

Vlad has been working independently on a Python mapping (see
http://www.zeroc.com/vbulletin/showthread.php?s=&postid=623#post623).
I haven't had a look at that in detail yet, but it at least shows that
it can be done (and can be done by third party). The advantages of
making the source code available show themselves yet again :-)

As far as Lisp is concerned, I'm not so sure -- it really all depends on
customer demand. If lots of customers want a Lisp mapping, I don't see
why we couldn't do one.

Bruce Fountain

unread,

Jul 24, 2003, 1:46:38 AM7/24/03

vin...@ieee.org (Steve Vinoski) wrote in message news:<6c2690b5.03072...@posting.google.com>...

This is a very interesting history, but I am not sure it is supporting
your case Steve. Try reading the above quotes in reverse order and you
can see a gradual process of disillusionment. And the quotes which are
most contrary to Michi's current position are four years old, a very
long time in this industry. The most recent quote there is a year old,
where Michi predicts that it will be 6-7 years before a rival emerges
(this *is* a bit odd Michi - surely you guys must have been toying
with this stuff a year ago?).

I don't think Michi is being dishonest or deceptive in his change
of outlook, I think this reflects the realities of this industry,
where a technology that was merely a glimmer in the eyes of some
clever guys last year might be pervasive next year.

I don't write ORBs for a living, I just use them. I have to say
that, much as I love what CORBA can do for me, interoperability
has been more of a comforting guarantee of my code surviving than
actually necessary. In practice I have used CORBA internally to
bind my systems together rather than to interoperate with external
systems. I could as easily have used ICE. And I think I will, first
opportunity I get. The opensource/GPL nature of the product gives
me much the same warm fuzzy that I used to get from knowing I
could change vendors if they go bust or suddenly jack-up the
license fees (as happened on one notable occasion). And I trust
and respect the developers.

I don't think that I am jumping onto the latest bandwagon, or
looking for a new silver bullet. I see this as a genuine
evolution of the best bits of CORBA. I am sure CORBA will be
around for a very long time, but it is clear to me that the
political structure of the OMG is not, and never was, very
agile. I am happy to keep using CORBA if that is what my
employer wants, but I would like the opportunity to tackle
a project with ICE.

Bruce Fountain
brucef
at
eudoramail
dot com

Michi Henning

unread,

Jul 24, 2003, 2:18:54 AM7/24/03

On 23 Jul 2003, Bruce Fountain wrote:

> The most recent quote there is a year old,
> where Michi predicts that it will be 6-7 years before a rival emerges
> (this *is* a bit odd Michi - surely you guys must have been toying
> with this stuff a year ago?).

I think that was at the very tail end of my employment with IONA, before
I decided to take a break.

And thanks for your vote of confidence -- I hope you'll like Ice!

Marcel Ruff

unread,

Jul 24, 2003, 5:08:48 PM7/24/03

Michi Henning wrote:
> Hi,
>
> we've just released a new version of the Ice documentation:
>
> - A new chapter on the server-side run time explains useful
> things such as oneway invocations, datagram invocations,
> and batched invocations (the last two of which CORBA can't do ;-)
>
> There is also quite a bit of material on how to make servers
> scalable using various techniques, such as default servants
> and evictors. (CORBA users should have a look and weep at
> how simple things can be with properly designed APIs...)
>
> - A new chapter on asynchronous method invocation (AMI) and
> asynchronous method dispatch (AMD). AMI works along similar
> lines as the CORBA version; AMD has no equivalent in CORBA:
> it allows you to suspend processing of a method invocation
> in the server to free up a processing thread and to then
> later resume processing of that invocation again. This is
> very nice if you want to build scalable blocking interfaces
> (such as providing a pull model to event consumers) without
> tying up thousands of threads. (The pull model for event consumers
> can't be made to scale with CORBA, unfortunately.)
>
> You can find the documentation at http://www.zeroc.com/download.html.
>
> Enjoy!

>
> Cheers,
>
> Michi.
>
> --
> Michi Henning Ph: +61 4 1118-2700
> ZeroC, Inc. http://www.zeroc.com
>

Nice approach, but i think on massive distributed
systems the 'not generic RPC approach' is not scaling over time
and versions.

I think it is time for more loosly coupled MoM like solutions like
JMS or our xmlBlaster (http://www.xmlBlaster.org).
Thinking asynchronous in such environments is often
a smarter way to go :-)

regards,

Marcel

Steve Vinoski

unread,

Jul 24, 2003, 6:29:04 PM7/24/03

bru...@eudoramail.com (Bruce Fountain) wrote in message news:<cacae9d5.0307...@posting.google.com>...

> This is a very interesting history, but I am not sure it is supporting
> your case Steve. Try reading the above quotes in reverse order and you
> can see a gradual process of disillusionment.

I think my point is that the reversal is not at all gradual. Don't
forget that I know Michi pretty well. Michi was a top user of an ORB I
helped build while at a previous employer, and of course there's the
book we co-authored.

As the quotes show, for the past N years and right up to the recent
past, Michi basically believed that CORBA was the greatest distributed
systems technology ever made, but almost overnight, it's suddenly
become the worst. Therefore, I believe Michi is being disingenuous in
trying to argue the superiority of his new software on technical
grounds -- IMO, as I've stated before, it's all just a facade to sell
more of his new software. I just wish he could admit that, given that
it's as plain as the nose on his face.

I am not trying to incite a flame war. Rather, I just don't feel that
there is a need for anyone in Michi's position, that of an established
expert, to greatly and irresponsibly exaggerate CORBA's technical
problems just to try to make their new software, in this case Ice,
look better. How good can Ice really be if the only way to make it
seem superior to CORBA is to unfairly trash CORBA?

Previously in this newsgroup (comp.object.corba), readers objected to
vendors posting what were essentially advertisements for their
products, so we vendors took to explicitly marking such postings as
being "vendor specific" or "vendor advertisement." I believe Michi's
Ice postings should also be marked as such, given that they're really
just infomercials with some technical jargon thrown in.

--steve

Michi Henning

unread,

Jul 24, 2003, 8:22:35 PM7/24/03

"Steve Vinoski" <vin...@ieee.org> wrote in message

news:6c2690b5.0307...@posting.google.com...

>
> I think my point is that the reversal is not at all gradual. Don't
> forget that I know Michi pretty well. Michi was a top user of an ORB I
> helped build while at a previous employer, and of course there's the
> book we co-authored.

I think we have pretty well established that I have been a proponent
of CORBA for a long time :-)

> As the quotes show, for the past N years and right up to the recent
> past, Michi basically believed that CORBA was the greatest distributed
> systems technology ever made, but almost overnight, it's suddenly
> become the worst.

Not quite overnight, actually. The many flaws and inconsistencies of
CORBA have been bugging me for a long time. If you dig through the
archives, you can find numerous criticisms that I have expressed in the
past. It's simply that I gradually got more and more disenchanted with
CORBA, in particular with the impossibility of rectifying its problems.

Jon Biggar once called me "one of CORBA's most visible promoters
and simultaneously one of it's most fearsome technical critics."
I guess that pretty much sums it up: CORBA was the best thing going
for a long time, but I've never been blind to its faults.

And, by the way, CORBA certainly isn't the worst middleware
platform. I think that web services and SOAP are in a better
position to claim that particular trophy :-)

> Therefore, I believe Michi is being disingenuous in
> trying to argue the superiority of his new software on technical
> grounds -- IMO, as I've stated before, it's all just a facade to sell
> more of his new software. I just wish he could admit that, given that
> it's as plain as the nose on his face.

Well, *of course* we want to sell our software -- it's a product,
and people build products to sell them. The business model is
unusual though. For example, people can use Ice free of charge
under the GPL: as long as they make their source code available
and don't charge anything for their software, Ice is free. That helps
people in the open-source and academic communities. If people
want to use Ice to build commercial software for which they want
to keep the source secret, they have to pay us a license fee. But,
even then, the fee is due only as they earn revenue themselves,
instead of up-front. That removes a significant obstacle for many
projects because they don't have to foot the bill for their middleware
in advance, so their cash flow improves and, if the project is a
commercial failure, they don't lose the money they otherwise
would have spent on up-front middleware license fees. In addition,
the fee for Ice isn't fixed. Instead, it's a percentage of revenue. So
we make money only if our customers make money. I think that's
an honest and fair deal.

> I am not trying to incite a flame war. Rather, I just don't feel that
> there is a need for anyone in Michi's position, that of an established
> expert, to greatly and irresponsibly exaggerate CORBA's technical
> problems just to try to make their new software, in this case Ice,
> look better. How good can Ice really be if the only way to make it
> seem superior to CORBA is to unfairly trash CORBA?

Hmmm... We didn't build Ice just for our personal amusement. Building
something such as Ice requires a lot of money, effort, and time. If
Ice were no better than CORBA, why would we have bothered building
it? To do so would be naive in the extreme. Instead, we could have
built another ORB (which we have demonstrated in the past we know
how to do).

For Ice to succeed commercially, it has to offer something that is
significantly better than CORBA, otherwise no-one will bother
using it. In nearly ten years with CORBA, I learned a lot about
middleware, as did my collegues at ZeroC. What are we supposed
to do with what we have learned? Ignore it and toe the CORBA line
for the rest of our lives? (And it's not as if we haven't tried to improve
CORBA but, every time we did, we ran into insurmountable obstacles
in the OMG and with other CORBA vendors.) Instead, looking at
everything we learned, we decided that Ice would be sufficiently
better than CORBA to have a chance in the market. Time will
tell whether we were right. (On technical grounds, I have no doubt
at all -- I believe that Ice is simply a better middleware platform.
But, as other people have pointed out in this thread, it takes not just
technical excellence to succeed commercially.)

As far as exaggerating CORBA's technical problems is concerned,
I have listed quite a few problems in this thread. The problems are
real and won't go away by pretending they aren't there. Ice
avoids those problems and, as a result, provides a middleware
alternative that is easier to use and may be suitable for some
projects. We are not naive enough to suggest that people should
throw away their investment in CORBA. (And, for companies
with an existing large investment in CORBA, Ice is quite possibly
not a good alternative: throwing another middleware platform
into the mix isn't something that should be done casually.)

Considering how good or bad Ice may be, you have predicted Ice's
demise elsewhere in this thread. Well, if Ice is that bad, we can just
all sit here and wait for it to fail. So why spend all that energy on
telling people how bad it is, or how dishonest I am? Just because
I spent many years working on CORBA, surely that doesn't mean
that I have to keep doing the same thing for the rest of my life? I've
learned something in all my time with CORBA, and I decided to
move on, it's as simple as that.

> Previously in this newsgroup (comp.object.corba), readers objected to
> vendors posting what were essentially advertisements for their
> products, so we vendors took to explicitly marking such postings as
> being "vendor specific" or "vendor advertisement." I believe Michi's
> Ice postings should also be marked as such, given that they're really
> just infomercials with some technical jargon thrown in.

Hmmm... I just recently tried to steer this discussion back to technical
issues, but I don't seem to be succeeding to well :-) I'd love to discuss
specific technical issues, simply because it's interesting, there is
something to be learned from such discussions, and other readers
of this group might find it interesting too. And I'm sure it would
be more interesting to do that than to have you and me carry out
a personal conflict in this group, which isn't what it is for.

Steve, how about we take the personal issues off-line? I think everyone
who is still reading this thread will have got the message by now that
you think that CORBA is better than Ice, and that I have the opposite
opinion :-)

Bruce Fountain

unread,

Jul 25, 2003, 1:25:20 AM7/25/03

vin...@ieee.org (Steve Vinoski) wrote in message news:<6c2690b5.0307...@posting.google.com>...

I don't think he said that CORBA was the worst technology going.
Maybe the second best :-)

For many years Michi has evangelised CORBA. His style hasn't changed,
just the subject. I don't think anyone has any doubt that he has a
vested interest.

Well, the posting was entitled "New Ice documentation available" and
simply said "we've just released a new version of the Ice documentation"
followed by a list of changes. I think that is pretty obviously a
vendor statement, and I don't believe that the thread would have gone
any different if he had prefixed it with "[ADV]".

Best regards,

Bruce Fountain

Gopi Bulusu

unread,

Jul 25, 2003, 4:46:22 AM7/25/03

"Michi Henning" <mi...@triodia.com> wrote in message news:<k2aTa.8550$OM3....@news-server.bigpond.net.au>...
> "Gopi Bulusu" <go...@sankhya.com> wrote in message
> news:2d87f439.03072...@posting.google.com...
> >
> > If you are saying that a C++/CORBA programmer has to look up the spec
> > all the time, then there is a serious problem. I completely agree that
> > many of the C++ mapping rules are "not-intuitive" for C++ programmers
> > who use and understand the ISO specification. One has to note that
> > CORBA's C++ mapping rules predate
> > ISO C++
>
> Well, the CORBA C++ mapping and the ISO C++ specification
> effort proceeded concurrently.

Correct, and that makes CORBA C++ mapping predate ISO C++. Because the
C++ mapping depends on the C++ language and not the other way round.

>
> > and may infact have contributed to the C++ standardization
> > effort (indirectly).
>
> No, fortunately not. If the current mess of the CORBA C++ mapping
> had been able to influence the ISO C++ standard, C++ would be a
> dead language by now :-( Fortunately, the people who worked on

> ISO C++ standardization were, on average, much better at C++
> than the ones who worked on the CORBA C++ mapping.

Almost all major C++ application patterns had their influence on the
C++ standardization effort. CORBA was certainly a major pattern. I did
not participate directly in the standardization body, but I was
building
and maintaining C++ compilers, and one of the big cause of problems
for a language specification and compiler is automatically generated
code (like C++ generated by an IDL compiler). Btw, your interpretation
of influence above
is not what I meant.

> > This does not in any way mean that CORBA is only for complex systems.
> > Even
> > the least experienced C++ developers can very quickly develop simple
> > CORBA
> > applications, if they are using a CORBA product, designed and
> > developed keeping in view the usability of the product.
>
> I cannot support this argument. After many years of CORBA, I know
> that anyone can knock up a simple client server application after a
> few hours, no problem. But I also know that, to build something that is
> robust, scales well, and performs well, a lot of experience is necessary.
> I have seen quite a number of projects that shot themselves in the foot
> something terrible due to lack of that experience. (To some extent, this
> is true for all distributed systems, I believe -- distributed systems aren't
> easy to get right, period. But CORBA does its share to make it even
> harder at times, and unnecessarily so.)

Looks like everything you say above supports my argument :-) CORBA
makes
it easy to build simple systems (as you agree) and makes it easier to
build
more complex systems -- which can't be done at all without an accepted
interoperable standard like CORBA.

Best Regards,
gopi

---

Gopi Kumar Bulusu
Sankhya Technologies Private Limited
http://www.sankhya.com
Tel: +91 891 554 2666
Fax: +91 44 2822 7357

Michi Henning

unread,

Jul 25, 2003, 9:31:27 AM7/25/03

"Gopi Bulusu" <go...@sankhya.com> wrote in message
news:2d87f439.03072...@posting.google.com...
> "Michi Henning" <mi...@triodia.com> wrote in message
news:<k2aTa.8550$OM3....@news-server.bigpond.net.au>...
> >

> > Well, the CORBA C++ mapping and the ISO C++ specification
> > effort proceeded concurrently.
>
> Correct, and that makes CORBA C++ mapping predate ISO C++. Because the
> C++ mapping depends on the C++ language and not the other way round.

Sorry, but I'm confused. So the C++ mapping predates ISO
C++ because the C++ mapping depends on C++? I'm afraid
I don't follow. As far as I know, the C++ mapping didn't have
any influence on ISO C++, and ISO C++ had no influence
on the C++ mapping. Also, the ISO C++ mapping both pre-dates
and post-dates the CORBA C++ mapping: the ISO C++ specification
effort was started before the CORBA C++ mapping, and the final ISO C++
specification was published in 1998, after the CORBA C++ mapping
was published. So, I'm sorry, but I can't see the link -- can you explain?

> Almost all major C++ application patterns had their influence on the
> C++ standardization effort. CORBA was certainly a major pattern.

Hmmm... I don't see anything that particularly patterned in CORBA,
either in the C++ mapping or in CORBA in general. So, I don't
understand how CORBA influenced ISO C++ (other than in the
very general sense of being one of the many areas of computing that
use C++).

> I did
> not participate directly in the standardization body, but I was
> building
> and maintaining C++ compilers, and one of the big cause of problems
> for a language specification and compiler is automatically generated
> code (like C++ generated by an IDL compiler).

How so? I know that generated code tends to stress compilers in some ways,
such as by generating unusally long identifiers, or by generating big switch
statements with thousands of case labels. Other than that, I'm not aware of
what would be special about the code that is generated by an IDL compiler.

> Btw, your interpretation
> of influence above
> is not what I meant.

Sorry, we seem to be misunderstanding each other then. I am simply not
aware of how the CORBA C++ mapping would have influenced the ISO
C++ mapping.

> > I cannot support this argument. After many years of CORBA, I know
> > that anyone can knock up a simple client server application after a
> > few hours, no problem. But I also know that, to build something that is
> > robust, scales well, and performs well, a lot of experience is necessary.
> > I have seen quite a number of projects that shot themselves in the foot
> > something terrible due to lack of that experience. (To some extent, this
> > is true for all distributed systems, I believe -- distributed systems
aren't
> > easy to get right, period. But CORBA does its share to make it even
> > harder at times, and unnecessarily so.)
>
> Looks like everything you say above supports my argument :-) CORBA
> makes
> it easy to build simple systems (as you agree) and makes it easier to
> build
> more complex systems -- which can't be done at all without an accepted
> interoperable standard like CORBA.

Can't it? Why is it necessary to have a standard to build complex distributed
systems? People built complex distributed systems a long time before there
ever was a standard. As far as I can see, the standard doesn't do much to
help people get on top of complexity. Rather, a standard is meant to provide
cross-vendor interoperability, source code portability, and a well-known
API. But I honestly don't see how a standard would help me to build
complex systems more easily. (I mean, it's not as if the standard would
make the inherent complexity go away, is it?)

Daniel Ortmann

unread,

Jul 25, 2003, 11:17:28 AM7/25/03

bru...@eudoramail.com (Bruce Fountain) writes:

> vin...@ieee.org (Steve Vinoski) wrote in message news:<6c2690b5.0307...@posting.google.com>...

> > As the quotes show, for the past N years and right up to the recent
> > past, Michi basically believed that CORBA was the greatest
> > distributed systems technology ever made, but almost overnight, it's
> > suddenly become the worst.

> I don't think he said that CORBA was the worst technology going.
> Maybe the second best :-)

And the statement "for the past N years" can't refer to Corba vs Ice
for those N years ... since Ice is fairly new. Isn't it?

At least, the oldest date I find in the current Ice release is July 21 2001.

> > Therefore, I believe Michi is being disingenuous in trying to argue
> > the superiority of his new software on technical grounds -- IMO, as
> > I've stated before, it's all just a facade to sell more of his new
> > software. I just wish he could admit that, given that it's as plain
> > as the nose on his face.

> For many years Michi has evangelised CORBA. His style hasn't changed,
> just the subject. I don't think anyone has any doubt that he has a
> vested interest.

I consult the excellent Corba text "Advanced CORBA Programming with C++"
jointly authored by Michi Henning and Steve Vinoski. Having that book
makes the debate more interesting. :-)

By the way, in these days of surplus $3 computer books, Michi and
Steve's book is holding its price well. The cheapest copy in the "new
and used" section at amazon.com is still at $40.

> > Previously in this newsgroup (comp.object.corba), readers objected
> > to vendors posting what were essentially advertisements for their
> > products, so we vendors took to explicitly marking such postings as
> > being "vendor specific" or "vendor advertisement." I believe
> > Michi's Ice postings should also be marked as such, given that
> > they're really just infomercials with some technical jargon thrown
> > in.

> Well, the posting was entitled "New Ice documentation available" and
> simply said "we've just released a new version of the Ice
> documentation" followed by a list of changes. I think that is pretty
> obviously a vendor statement, and I don't believe that the thread
> would have gone any different if he had prefixed it with "[ADV]".

I very much appreciate Michi's posting since the Ice documentation
cleared up _several_ of my confusions about CORBA.

In my opinion, CORBA has offered the world a service, and can
legitimately expect to be rewarded. ZeroC has also contributed a much
needed service, product and perspective. If people deem it worthy, they
will send ZeroC the appropriate "certificate service to their fellow
man" ... stamped at the top with the phrase "Federal Reserve Note".

> Best regards,
>
> Bruce Fountain

--
Daniel Ortmann, LSI Logic, 3425 40th Av NW, Suite 200, Rochester MN 55901
work: Daniel....@lsil.com / 507.535.3861 / 63861 int / 8012.3861 gdds
home: ort...@isl.net / 507.288.7732, 2414 30Av NW #D, Rochester MN 55901

Douglas C. Schmidt

unread,

Jul 25, 2003, 1:33:11 PM7/25/03

Hi Folks,

Ok, there's finally time today to reenter the fray. First,
let me address the FUD issue. To me, FUD is an
unsubstantiated/unvalidated claim (such as "CORBA is dead/slow/big" or
"UNIX is dead/slow/big," etc.) made as an appeal to people's
emotions/fears rather than their technical expertise. Just about
every talented/charismatic person in computing/software I've ever
talked to uses FUD in one way or another at some point. My use of the
term is not for character assassination, but to simply point out where
strong claims were made that weren't backed up by technical evidence.
Bottom-line - don't use FUD as the rationale for your claims and I
won't call you on it!

> Well, depends on what you mean by "getting fixed".

Again, I'm not arguing that the CORBA standardization process is
perfect - far from it. I'm simply arguing that it's guaranteed that
creating new *non*-standard middleware won't address the key reasons
why software standards are important for industry - particularly for
companies that are building systems that live for long periods of
time. This is crucially important for distributed real-time embedded
(DRE) systems.

> Doug, I haven't been talking about distributed real-time systems,
> I've been talking about general-purpose middleware. They are
> certainly different.

Agreed, though there's lots of overlap, e.g., many people use the same
CORBA middleware implementations for both. The key, of course, is to
"strategize" the middleware implementations in such a way that their
capabilities and services can be scaled up and down for a range of
domains. The best example of I've seen of this is e*ORB. Sam
Aslam-Mir <s...@prismtechnologies.com> gave an excellent talk about
e*ORB in DC last week, so I recommend you contact him for the slides
he used, which explain how their ORB middleware architecture can be
configured to support a wide-range DRE and general-purpose
applications.

> And, it really begs the question: why is it that the CCM
> specification was adopted in 1999 and now, in 2003, has to be
> redone?

Well, to quote Andrew Watson from last week's OMG Real-time Middleware
conference "the DRE systems community is largely driving CORBA
standarization at this point." I think he's right, though I think
that CORBA still has a tremendous impact on general-purpose middleware
(though not as much enterprise middleware anymore). Speaking from a
business perspective, I think the only place to make serious $$$ on
middleware *products* these days is in the DRE domain and the
enterprise domain. There's simply too much good general-purpose
middleware available in open-source form.

> Why is it that, as far as I know, therer is not a single commercial
> implementation of that specification?

Please see slide 70 of our recent CCM tutorial

http://www.cs.wustl.edu/~schmidt/OMG-CCM-Tutorial.ppt

for a list of CCM implementations, several of which are now supported
commercially.

> Why is it that so many CORBA specifications are not worth the paper
> they are written on and are never implemented?

I think you've explained this stuff in great detail in many of your
postings about the POS ;-)

> Need I remind you of the Cos services debacle? Or the much-heralded
> multicast specification that is still not implemented, to the best
> of my knowledge?

Are you referring to MIOP? TAO has supported MIOP for over two years.

> How much credibility is there in an organization that continues to
> publish documents such as this

I'm surprised to hear you say this, given that I *know* you know how
standardization processes work in general. The world of standards
(including OS, networking, language, and middleware standards by the
IEEE, ITU, OMG, IETF, etc.) is littered with MANY protocols, services,
features, APIs, etc. that have well-specificed definitions that exist
mainly/solely on paper. As usual, it's business decisions that drive
the implementation and adoption of standards, i.e., vendors implement
the standards that they can "sell" and companies end up using the
standards that solve their problems. The OMG has produced its share
of stuff that didn't pan out in practice, but so have all the other
standards bodies (ever heard of TLI, ATM, OSI, Ada, IntServ/RSVP,
etc.?). So is the solution to shutdown the IEEE, ITU, OMG, IETF (all
of which have released documents that were never
implemented/disseminated widely) and let the 800 pound gorilla IT
companies push whatever they feel like it at any given point in time?
Of course not!

> (despite my best efforts as an Architecture Board member to inject
> some reality into the process and to prevent these embarrassing
> incidents)?

I feel your pain, Michi! However, that doesn't invalidate the fact
that there are MANY useful parts of the CORBA specification, which are
being used by all sorts of companies for all sorts of real-world
solutions! Moreover, just because you were frustrated doesn't mean
that there aren't VERY good people working on improving the CORBA
specifications, particularly in the DRE arena.

> - I believe that there are very few people in the world who can
> claim to have worked harder or longer than myself on developing
> CORBA, specifying CORBA, teaching CORBA, promoting CORBA, fixing
> CORBA, or implementing CORBA.

I agree you've done a super job with CORBA for many years.

> To put me on a level here with Roger
> Sessions, (who had a very personal axe to grind with the OMG) is
> both inappropriate and in bad taste, IMO.

Bad taste or not, I find it ironic that the arguments you were using
in your initial "ICE promoting and CORBA bashing" posting sounded
nearly identical to the kinds of things that Roger et al have said
over the years. As Steve Vinoski pointed out in detail in his reply,
for years you eloquently defended CORBA against these very types of
FUD attacks. It's just interesting to me see you change your
perspective so radically now that you're working for a company that's
producing a product that competes with CORBA.

Of course, this is not wholely unexpected - and is actually quite
rational from a business perspective. I remember back when I first
started working on CORBA-related topics back in the early 90's I met
with Bjarne Stroustrup, who mentioned how various people (names
omitted to protect the guilty) who so loudly bashed C++ at the time
had been quite collegial in the 80's until the growth of C++ started
to conflict with their business interests.

> Well, I have taught CORBA to well over a thousand engineers over the
> years, many of whom were highly-experienced professionals with many
> years of software development experience. They didn't think it was
> easy -- they settled on CORBA simply because it was the best thing
> going for the job. After nearly a decade of having lived and
> breathed CORBA, I really have to look things up in my own book when
> I write CORBA code. Yes, really. I simply can't remember the
> incoherent and complex mess of APIs, memory management rules,
> inconsistent naming conventions, and needless verbosity.

Well, for some reason the 20-22 year olds we teach at universities
seem to have an easier time. Perhaps their brains haven't filled up
as much as ours ;-)

> And, forgive me, no matter how good a course you teach or how good a
> book Steve and I might have written, no-one learns CORBA in 6-8
> weeks to the point where they can create industrial-strength
> applications. Distributed computing in general, and CORBA in
> particular, are far too complex for that.

You're taking my words out of context Michi. I simply said that you
can learn the core CORBA C++ mapping and most important APIs in 6-8
weeks, which when combined with good software processes and tools
(such as Purify) can enable you to write good software. Clearly,
learning a framework/middleware the size of the entire CORBA
specification (and any given ORB implementation) takes longer than 6-8
weeks, but I suspect that's true of any framework/middleware of
comparable size and scope.

> > There's no question that CORBA could be simpler - especially given the
> > benefit of hindsight (and the lack of SOM compatibility in the early
> > days ;-)). However, it's also clear that UNIX, C, C++, C#, Perl,
> > Windows, X-Windows, MFC, ACE, SOAP, COM/DCOM, .NET, Java, J2EE,
> > Real-time Java, etc. all have accidental complexities and warts that
> > leave something to be desired. While it would be nice to throw them
> > all out and start from scratch, that's not always possible/sensible.
>
> Well, we think that is possible and sensible.

Well, far be it from me to argue with anyone who wants to banish all
the legacy software infrastructure, applications, developers, and
organizations! I have the same urges as you wrt this Michi. However,
there are times when Sancho get tired of following me and Rocinante
around... BTW, if you found it frustrating to purge the OMG AB of
their hide-bound tendencies, I'm going to be curious to see how you
feel after a couple of years of trying to convince industry to scrap
their investments in standards and legacy!

> By that argument, we would have to live with every wart and bad
> design ever invented by anyone, and we are certainly not doing
> that. (How many DOS programs get written these days? Or how many DCE
> programs, for that matter? And DCE proponents had much the same
> things to say about CORBA when it was new...)

Again, I think we're probably comparing apples and oranges here. If
you check out the domain of large-scale, long-lived, mission-critical
DRE systems, where the applications often live MUCH longer than any
particular proprietary tool/platform/company, you'll find companies
have legacy commitments (e.g., Jovial, CMS-2, HAL-S, etc.) that make
DOS look like "New Technology"!

> Hmmm... I can't say I like this line of reasoning. It really boils
> down to "Well, we can always put another layer of abstraction on
> top, so the bad design of the layer below doesn't matter." Far too
> much in computing is done with kind of attitude, to the detriment of
> the entire industry.

Again, I agree with you in principle Michi. That's one reason why our
long-term R&D activities are focusing increasingly on model-based
software development technologies, rather than exclusively on
middleware. Check out

http://www.cs.wustl.edu/~schmidt/PDF/MDA4PDF.pdf
http://www.cs.wustl.edu/~schmidt/PDF/QoS4PDF.pdf

for our latest thinking about this. I also gave a short presentation
at the OMG Real-time Middleware meeting that summarizes this
perspective. Check out

http://www.cs.wustl.edu/~schmidt/doug-omg.ppt

for details.

> Doug, please! Comparing a dedicated real-time ORB with a
> general-purpose ORB or middleware platform such as Ice is
> inappropriate, and you know that.

No, I actually DON'T know that. TAO is a classic example of very
configurable, open-standards-based, COTS middleware that's widely used
for both general-purpose and DRE applications. Moreover, you and Mark
both made claims that CORBA was "inherently" slow and big, yet this
simply doesn't seem to hold up under closer empirical scrutiny (which
is why I labeled it as FUD).

> Last time I looked, e-ORB was certainly very fast (and it appears to
> be a fine product for its market), but it only provided a small
> subset of the CORBA spec, and certainly wasn't standard compliant.

I think you should probably look again ;-). Now that e*ORB has been
"rescued" from Vertel, it's been doing a nice job of establishing
itself as a powerful, highly configurable, and standards-compliant
ORB. Please contact Sam Aslam-Mir <s...@prismtechnologies.com> for
more info. Likewise, ORBexpress is also highly compliant with the
CORBA standard, and interoperates nicely with TAO.

> BTW, Gautam has already done some benchmarks on Ice and, for what it's
> worth, Ice appears to be remarkably fast. (See
> http://www.zeroc.com/vbulletin/showthread.php?s=74b49746368e034316f1d319b163289b&threadid=27 for details.)

Gautam's out of town right now, but he'll be back next week so we can
clarify these issues in detail then. However, if you check out some
results from Gautam's webpage (courtesy of Bill Beckwith) that I've
put at

http://www.cs.wustl.edu/~schmidt/ICE_perf.png

you'll see that for a simple "null" RPC call, ORBexpress (both C++ and
Java) and TAO are ALL faster than ICE. Obviously, we'll need to do
more testing to determine the pros and cons of each approach
empirical, but I think this simple example should illustrate why I
consider it FUD for you guys to claim that ICE is somehow "inherently"
faster than CORBA!!!

> Well, if you insist on comparing apples and oranges, of course.
> ORBacus/E also is faster than Ice. But ORBacus/E is a dedicated
> embedded effort and not fully compliant with the CORBA spec. And
> ORBacus/E is unsuitable as a general-purpose middleware, just as
> many, if not all, of the embedded and real-time ORBs are.

Hum, that just doesn't ring true to me given all the discussion above.
Perhaps we have a different definition of "general-purpose middleware"
is. For me, "general-purpose middleware" is middleware that can be
configured to support most/all of the features/services defined by
distribution and common middleware service specifications, such as
those defined by CORBA. The last time I checked (see
www.cs.wustl.edu/~schmidt/ACE_wrappers/TAO/docs/releasenotes/ for
details) TAO supported most of the *useful* OMG features and services
(either directly or via 3rd party integrators, such as those described
at http://www.cs.wustl.edu/~schmidt/TAO-integrators.html), which
enable it in my book to be considered "general-purpose middleware."
It's also possible, however, to configure TAO so that it's useful for
DRE systems, as well. If you check out

http://www.cs.wustl.edu/~schmidt/TAO-users.html

you'll see that a signficant number of TAO users are applying it to
mission-critical DRE systems, as well as general-purpose solutions.
When you combine this with the range of ORB middleware solutions from
companies like PrismTech (who support e*ORB, TAO, and JacORB) and OCI
(who support ORBit, TAO, and JacORB) it looks to me like CORBA's able
to cover a wide gamut of domains in a standards-compliant, portable,
and interoperable way.

> You keep talking about real-time and embedded ORBs, not
> general-purpose ORBs. Where are all the general-purpose ORBs? Where
> is BEA's ORB these days? Or IBM's? Or Expersoft's? Or Rogue Wave's?
> How much vendor choice do I have left when I'm looking for CORBA
> these days?

Well, let's see, how about:

. Orbix <http://www.iona.com/>
. Visibroker <http://www.borland.com/visibroker/>
. OpenFusion <http://www.prismtechnologies.com/English/Products/CORBA/index.html>,
which includes JacORB <http://www.jacorb.org/> and TAO <www.cs.wustl.edu/~schmidt/TAO.html>
. TAO <http://www.theaceorb.com>
. orb2 <http://www.2ab.com/orb2.htm>
. omniORB <http://omniorb.sourceforge.net/>
. Varadhi <http://www.sankhya.com/info/varadhi.html>
. K2 <http://www.icmgworld.com/products.asp>

to name the ones off the top of my head. But I think in many ways
you're asking the wrong question. This is like asking "is UNIX dying
because there are fewer hardware vendors pushing their proprietary
versions of UNIX?" The answer, of course, is NO! What's happening in
the UNIX community is that

1. A few hardware vendors are continuing to successfully push their
proprietary versions of UNIX (these few companies are similar in my
mind to IONA, Borland, etc).

2. The rest of the hardware vendors have gotten behind Linux, which is
and open-source implementation of UNIX that's actually more standards
compliant than most of the proprietary versions)!

I think we're seeing something similar happening in the ORB middleware
domain, where the open-source ORBs (and the commercial companies that
support them in much the same way that RedHat, SuSE, and Debian
support Linux) are starting a major consolidation of the
general-purpose ORB middleware market.

> Completely agree. In fact, the Open Source communities have
> definitely done a lot for CORBA (much more than the commercial
> vendors, IMO).

I agree with you for general-purpose middleware, which is rapidly
becoming a commodity. However, there are still good reasons why
commercial vendors (such as OIS and PrismTech) are doing quite well in
the more extreme ends of the spectrum in the DRE domain, which are not
(yet) commoditized.

> But I also believe that, as long as these ORBs adhere to an aging
> and clumsy specification, they will never come anywhere near their
> full potential.

LOL! This sounds like it could be almost an exact quote from Bill
Gates about Linux/UNIX any time during the past two decades!!

> CORBA was a great thing in its day.

Again, this sounds like Bill Gates talking about Linux/UNIX!

> But the specification process is too inflexible, and fundamental
> design problems (such as the inability to version IIOP properly)
> make it just about impossible to incorporate technical improvements
> into the platform. As a former OMG Architecture Board member, I can
> definitely assure you that topics like fixing IIOP make people's
> hair stand on end, due to the immense technical and marketing
> difficulty of doing so, plus the weight of legacy and backward
> compatibility issues.

No one said that standardization is easy, Michi. And no one is
claiming that CORBA is perfect. But in key domains (again,
long-lived, mission-critical DRE domains) there really is no other
reasonable way forward given the constraints.

> Doug, see above -- I believe that comparison with Roger is
> singularly inappropriate here.

Michi, I apologize that I've compared you to Roger *the person*. But
I still think it's ironic that your original email sounded like you
were reading from a Sessions cue card! For the record, this email has
a LOT more technical content to it, so I official retract my Sessions
comparison (but the Bill Gates comparisons still apply ;-)).

> I have spent many years doing CORBA, and I am generally recognized
> as one of the world's experts on the topic.

Yes, indeed - and rightly so!

> And I am sick of doing things the hard way when they can be so much
> easier. I am not trying to throw mud at CORBA. (I personally
> invested far too much of myself in CORBA for that).

Ok, thanks for saying this publically.

> But I want to point out that some of the arguments for CORBA should
> be examined more closely: by and large, the benefits of
> standardization of CORBA have not been realized.

Agreed, though I still claim this is largely due to a failure of the
typical software process followed by development organizations rather
than something inherent in modern CORBA ORBs. Moreover, the solution
that you're proposing now (ICE) doesn't get us any closer to realizing
the benefits of standardization either!!

> Vendors insist on adding their own extensions (often incompatible
> with the specification), much of what is needed is underspecified,
> and the much-touted freedom of choosing a vendor largely does not
> exist: even with 100% CORBA compliance, another vendor may not
> support the platform I need, may not provide the language mapping I
> need, may not support the compiler I need, or may not implement the
> particular part of the CORBA spec I need.

While this is often true for proprietary ORBs, it just doesn't make
sense given the availability of very good open-source ORBs. Companies
like OCI and PrismTech make a good business catering PRECISELY for
customers with the types of needs you mention above, and they support
multipe ORBs (e*ORB, TAO, JacORB, and ORBit).

> Realistically, there is little choice of vendor in many situations
> (not all situations, I freely admit).

I agree there is often little choice of vendor for enterprise
applications. For general-purpose applications and DRE applications
there's a good choice of vendors for CORBA products, as I've listed
above.

> Doug, of course Ice is not as efficient as a real-time ORB! Why do
> you keep comparing a general-purpose platform with a general-purpose
> one?

[BTW, I think you might have mean "with a real-time one" above - LOL!]

I do this because I think the distinction between a general-purpose
ORB and a real-time ORB is largely a false dichotomy *if* the ORB is
implemented correctly.

> We believe that Ice is faster than any general-purpose ORB.

Again, we'll need to wait for Gautam to prove/disprove this
empirically in an open and objective comparison.

> And it provides that performance with APIs that are a fraction of
> CORBA's in complexity, and with a smaller footprint.

Yes, again, this claim needs to be substantiated empirically.

> And, to boot, it provides features that neither general-purpose nor
> DRE CORBA implementations can provide: a persistence service that is
> incredibly easy to use,

BTW, it's worth pointing out that the AMD approach you mention here is
remarkably similar to the AMH approach implemented by TAO back in
2000!

> asynchronous method dispatch,

> an efficient protocol that doesn't waste bandwidth, compression on
> the wire, security, etc. (Where is CORBA's security? Please don't
> tell me about the firewall spec which, apart from the complexity of
> administering all this machinery, requires every firwall vendor in
> the world to make extensive changes to their product -- how
> realistic is that?)

Please see

http://www.2ab.com/corba_sec.htm

for detailed information on an implementation of CORBA Security from
2AB. We're in the midst of adding similar capabilities to TAO and
hope to work closely with the 2AB folks to ensure interoperability. I
believe that there's also some good work on CORBA security being done
in the open-source MICO community, which should be readily portable to
other ORBs.

> I don't think this answers my question. Again, how much has the CORBA
> standardization really achieved for people? Not a lot, IMO.

Well, I'm not sure exactly what it'll take to convince you Michi that
CORBA standardization has been CRUCIALLY important for MANY, MANY
companies. There's a major push within key industries that develop
long-lived product lines (including defense/aerospace, process
control/manufacturing, telecom/datacom) to use CORBA, and one of the
primary motivations has been standardization. The fact that you don't
seem to (want to) acknowledge this makes me believe you're
intentionally deciding not to see it!

> No, I'm not talking about BOA-to-POA transitions here, I'm talking
> switching from things such as Orbix 2000 to ORBacus, or Visibroker
> to TAO.

People do this ALL the time now - in fact, companies like OCI and
PrismTech now make $$$ selling documents, products, and services that
simplify this process.

> Well, why is it painful if things are supposedly so well
> standardized?

You're putting words into my mouth here Michi. I never that the CORBA
standard was perfect (especially the early standards) - I just said
that modern ORBs written using newer features aren't very hard to port
to/from if you use appropriate tools and patterns.

> You mean painful because of the BOA? But the BOA was a standard too!

Pulleeeeeze Michi, don't EVEN go there!!!!

> Bidirectional IIOP and CORBA security were standards too, as I
> recall. What has become of those?

As far as I know, TAO's supported bi-directional GIOP/IIOP for the
past 3-4 years. As for CORBA security, please see the discussion
above about this.

> No, that's not FUD, that is first-hand experience I have gathered
> over the years.

I agree that earlier generations of ORBs were hard to port between.
But the modern ORBs that are available now (e.g., Orbix 2000, latest
Visibroker, TAO, omniORB, etc.) are really fairly easy. I don't know
whether you've done much consulting with ports between these ORBs in
the past two years, so perhaps your sample is different from our. At
any rate, you should contact Richard McClain from LMCO and Tom Jones
from Raytheon who gave a talks at the OMG Real-time Middleware
workshop last week about their experiences porting to/from modern
ORBs. These are the guys in the trenches and they don't seem to be
having the same problems that you've encountered much any more.

> The amount of effort to simply change a Clearcase-based development
> environment alone to a different ORB is staggering.

Perhaps that's an indication of the problem with the development
environment, not the ORB!

> And we haven't talked about the need to use different tools to
> administer the whole thing, the changes in testing procedures, the
> changes in deployment of services, etc. This things impose a
> considerable cost.

So, it sounds like your solution is to "use ICE and leave your trouble
behind"? I really don't see how this is a viable solution for the
types of long-lived mission-critical systems that I've been
discussing. Let's face it, the OOC folks did a great job with
omniBroker/ORBacus, which were based on standards and still live on
today despite the fact that the original development team has moved on
to "better" things.

However, can you convince your potential ICE customers that the same
thing won't happen in 3-4 years when an even more appealing technology
comes along? How will they protect their investment, when there most
likely won't be a "standard" (however "lame" it may be - LOL) to
sustain interest in continuing forward development. From this
perspective, shouldn't Expersoft's Xshell product have won out since
it was more intuitive for C++ developers than CORBA back in 1991?!

My point is that while I appreciate many of your critiques, I remain
unconvinced that your remedy is actually a "cure" for the problems of
many important distributed systems.

> > you'll see there were talks by Raytheon, BAE Systems, Boeing, and
> > Lockheed Martin last week describing their experiences developing and
> > porting MAJOR (i.e., million lines of C++ and CORBA code)
> > mission-critical DoD combat systems and radio systems using multiple
> > ORBs. The basic consensus was that as long as you stick with "good"
> > ORBs (i.e., the ones I mentioned earlier that are compliant with the
> > CORBA spec) and use available tools (such as CORBA auto-conf
> > <http://corbaconf.kiev.ua>) the porting process is straightforward.
>
> Doable? Yes. Straightforward? In some cases. Cheap? Never.

I guess it depends on what you consider "cheap". However, now that
there's

1. A body of expertise, which companies like OCI and PrismTech can
provide and

2. A set of tools/processes that largely automate all the guess work

The process really isn't very hard or time consuming, especially if
you know what you're doing. Moreover, the complexities of doing these
migrations PALE in comparison with the INHERENT complexities of
developing distributed systems. Finally, it's CERTAINLY
cheaper/easier than having to move to a totally new middleware
platform every few years as companies lose interest in supporting
their proprietary platforms (I'm speaking about Microsoft here, of
course ;-)).

> > In fact, in talking with the speakers mentioned above, they said they
> > are regularly develoing their systems with both ORBexpress and TAO in
> > order to ensure they are remaining compliant with the standard APIs.
>
> Well, if they really were compliant, I wouldn't have to develop for two
> ORBs in parallel, just to be sure, would I?

That's correct - as long as you have programmers who have enough
knowledge/experience to follow the published specification alone. But
it never hurts to get a "second" opinion, particularly when it doesn't
require much additional time/effort! If you check out

http://www.dre.vanderbilt.edu/scoreboard

you'll see that we build ACE+TAO on about 30 different
OS/compiler/hardware configurations 24 hours a day just to get "second
opinions" about portability and correctness issues. We've automated
this process years ago and it more or less just takes care of itself
now.

> > The bottom line is that it's really no harder to develop portable
> > CORBA applications now than it is to develop portable UNIX and Windows
> > applications.
>
> Right. And that is far too hard.

Only if you don't use the right host infrastructure middleware ;-)

> I think we both agree that without the open-source community, this
> industry would be in an even bigger mess than it is actually in! It
> is sad though to see so much creativity and energy being spent on
> something with so many deep-seated problems.

Agreed.

> > Give me a break Michi. This is NO different than for UNIX, Windows,
> > and real-time embedded operating systems, which are MUCH more diverse
> > than today's leading CORBA ORBs.
>
> Excuse me? Does this make it right or acceptable? Just because it's
> as bad as other things, I have to put up with that? That doesn't
> make sense to me.

Well, I think we're just going to have to agree to disagree here
Michi. While I agree with you at some fundamental level, I spend too
much time in the real world (which is particularly odd for an academic
;-)) to worry about whether support for cross-platform development is
"right" or not. It's a reality, and one that can be addressed
surprisingly easily if you use the right tools/platforms/patterns.
What keeps me awake at night is trying to solve the INHERENT
complexities of DRE systems, so stuff like this really is in the
"noise" most of the time once you get the build environment setup
right.

> We don't seem to have spoken to the same people, or seem to have
> interpreted their messages differently. As far as I am concerned, if
> I need an auto-conf tool to write code for more than one middleware
> platform, there is something wrong with the middleware.

Ok, so now you sound like Scott McNealy ;-) ;-). But seriously,
there's a reason why attempts at defining the "One True Middleware"
API/tool/mapping go awry - mostly because no one (even you) is smart
enough to "get it right" the first time. Rather than trying to figure
out if this is "right or wrong," my pragmatic approach is simply to
figure out how to apply tools and patterns to make these issues
evaporate in practice. I admit that this isn't the idealist solution,
but it works well in practice.

BTW, this reminds me of another quote I once heard from Bjarne, who
said "some programming languages are designed to solve a problem,
whereas others are designed to prove a point." Clearly, C++ falls in
the former category, as do most of the tools/platforms/languages used
by software developers around the world.

> Installing and using the tool doesn't come at zero cost, and I
> shouldn't need such a tool in the first place.

Again, we can debate this ad nauseum, but I suspect that for most
people, installing and using an ORB conf tool is the LEAST of their
worries when developing a mission-critical DRE system that's designed
to run for 20+ years!!!!

> Hmmm... How many CORBA vendors offer a product that provides even
> half of all these things?

Aside from the obvious answer ;-), I recommend you check out
Arno's "CORBA product matrix" at

http://www.puder.org/corba/matrix/

which has a good summary of the relationships of CORBA products to
CORBA services/features, etc.

> Last time I looked, there wasn't a single commercial vendor that
> would provide CCM, load balancing, transactions, and fault
> tolerance. (Pick any two, and you just might be lucky.)

Well, there's at least one commercially supported ORB where load
balancing, fault tolerance, transactions, and CCM are all supported
(I'll let you guess which one it is ;-)) and I'll let the other ORB
vendors do their own marketing.

> Just because there is a CORBA specification for something, that
> doesn't mean that it exists, that I can buy it, or that I can buy
> from the vendor I need to buy it from and for the platform I need it
> to run on.

Of course not, but you can certainly get the most useful CORBA
features/services from multiple vendors on a VERY wide range of
platforms, including

. Windows (i.e., WinNT 3.5.x, 4.x, 2000, Embedded NT, XP, Win95/98,
and WinCE using MSVC++, Borland's C++ Builder, and IBM's VisualAge on
Intel and Alpha platforms) and MacOS.

. Most versions of UNIX (e.g., Solaris 1.x and 2.x on SPARC and Intel,
SGI IRIX 6.x, HP-UX 10.x and 11.x, Tru64UNIX 4.x, AIX 4.x and 5.x,
SCO, and freely available UNIX implementations, such as Debian Linux
2.x, RedHat Linux 5.2, 6.x, and 7.x, FreeBSD, and NetBSD)

. Real-time operating systems (e.g., LynxOS, VxWorks, QnX Neutrino,
OS9, and ChorusOS)

. Big iron, (e.g., OpenVMS, MVS OpenEdition, Tandem, the Cray
supercomputer, etc).

I'm sure there's a platform or two missing there ;-). Of course, if
the ORB is a good open-source ORB it should be straightforward to
either do the port or pay a commercial company to do the port.

> Well, that might happen, we'll just have to wait and
> see. Personally, I am much happier to work on something that is
> slick and elegant, instead of cumbersome and clumsy.

We'll remind you of this in 3-4 years when you've changed your mind
again ;-)

> And, currently, I would call SOAP, J2EE, .NET, and CORBA niche
> technologies too: none of them is ubiquitous. If we have room for
> four RPC platforms, surely there must be room for a fifth?

As usual, the invisible hand of the market will decide!

> That I really would call a fallacy. The lack of a threading model in
> CORBA is definitely not straightforward to solve in practice,
> otherwise it would have been solved years ago.

Hum, I guess you haven't read the Real-time CORBA spec then? It's had
a standard threading model since 1998? Please see

http://www.cs.wustl.edu/~schmidt/report-doc.html

for a serious of columns on Real-time CORBA and its threading model
that Steve and I wrote several years ago.

> None of these problems are "straightforward" to solve. In fact, many
> of them are impossible to solve, due to the political nature of the
> OMG, the legacy problem, and the drag of backward compatibility and
> vendor apathy.

You'll get no disagreement from me that the OMG process could be better!

> I think we just will have to disagree then. Most certainly, my
> experiences have been nowhere near as rosy.

Hum, I guess I'm confused then. As far as I can tell, as recently as
06/27/2002 (i.e. last year around this time) you were saying stuff
like:

----------------------------------------

Given that you've been working on ICE most of the past year (as
opposed to working on modern ORB projects - which are the basis of my
"rosy" view) it's not really clear to me what changed during this
time...? As Steve said so eloquently "Which Michi are we to
believe?"!

> Actually, I think there are several good excuses:
>
> - Developer ignorance. It is not reasonable to expect developers
> to be conversant with the spec to the degree required to steer
> away from non-portable or vendor-specific constructs.

Right, that's why it helps to use multiple ORBs to keep developers
"honest". As I mentioned above, we do the same thing with ACE for
zillions of OS platforms and it works just fine.

> - Overhead. Why should I have to worry about all these extra
> layers of patterns, tools, and techniques just to get portable
> code? Why can't the API be portable, period?

For CORBA it is - largely, with a few well known exceptions that are
trivially covered using the CORBA conf tools.

> (And Doug, really, if CORBA is so portable, what exactly is
> it that all these patterns, tools, and techniques are achieving?)

Two things:

1. Future proofing

2. Providing a domain-centric interface, rather than a
middleware-centric interface.

> - Cost. All the extra patterns, tools, and techniques have a
> cost, both financial, and in terms of complexity, footprint,
> and performance.

Again, these costs are in the noise for non-trivial systems.

> Well, I don't think it is. The dream of interoperable and portable
> software has by and large not been realized by CORBA.

I think we've been through this already, so I won't beat the dead
horse anymore.

> Maybe that isn't CORBA's fault -- maybe the dream is unrealistic.

No, I don't think it's unrealistic at all. In fact, people do it all
the time now.

> I just spoke to a large company who was forced by the demise of a
> commercial CORBA vendor to switch ORBs. The story they told was very
> painful, and they were greatly disillusioned by the way their
> investment in standardized technology had failed to pay off.

While I'm sure you can't mention any names, it's probably worth
pointing out that the commercial CORBA vendor wasn't complying to the
modern standards very closely...

> The cost was large for that company, both financially and in terms
> of development effort, defects, and down time. Doug, these people
> would laugh in your face if you told them that the issue is moot!

Michi, you're still trying to put words in my mouth. If companies
want to (1) use outdated versions of products from (2) companies that
aren't truly interested in supporting standards and (3) aren't willing
invest in the (minimal) efforts to ensure their software is portable
then there's just not a whole lot I can do for them... And they can
laugh all they want at me, but THEY'RE the ones who've screwed up and
have to pay the price! To put a different face on this, plenty of
companies around the world are switching from old/proprietary versions
of "standard" CORBA to modern standard CORBA and are succeeding quite
nicely. I'm not sure what else to say than to check out

http://www.cs.wustl.edu/~schmidt/TAO-users.html

for a list of just a few of the MANY companies that are succeeding!

> Thanks! We believe that Ice is better, period.

Wait, are you SURE about this Michi? I mean, you wouldn't want to say
anything half-hearted here, right? ;-) ;-)

> It will never be all things to all people, just as no other
> technology is. But, if you are looking for a simple, efficient, and
> reliable technology for RPC, Ice leaves CORBA in the dust. To some
> people, that matters more than anything.

I certainly can't argue with that.

> That is very well possible. And, if that's what happens, suits me
> fine -- we aren't interested in world domination, but in quality
> technology. We do provide that and leave world domination to other
> people :-)

Touche!

> Again, these aren't Box/Session tactics. The concerns I raised are
> real in my opinion, are technically well founded, and are not
> FUD. They are born of many years of very intensive work on CORBA,
> and many years of consulting to customers. If I wanted to spread
> FUD, I'd write an article for one of the trade rags instead of
> posting here. Ice offers an alternative to CORBA that may be
> suitable for many people because it is well possible that the
> arguments in support of CORBA don't stand up under closer
> examination.

Or not... but at this point in the email I'm not going to rehash all
the point-by-point discussions again.

> In such cases, Ice is definitely worth a look.

I agree with this.

> And no, I of course wasn't going to let you have the last word ;-)

Hahahahhaha, well, you ALMOST did since this week has been hectic.
Hopefully I can catch up on the rest of the thread later today.

> How about we talk about this at JAOO? Steve Vinoski, Doug Lea,
> Bjarne Stroustrup, and Jim Coplien will all be there too. Should
> make for a lively evening over a few beers :-)

Sounds like a great plan! Now, all we need to do is invite Com Box
and we'll REALLY have a row!

Douglas C. Schmidt

unread,

Jul 25, 2003, 1:39:36 PM7/25/03

Hi Steve,

>> Previously in this newsgroup (comp.object.corba), readers objected
>> to vendors posting what were essentially advertisements for their
>> products, so we vendors took to explicitly marking such postings as
>> being "vendor specific" or "vendor advertisement." I believe
>> Michi's Ice postings should also be marked as such, given that
>> they're really just infomercials with some technical jargon thrown
>> in.

Bingo - again this is particularly ironic coming from Michi, who IIRC
was always beating up on ORB vendors/developers for "tooting their own
horn" in comp.object.corba. My recommendation would be to start a
comp.object.ice (or whatever) newsgroup and these discussions can
continue ad nauseum in that forum!

Thanks,

Douglas C. Schmidt

unread,

Jul 25, 2003, 2:03:52 PM7/25/03

Hi Marc,

>> It is very clear to me that CORBA is slowly dying.

This is FUD - plain and simple, i.e., there's no proof, no citations,
no evidence, just good ol' "fear, uncertainty, and doubt". Here's
some counter-FUD: "Based on the meteoric rise in postings from users,
web download, and sales of documentation and precompiled software
kits, use of open-source CORBA is growing by leaps and bounds all
around the world." BTW, there's actually evidence for this ;-)

>> But I see very little traction in the CORBA world anymore. Fact is,
>> that there are much fewer dollars invested in CORBA than this used
>> to be the case, both by vendors and customers. And not only due to
>> the poor economy, no, CORBA had an overproportional rapid decline
>> in the last years.

Again, some counter-FUD: "The overall downturn in the global IT
enconomy, which has dried up IT budgets and caused many IT
platform/tool providers to fail, has led many companies (particularly
telecom and aerospace/defense companies) to move towards open-source
operating systems (such as Linx) and middleware (such as CORBA)
solutions. Most telecom providers and aerospace/defense integrators
are investing heavily in standards-based open-source OS/middleware
solutions since they see it as a way to avoid catastrophe when small
companies selling proprietary solutions disappear." There's also lots
of evidence for this, as well.

>> Some CORBA vendors even tried to downplay the fact that they are
>> CORBA vendors.

The fact that there are (or were) CEOs at certain companies that
couldn't manage their way out of a wet paper bag should be an
indictment of their (lack of) leadership skills and vision, rather
than an indictment of the technology!!! Fortunately, other CORBA
vendors are doing quite well, so the overall balance is positive.

>> And the OMG now focuses much more on MDA than on CORBA.

Of course - that strategy makes a lot of sense since DOC middleware
has largely been successful and there's a LOT more effort required to
address the MDA-related challenges. I recommend you read the book
"The Innovators Dilemma" by Clayton Christensen for good coverage of
what happens when organizations spend too much time "looking at their
backswing" rather than moving ahead to address next-generation
challenges.

>> Given this situation, I believe that Ice has a brilliant future.

That belief doesn't surprise me at all ;-)

>> I can tell you from the many companies that are currently
>> evaluating Ice, or already building it in their next-generation
>> product, that there is a lot of interest in a new, easy-to-learn,
>> "technical middleware" platform. Of course, your opinion might
>> differ, and ultimately only time will tell.

No question there. The big question is "why the $%^#& are you posting
this FUD and ICE marketing stuff on comp.object.corba"?!?!?!

Douglas C. Schmidt

unread,

Jul 25, 2003, 2:20:57 PM7/25/03

Hi Michi,

>> Can't it? Why is it necessary to have a standard to build complex
>> distributed systems?

I find it strange that you would even ask this question Michi. Pretty
much by definition, "complex distributed systems" tend to live a long
time - usually MUCH longer than the "attention span" of COTS providers
who basis their technologies on non-standard
tools/platforms/services/etc. The world of IT is LITTERED with what
Steve Vinoski calls "Middleware Dark Matter"
<www.iona.com/hyplan/vinoski/pdfs/IEEE-Middleware_Dark_Matter.pdf>,
which causes ALL SORTS of problems wrt quality, capability, and total
ownership costs. But don't take my word for it - check out

http://www.cs.wustl.edu/~schmidt/Tech_030612.pdf

for information from one of the major US aerospace/defense integrators
talking about the challenges they face when building complex
distributed systems, and how standards are helping them out. In fact,
starting page 18 you'll find some interesting stuff ;-)

>> People built complex distributed systems a long time before there
>> ever was a standard.

Sure, and these systems have INEVITABLY become albatrosses around the
necks of the companies that have to maintain them over a long period
of time. Some major telecom equipment providers have been virtually
crippled by the total ownership costs of maintaining their
cathedral-like switching systems based on proprietary technologies.

>> As far as I can see, the standard doesn't do much to help people
>> get on top of complexity.

Quite frankly Michi, if you don't see this, you need to spend more
time working with people building long-lived, complex distributed
systems! There's now a lot of empirical evidence (i.e., gathered from
detailed cost/schedule/quality metrics collected over many years) from
companies like Boeing, Siemens, Raytheon, SAIC, LMCO, etc. that
illustrates the lifecycle cost savings of developing these types of
systems using standards-based approaches.

>> Rather, a standard is meant to provide cross-vendor
>> interoperability, source code portability, and a well-known
>> API. But I honestly don't see how a standard would help me to build
>> complex systems more easily. (I mean, it's not as if the standard
>> would make the inherent complexity go away, is it?)

I disagree here again Michi. In fact, if you look at MATURE IT
industries (e.g., micro-processor manufacturers and the IP equipment
provider market) you'll see that the use of standards is ESSENTIAL to
obtaining the economies of scale necessary to focus their R&D
activities on actually resolving the inherent complexities, rather
than wasting time rearranging the accidental complexities (which
ultimately end up being like rearranging deck chairs on the Titanic).
For a very detailed discussion of this point, please see

http://www.cs.wustl.edu/~schmidt/PDF/middleware-chapter.pdf

Having said that, of course, standards are no panacea. However, the
LACK of standards in the middleware domain is SERIOUSLY hurting the
competitiveness of the world IT distributed systems market.

Take care,

Douglas C. Schmidt

unread,

Jul 25, 2003, 2:30:23 PM7/25/03

Hi Mark,

>> By the way, I agree with you that writing a good C++ mapping isn't
>> so hard. This makes it even more confusing to me why there is no
>> new C++ mapping for CORBA. The only answer I can think of is that
>> neither the CORBA vendors nor the OMG care.

Is there a reason why you just can't stay away from slinging FUD Marc?
At any rate, in case you're actually interested in a rational
technical discussion of these issues, please check out

http://www.cs.wustl.edu/~schmidt/report-doc.html

and read the three columns Steve and I wrote for the C/C++ Users
Journal that explains the various forces involved here. LOTS of
people (including the OMG and ORB vendors) would like a better
mapping. As usual, it comes down to balancing various forces. IMHO,
the "Right Thing"[TM] to do would be to start an initiative to get the
major ORB vendors who care about this to develop their own alternative
mapping, get it working in multiple mainstream ORBs, and then submit
this to the OMG revision task force. The TAO group has talked with
OIS about doing this, and if we ever get some spare cycles we'll work
it out. If someone wants to sponsors this work, it'll get done
faster.

>> Besides, Ice is not proprietary. It is available under the GPL. We
>> only charge for licenses if somebody doesn't want to make their
>> programs available under GPL-like terms. See
>> http://www.zeroc.com/licensing.html

I think you're mixing up your terminology here - probably
intentionally. Here's the bottomline, Ice isn't based on any ratified
standard, CORBA is. It's also not free of charge for the vast
majority of organizations who want to develop software they aren't
planning to give away in source-code form. At least Michi was honest,
he said "we're in this to make $$$." I have no problem with that, but
let's not play word games, ok?

Thanks,

Douglas C. Schmidt

unread,

Jul 25, 2003, 2:39:38 PM7/25/03

Hi Frank,

>> Let's not forget the benefits that CORBA gives us. GIOP/IIOP is
>> about the best there is, it's widely accepted, compact (even though
>> you can have religious discussions over padding that never matches
>> in-memory padding when you need it), and reasonably easy to
>> implement. That the IIOP version number to the GIOP version number
>> is unfortunate, but not such a big deal.

Exactly. One of the problems with being an expert (or an academic
;-)) is that it's sometimes hard to realize that a lot of the dark
corners that are so tantalizing intellectually are actually not
something that makes any difference in practice.

>> Interoperability between ORBs is not an issue these days. The wide
>> acceptance of Open Source ORBs like Mico, TAO, and easily
>> accessible ORBs like ORBacus certainly did the trick here.

Rigth.

>> Even source code compatiblity isn't so bad, once you get past the
>> header file anomalies (fortunately, at least all Open Source ORBs
>> allow you to configure header file suffices) and follow the good
>> advice in Michi's book, you're almost there.

Yup - plus the CORBA conf tools help a lot here, as well.

>> So I think that at this central core, CORBA is sound and healthy,
>> even if that argument only applies to like 10% of the current volumes
>> that call themselves CORBA spec.

Agreed. Again, the fact that some companies sell "CORBA" products
that implement ancient mappings and APIs is not an indictment of
CORBA, but of those companies. Fortunately, there are enough good,
interoperable, modern ORBs available to write portable, effective,
efficient, robust distributed systems.

>> I love the simplicity of Ice's C++ mapping, and getting some of
>> the same for CORBA would be wonderful. I'd like to see Ice being
>> based on GIOP for interoperability, and its C++ mapping submitted
>> to the OMG as the future C++ language mapping 2.0 for CORBA. That
>> would go a long way in making CORBA more appealing. I know I'm
>> dreaming here.

So here's a question for the ZeroC folks - if someone were to
recommend the Ice C++ mapping as the C++ language mapping 2.0 for
CORBA would that be consistent with the Ice/ZeroC license? Put
another way, is Ice *really* that open?

>> Yes, there's plenty of things that are wrong with parts of the
>> CORBA specification(s). Sometimes it's good to take a step back and
>> publish a version 2.0 specification, taking into account all you
>> learned when applying version 1.0, and not making the same mistakes
>> again. In effect, that is what the embedded systems domain is doing
>> at the moment, trying to focus on the pieces that CORBA does really
>> well, removing add-on features like the kitchen sink. And I think
>> CORBA will greatly benefit from these efforts.

Yes, indeed! IMHO, the DRE domain is the key future market for CORBA.
Fortunately, it's also a rapidly growing economic force, particularly
as the general-purpose software market is increasingly outsourced to
countries that can't afford to pay high costs for software licenses
(which therefore motivates them to use zero-cost open-source
solutions).

>> I also have high hopes for component-based development, where you
>> interconnect components into higher-level assemblies.

This is clearly the future of middleware, particularly when combined
with model-based software technologies.

>> This design paradigm is not a CORBA exclusive, but CCM, once you
>> get past its more intimidating chapters, takes the idea the
>> farthest.

Agreed, and moreover there's a substantial amount of R&D effort going
on today to add QoS support to CCM.

>> Lightweight CCM, however unfortunate the name (it should be called
>> CCM, and the current spec should be Persistent and Transactional
>> Component Model or something like that) should make that even more
>> accessible. And I think that it will see early adoption by Open
>> Source ORBs (by coinci- dence, MicoCCM pretty much exactly
>> implements the Lightweight CCM subset already, as does OpenCCM);

That's great news!

>> I already hear embedded systems engineers screaming for
>> commercial(ly supported) implementations.

Yup!

>> So there's lots to be done, but I am not yet convinced that
>> there's only darkness glooming ahead.

Well, just don't read Marc's postings then - or you'll think the end
of the world is close at hand for CORBA ;-)

Douglas C. Schmidt

unread,

Jul 25, 2003, 2:48:55 PM7/25/03

Hi Michi,

>> I don't want to pour too much water on CCM but, I'm afraid, its
>> major problem is that it was about five years too late.

You're missing Frank's point here Michi because you're arguing from an
enterprise/general-purpose middleware perspective. Frank's point
(which is also my overall point) is that Lightweight CCM will become
THE technology for DRE systems. Right now, these systems are largely
based on VERY low-level technology (such as C, sockets, RTOS) - in
fact, many of these systems don't even have Middleware Dark Matter in
them! Since these systems need to live for very long periods of time,
its essential that they be based on standard technologies.

The emerging combination of QoS-enabled Lightweight CCM + model-based
software development, configuration, and deployment tools will provide
a major paradigm shift in the way that complex, long-lived DRE systems
are developed. There are already success stories in this domain (such
as the Boeing Bold Stroke middleware, which is being used in a wide
range of avionics mission computing product lines) and more are coming
online every year (JTRS is another good example, and I know that
Frank's been doing great work on this topic at MCS).

>> Frank, I think you are much more idealistic than I am.

Yes and no. My guess is that you don't have much exposure to the
types of domains that Frank and I are talking about, so it's not
surprising that you don't see how well the pieces of technology are
fitting together. But for those of us who work in this space
day-in/day-out it's really remarkable to see what am impact that the
Lightweight CCM spec (and its emerging implementations) are having.

Take care,

Douglas C. Schmidt

unread,

Jul 25, 2003, 2:52:38 PM7/25/03

Hi Frank,

>> However, you could also argue that bypassing the process and
>> publishing something on your own is the easy way out.

Bingo - that was Steve and my point, as well. While it's the easy way
out, this approach has a habit of not working well in the long-run
(unless you are one of a handful of giant companies). I've listed
examples of operating systems (e.g., Be-OS, NextStep/OpenStep, etc.)
that bypassed standards to no avail. There are also plenty of
middleware technologies in the same boat (e.g., Xshell, Inferno, RMI,
etc.).

I'm reminded of a classic quote by Winston Churchill, who once said
"Democracy is the worst form of government, except in comparison to
all the rest." I think the same thing tends to be true of standards.

Douglas C. Schmidt

unread,

Jul 25, 2003, 3:10:41 PM7/25/03

Hi Ruslan,

>> Yes. But I think that such list can be prepared for each
>> non-trivial technology with long lifetime.

Exactly. It would be interesting to see the list of things that need
to be fixed with, e.g., Linux, Windows, Solaris, .NET, J2EE, etc. I'm
sure the list is staggering!

>> Strange. I was involved in VisiBroker/TAO translation, of course we
>> touch source code of target system in many places, but in general
>> it was not very hard.

Right - as I was saying to Michi in my earlier post, this seems to be
the general consensus from the folks we've talked with who've done
this migration. I agree, however, that if you're using a very old
version of Visi or Orbix the translation is harder.

>> (Currently our cbroker compiles with 6 different ORB.)
>> We have one near 1 MLOC project, which can work with 3 ORB.

This is also something I'm hearing more and more recently. Michi, you
need to start coming to the OMG Real-time Middleware conferences again
;-)

>> Hmm. let's do mental experiment: imagine that some group receive
>> documentaion for protocol and language mapping and decide to write
>> own ICE implementation. I can guarantuee, than after this we will
>> needed in something like ice-conf ;)

Hahahhaha - isn't it funny how the Sun folks had the same hubris when
they first developed Java and decided to leave out the pre-processor
altogether since there would only ever be a "single" version with
"write-once, run-anywhere" semantics. The moment there was a second
version (not to mention implementations from different vendors) this
hubris was no longer warranted. In fact, at some point, Sun's dropped
that WORA marketing hype and refocused on other stuff. Unless ICE
*never* changes (and all glitches were fixed in the original relase)
and never has more than a single implementation then it'll be possible
to avoid having an ice-conf. Otherwise, I don't see how this could be
the case!

>> I hope that ICE will find good market segment, but not in
>> mainstream. For a pity, that it was possible to refactor CORBA,
>> but this was not to be done. Looks like 'design by commitee' fault.

Well, it may also have been an artifact of the political dynamics in
the OMG at certain points in time. As certain vendors lose dominance,
it may become easier for the remaining CORBA participants to do
something useful to fix these problems. But I wish that Michi hadn't
bailed out since his input was invaluable.

Marc Laukien

unread,

Jul 25, 2003, 5:10:44 PM7/25/03

Douglas C. Schmidt wrote:
> Hi Marc,
>
>
>>>It is very clear to me that CORBA is slowly dying.
>
>
> This is FUD - plain and simple, i.e., there's no proof, no citations,
> no evidence, just good ol' "fear, uncertainty, and doubt". Here's
> some counter-FUD: "Based on the meteoric rise in postings from users,
> web download, and sales of documentation and precompiled software
> kits, use of open-source CORBA is growing by leaps and bounds all
> around the world." BTW, there's actually evidence for this ;-)

First of all Doug, I'm free to voice my opinion, and don't have to prove
anything to you. My opinion is formed by talking to many people about
CORBA, by looking at quarterly balance sheets of leading CORBA
companies, and by looking at progress at the OMG, and by spending many
years in the CORBA industry. And yes, my opinion is also formed because
of my work on Ice, and what people tell me if they compare Ice with CORBA.

You simply call my opinion FUD because you don't like my opinion.

>
>>>But I see very little traction in the CORBA world anymore. Fact is,
>>>that there are much fewer dollars invested in CORBA than this used
>>>to be the case, both by vendors and customers. And not only due to
>>>the poor economy, no, CORBA had an overproportional rapid decline
>>>in the last years.
>
>
> Again, some counter-FUD: "The overall downturn in the global IT
> enconomy, which has dried up IT budgets and caused many IT
> platform/tool providers to fail, has led many companies (particularly
> telecom and aerospace/defense companies) to move towards open-source
> operating systems (such as Linx) and middleware (such as CORBA)
> solutions. Most telecom providers and aerospace/defense integrators
> are investing heavily in standards-based open-source OS/middleware
> solutions since they see it as a way to avoid catastrophe when small
> companies selling proprietary solutions disappear." There's also lots
> of evidence for this, as well.

You are mixing so many things into one statement that it's impossible to
have evidence for or against the overall statement.

I think the only part of your statement for which there is actually
evidence is that Linux is growing. Everything else is opinion, based on
your perception of the industry. My opinion and my perception differs.

>
>
>>>Some CORBA vendors even tried to downplay the fact that they are
>>>CORBA vendors.
>
>
> The fact that there are (or were) CEOs at certain companies that
> couldn't manage their way out of a wet paper bag should be an
> indictment of their (lack of) leadership skills and vision, rather
> than an indictment of the technology!!! Fortunately, other CORBA
> vendors are doing quite well, so the overall balance is positive.

If we are talking about the largest CORBA vendor, the "gorilla player in
the CORBA world", then I believe that this also says something about
how investors and analysts and customer perceive CORBA these days.

>
>
>>>And the OMG now focuses much more on MDA than on CORBA.
>
>
> Of course - that strategy makes a lot of sense since DOC middleware
> has largely been successful and there's a LOT more effort required to
> address the MDA-related challenges. I recommend you read the book
> "The Innovators Dilemma" by Clayton Christensen for good coverage of
> what happens when organizations spend too much time "looking at their
> backswing" rather than moving ahead to address next-generation
> challenges.

I read the book. But in my opinion you are making a big mistake here,
which so many other companies did.

The book basically says that sometimes you have to take a risk and
pursue an idea, even if it cannot be proven that the idea is really viable.

I fully agree with this in general. But to turn this around, and to
conclude that you should pursue every idea, no matter how far-fetched
and unrealistic it is, is wrong. Such a strategy has proven fatal to
many companies.

>
>>>Given this situation, I believe that Ice has a brilliant future.
>
>
> That belief doesn't surprise me at all ;-)
>
>
>>>I can tell you from the many companies that are currently
>>>evaluating Ice, or already building it in their next-generation
>>>product, that there is a lot of interest in a new, easy-to-learn,
>>>"technical middleware" platform. Of course, your opinion might
>>>differ, and ultimately only time will tell.
>
>
> No question there. The big question is "why the $%^#& are you posting
> this FUD and ICE marketing stuff on comp.object.corba"?!?!?!

Isn't it obvious? I want more people to check out Ice. Ice is an
alternative to CORBA, therefore comp.object.corba is the right
newsgroup. This group is not just for CORBA praise! I don't see anything
wrong with this.

Besides, the original post in this newsgroup was about new Ice
documentation being available for free download. Shouldn't something
like this be interesting for you as a professor in particular? After
all, we put a lot of work into this documentation, and it shows new
possibilities with Ice in distributed computing, and how they compare to
CORBA.

Is this marketing? If so, then you also shouldn't post information about
papars about TAO in this newsgroup either. But this would be a really
shame, because I always enjoyed reading your papers, and never called
them marketing.

-- Marc

Marc Laukien

unread,

Jul 25, 2003, 5:20:37 PM7/25/03

> Bingo - again this is particularly ironic coming from Michi, who IIRC
> was always beating up on ORB vendors/developers for "tooting their own
> horn" in comp.object.corba. My recommendation would be to start a
> comp.object.ice (or whatever) newsgroup and these discussions can
> continue ad nauseum in that forum!

Since Ice is positioned as an alternative to CORBA, comp.object.corba is
exactly the right newsgroup. Again, this is not only a group for praise,
but also to show alternatives. If somebody is not interested in
alternatives, they don't have to read what we've got to say.

There are also have a lot of ACE/TAO developers who are currently
looking into Ice as an alternative, therefore we also posted the
information about the documentation release in comp.soft-sys.ace. After
all, this is a pubic newsgroup, and we are free to post announcements
there, as long as they are related to the topic of the newsgroup.

-- Marc

Marc Laukien

unread,

Jul 25, 2003, 5:47:39 PM7/25/03

Douglas C. Schmidt wrote:
> Hi Mark,
>
>
>>>By the way, I agree with you that writing a good C++ mapping isn't
>>>so hard. This makes it even more confusing to me why there is no
>>>new C++ mapping for CORBA. The only answer I can think of is that
>>>neither the CORBA vendors nor the OMG care.
>
>
> Is there a reason why you just can't stay away from slinging FUD Marc?

FUD seems to be your favorite word lately. Whenever there is an opinion
you don't like, it's FUD to you.

> At any rate, in case you're actually interested in a rational
> technical discussion of these issues, please check out
>
> http://www.cs.wustl.edu/~schmidt/report-doc.html
>
> and read the three columns Steve and I wrote for the C/C++ Users
> Journal that explains the various forces involved here. LOTS of
> people (including the OMG and ORB vendors) would like a better
> mapping. As usual, it comes down to balancing various forces. IMHO,
> the "Right Thing"[TM] to do would be to start an initiative to get the
> major ORB vendors who care about this to develop their own alternative
> mapping, get it working in multiple mainstream ORBs, and then submit
> this to the OMG revision task force. The TAO group has talked with
> OIS about doing this, and if we ever get some spare cycles we'll work
> it out. If someone wants to sponsors this work, it'll get done
> faster.

I read all the stuff about the history, but this doesn't change the fact
that there is still only an arcane C++ mapping for CORBA. You can argue
about history all you want, fact is that no attempt to start a new C++
mapping to date ever succeeded.

Perhaps the TAO group and OIS finally make a new C++ mapping happen. If
so, then I will be the first one to congratulate you for your effort.

>
>
>>>Besides, Ice is not proprietary. It is available under the GPL. We
>>>only charge for licenses if somebody doesn't want to make their
>>>programs available under GPL-like terms. See
>>>http://www.zeroc.com/licensing.html
>
>
> I think you're mixing up your terminology here - probably
> intentionally. Here's the bottomline, Ice isn't based on any ratified
> standard, CORBA is. It's also not free of charge for the vast
> majority of organizations who want to develop software they aren't
> planning to give away in source-code form. At least Michi was honest,
> he said "we're in this to make $$$." I have no problem with that, but
> let's not play word games, ok?

Ice is GPL, and the pros and cons of GPL are well known. Furthermore, we
have documented Ice and the Ice protocol in detail, and do not prevent
anybody from implementing the protocol. There are no patents, no
restrictions on how somebody could use the Ice protocol or other parts
of the Ice specification. It might not be standards based, but I think
Ice qualifies as non-proprietary software because of the openness of its
specification and source code.

And yes, if you don't want to make your code available under GPL, you
have to buy a license from us (not for the specification, but for our
implementation). Our pricing is publicly available on our Web server, so
we don't make a secret out of this. And yes, we want to make a living
from selling Ice licenses and support.

If you are saying "at least Michi was honest", it implies that I was
dishonest in my statement. Is there really any need to make personal
insults? Did I do anything to you, other than having a different opinion?

-- Marc

Marc Laukien

unread,

Jul 26, 2003, 3:18:30 AM7/26/03

Douglas C. Schmidt wrote:
> [...]

> So here's a question for the ZeroC folks - if someone were to
> recommend the Ice C++ mapping as the C++ language mapping 2.0 for
> CORBA would that be consistent with the Ice/ZeroC license? Put
> another way, is Ice *really* that open?

As I already wrote in another posting, the answer is yes.

Note, however, that some parts of the mapping are not applicable to
CORBA. For example, Slice (the "specification language for Ice") has a
dictionary type, which IDL does not have. On the other hand, Slice got
rid of Anys or Unions.

-- Marc

apm

unread,

Jul 26, 2003, 6:29:13 AM7/26/03

Michi Henning <mi...@triodia.com> wrote in message news:<Pine.LNX.4.44.03072...@diadora.client.uq.net.au>...

> On 24 Jul 2003, Christopher Browne wrote:
>
> > If there were implementations out there for other languages (Perl?
> > Python? Lisp?), I'd be more interested; as it stands, CORBA still
> > supports a boatload more languages and environments.

How about an Eiffel mapping? There is no offical Eiffel mapping for
CORBA but there is an unoffical one currently owned by 2AB, inherited
from MICO/E. Perhaps that could be examined for inspiration. Maybe 2AB
would be interested?

-Andrew M.

david a. janello

unread,

Jul 26, 2003, 1:48:32 PM7/26/03

sch...@macarena.cs.wustl.edu (Douglas C. Schmidt) wrote in message news:<bfru2n$b...@macarena.cs.wustl.edu>...
> Hi Michi,

>
>
> The emerging combination of QoS-enabled Lightweight CCM + model-based
> software development, configuration, and deployment tools will provide
> a major paradigm shift in the way that complex, long-lived DRE systems

Hi Doug,

Is there anything in ICE worth ripping off and putting into TAO?

A couple of ideas seem interesting:

a) the data compressed IIOP streams, we could do a pluggable protocol
in TAO called CIOP for compressed IOP.
b) ditto for firewalls, we could have an FIOP pluggable protocol for
NAT and proxy firewalls.
c) a mapping to ISO C++, no need for new middleware here, we can
modify the IDL compiler to write translation utility methods between
CORBA and std datatypes and put these routines into a utils.h file.
Kind of like the -GI flag in TAO that generates default server code.
The utility functions could hide most if not all the memory management
ugliness of the current CORBA c++ mapping.

There might be a few others, I'll probably be posting some
implementations of these ideas in the near future.

I think that the idea of rewriting CORBA is misplaced. Since there is
an IDL to C++ binding, it is possible to modify almost any aspect of
the OMG spec by hacking the IDL compiler and/or writing pluggable
protocols. This approach allows users to define arbitrarily complex
modifications to the CORBA specification and preserves 100%
interoperability with other orbs by switching back to the standard
protocols.

--David Janello
Simulation and Searches, LLC
www.simulationandsearches.com
Argon Technology Group, Inc.
www.argon-tech.com

Michi Henning

unread,

Jul 26, 2003, 6:07:37 PM7/26/03

"apm" <ap...@student.open.ac.uk> wrote in message
news:d1a33011.03072...@posting.google.com...

>
> How about an Eiffel mapping? There is no offical Eiffel mapping for
> CORBA but there is an unoffical one currently owned by 2AB, inherited
> from MICO/E. Perhaps that could be examined for inspiration. Maybe 2AB
> would be interested?

It really all depends on customer demand. We'll do those things that
customers need the most first, rather than trying to be all things to all
people and spreading ourselves too thin. In terms of adding new
language mappings in general, it's not too hard to do that, provided
the language has a C/C++ call interface. Without that, it's harder because
it means to rewrite the whole run time in that language, which is quite a
bit of work. (BTW -- that's what we did for Ice for Java, because we
wanted a pure Java implementation, not one that depends on C or C++
run-time libraries.)

Steve Vinoski

unread,

Jul 27, 2003, 8:29:07 PM7/27/03

Marc Laukien <ma...@zeroc.com> wrote in message news:<JnSdnRalfNH...@speakeasy.net>...

> FUD seems to be your favorite word lately. Whenever there is an opinion
> you don't like, it's FUD to you.

I disagree, Marc. Doug's use of the acronym "FUD" is perfect for the
unfounded references you and Michi have made regarding the poor
technical quality and fading market strength of CORBA. Does CORBA have
technical problems? Sure! Name me a standard that doesn't! As for the
CORBA market, I've heard various "industry pundits" say it's weak,
it's strong, or it's dead -- take your pick. If you guys were still
selling CORBA, you'd both be posting about how great it is and
defending it, as my "quotes" posting proved. The fact that you guys
can't seem to admit that is amusing at best, misleading at worst, and
perhaps even delusional.

> I read all the stuff about the history, but this doesn't change the fact
> that there is still only an arcane C++ mapping for CORBA. You can argue
> about history all you want, fact is that no attempt to start a new C++
> mapping to date ever succeeded.

You just have to love developer hubris.

One of the things I find amusing about this thread is the implication
that somehow CORBA lives and dies by its C++ mapping. Technical people
often make the mistake of thinking that technical details actually
matter! CORBA did not succeed because it was the best technical thing
going. Rather, it succeeded due to superior marketing and superior
mindshare, both on the part of the OMG and the many vendors that
support CORBA. If the C++ mapping is as bad as Michi's exaggerations
have claimed it to be, then why didn't CORBA die in 1995 or 1996? In
other words, it's a business thing, not a technical thing. That's why
no C++ mapping has succeeded the existing one -- one hasn't had to!
Much as we might like to think differently, in the whole scheme of
things we developers and our technical perspective have actually had
very little to do with CORBA's success.

Another way to put it is that the C++ mapping could have been 10 times
worse and it wouldn't have mattered. It could have been 10 times
better, and that wouldn't have mattered either. Get over it. From a
business perspective -- and business totally governs how, why, and
when technologies live and die -- your claims about having developed a
superior C++ mapping for Ice don't matter at all. Not at all.

--steve

Bruce Fountain

unread,

Jul 28, 2003, 2:03:11 AM7/28/03

vin...@ieee.org (Steve Vinoski) wrote in message news:<6c2690b5.03072...@posting.google.com>...

>
> You just have to love developer hubris.
>

Indeed. Laziness, Impatience and Hubris: the three essential
traits of a great software engineer (apologies to Larry Wall). Where
would we be without them?

> Another way to put it is that the C++ mapping could have been 10 times
> worse and it wouldn't have mattered. It could have been 10 times
> better, and that wouldn't have mattered either. Get over it. From a
> business perspective -- and business totally governs how, why, and
> when technologies live and die -- your claims about having developed a
> superior C++ mapping for Ice don't matter at all. Not at all.

In a previous job, we built a traffic control system (now a
flagship product of the company) around CORBA. Because it was a
standard protocol? Because it was mature technology? Because there
were multiple vendors available? Because it had a great C++ mapping?

These are all good reasons (except perhaps the last), but the
reason we used CORBA was that I had used it before and I reckoned
it was pretty neat. I think you might be surprised how often this
happens.

Bruce Fountain

Gopi Bulusu

unread,

Jul 28, 2003, 5:14:59 AM7/28/03

"Michi Henning" <mi...@triodia.com> wrote in message news:<PiaUa.14272$OM3....@news-server.bigpond.net.au>...

> "Gopi Bulusu" <go...@sankhya.com> wrote in message
> news:2d87f439.03072...@posting.google.com...
> > "Michi Henning" <mi...@triodia.com> wrote in message
> news:<k2aTa.8550$OM3....@news-server.bigpond.net.au>...
> > >
> > > Well, the CORBA C++ mapping and the ISO C++ specification
> > > effort proceeded concurrently.
> >
> > Correct, and that makes CORBA C++ mapping predate ISO C++. Because the
> > C++ mapping depends on the C++ language and not the other way round.
>
> Sorry, but I'm confused. So the C++ mapping predates ISO
> C++ because the C++ mapping depends on C++? I'm afraid
> I don't follow. As far as I know, the C++ mapping didn't have

Well, when one writes a spec (like CORBA C++ mapping) that depends
on other specs x y z, you have to use a standard version of x y z.
Since CORBA C++ mapping depends on C++ standard, naturally the CORBA
C++ mapping predates the ISO C++. Btw, I don't see how this thread
contributes to CORBA/C++ mapping in any way.

> any influence on ISO C++, and ISO C++ had no influence
> on the C++ mapping. Also, the ISO C++ mapping both pre-dates
> and post-dates the CORBA C++ mapping: the ISO C++ specification
> effort was started before the CORBA C++ mapping, and the final ISO C++
> specification was published in 1998, after the CORBA C++ mapping
> was published. So, I'm sorry, but I can't see the link -- can you explain?
>
> > Almost all major C++ application patterns had their influence on the
> > C++ standardization effort. CORBA was certainly a major pattern.
>
> Hmmm... I don't see anything that particularly patterned in CORBA,
> either in the C++ mapping or in CORBA in general. So, I don't
> understand how CORBA influenced ISO C++ (other than in the
> very general sense of being one of the many areas of computing that
> use C++).

Your "other than" pretty much sums up what I said earlier.

> > > easy to get right, period. But CORBA does its share to make it even
> > > harder at times, and unnecessarily so.)
> >
> > Looks like everything you say above supports my argument :-) CORBA
> > makes
> > it easy to build simple systems (as you agree) and makes it easier to
> > build
> > more complex systems -- which can't be done at all without an accepted
> > interoperable standard like CORBA.
>
> Can't it? Why is it necessary to have a standard to build complex distributed
> systems? People built complex distributed systems a long time before there
> ever was a standard. As far as I can see, the standard doesn't do much to
> help people get on top of complexity. Rather, a standard is meant to provide
> cross-vendor interoperability, source code portability, and a well-known
> API. But I honestly don't see how a standard would help me to build
> complex systems more easily. (I mean, it's not as if the standard would
> make the inherent complexity go away, is it?)

Think about it, could we all have discussed this topic with as much
ease if we were both not using English (or French or Telugu, whichever
happens to be our
favorite spec :-)

Standards do reduce complexity. They reduce complexity by cutting down
on the solution space available -- by reducing the number of options
available to put together a solution. In fact, many AI Planning
Experts agree that humans deal with complexity by reducing the number
of options, standardizing on what they do and how they do it, rather
than by coming up with the best plan for solving every problem.

Marc Laukien

unread,

Jul 28, 2003, 5:19:26 AM7/28/03

Steve Vinoski wrote:
> One of the things I find amusing about this thread is the implication
> that somehow CORBA lives and dies by its C++ mapping.

Actually, I agree with you on this one. The C++ mapping is only one of
many things that makes Ice different from CORBA. I'm not happy at all
that this discussion seems to focus on a single detail, namely the C++
mapping. This gives the reader the impression that Ice is basically
CORBA plus a better C++ mapping, which it definitely is not.

-- Marc

Michi Henning

unread,

Jul 28, 2003, 6:38:32 AM7/28/03

"Douglas C. Schmidt" <sch...@macarena.cs.wustl.edu> wrote in message
news:bfrsvv$b...@macarena.cs.wustl.edu...

> Hi Mark,
>
> >> By the way, I agree with you that writing a good C++ mapping isn't
> >> so hard. This makes it even more confusing to me why there is no
> >> new C++ mapping for CORBA. The only answer I can think of is that
> >> neither the CORBA vendors nor the OMG care.
>
> Is there a reason why you just can't stay away from slinging FUD Marc?

I really don't see the FUD here. I think it's a legitimate question.
Why is it that there isn't a better C+ mapping for CORBA?
We tried you know, and were told to go away.

> As usual, it comes down to balancing various forces. IMHO,
> the "Right Thing"[TM] to do would be to start an initiative to get the
> major ORB vendors who care about this to develop their own alternative
> mapping, get it working in multiple mainstream ORBs, and then submit
> this to the OMG revision task force. The TAO group has talked with
> OIS about doing this, and if we ever get some spare cycles we'll work
> it out. If someone wants to sponsors this work, it'll get done
> faster.

Hmmm... The most optimistic estimate I can come up with for getting
a new OMG-approved C++ mapping done is 12 months (and I think
that I'm being *really* optimistic here). Then add the time it takes
vendors to implement the final version and bring it to market, and add
the time it takes for customers to switch to the new mapping and get
over the learning curve. That will take some time too.

What I find interesting in this thread is that I have raised quite a few
points of criticism about CORBA, but the only one that is discussed
is the C++ mapping. And, instead of discussing what's good and bad
about a particular thing, I hear "Michi, you are exaggerating, it isn't as
bad as you make it sound." I guess that's one way to avoid addressing
the specific points of criticism.

One advantage Ice has over a standard such as CORBA is that we have
a level of freedom and agility that CORBA can only dream of.
Ice isn't burdened by a standards process and historical mistakes, which
makes it comparatively easy to excel technically because we are free to
apply the lessons of the past. CORBA simply can't do that -- that's the
price of standardization. What surprises me though is how strongly
you and Steve react to Ice. We've gone and done something new that,
in our opinion, is better and more elegant than CORBA. So what?
I would have thought that you'd appreciate it if someone advanced the
state of the art another notch or two.

Michi Henning

unread,

Jul 28, 2003, 7:11:54 AM7/28/03

"Douglas C. Schmidt" <sch...@macarena.cs.wustl.edu> wrote in message

news:bfrse9$b...@macarena.cs.wustl.edu...

> >> Can't it? Why is it necessary to have a standard to build complex
> >> distributed systems?
>
> I find it strange that you would even ask this question Michi. Pretty
> much by definition, "complex distributed systems" tend to live a long
> time - usually MUCH longer than the "attention span" of COTS providers
> who basis their technologies on non-standard
> tools/platforms/services/etc.

Hmmm. There are a lot of interesting issues coming up here. One is the
life time of distributed systems. That's an interesting one in itself. What
*is*
the average life time of software, and what does the distribution curve look
like? I know that we have the full gamut of life time from days (as in the
financial world,
where a lot of financial modelling programs are written with a life expentance
of less than week), to to years (as for air traffic control system, which tend
to live
for decades). I have to admit that I've never thought much about this -- I
honestly don't know what the distribution curve would look like, or how
skewed it would be. (Bi-modal or even try-modal maybe?) I know that a lot
of software I have written myself was out of date after maybe three or four
years.
But that's simply because I tend to work at the systems level, and I often
write
tools to make up for some deficiency or lack of functionaly in some software
that I'm using. Quite often, the tool I wrote becomes obsolete when the
software
I wrote it for now offers the functionality of the tool, of the software I
wrote the
tool for no longer exists (or I stop using it). Anyway, I digress...

It's interesting to think about the benefits of standardization though. There
are
several I can see off-hand:

- A standard makes it more likely that I'll be able to hire people with the
skill
I need.

- A standard makes it more likely that the people I hire will understand each
other.

- A standard makes it more likely that I'll be able to switch software, or
hardware,
or vendor, or whatever.

- A standard makes it more likely that I'll be able to find literature,
training courses,
etc.

To extent of the above points, the standard helps to reduce complexity. (It's
less
complex to not have to train a new engineer than to have to train him.) But I'm
not
aware of how standards would reduce complexity of the actual application. The
problem I want to solve doesn't get magically simpler because there is
standard,
I would think.

> >> People built complex distributed systems a long time before there
> >> ever was a standard.
>
> Sure, and these systems have INEVITABLY become albatrosses around the
> necks of the companies that have to maintain them over a long period
> of time. Some major telecom equipment providers have been virtually
> crippled by the total ownership costs of maintaining their
> cathedral-like switching systems based on proprietary technologies.

Yes and no. I agree that people who use ancient software suffer from
the cost of maintaining that software. The question is how much standards
actually help with that. When you are talking twenty years plus, it seems
that a lot of standards disappear before the software gets a chance to
get as old as that, meaning that, by the end of that period, it seems
irrelevant whether the software was built on what once was a standard.
More relevant seems to be whether, at the time I need maintenance for
my software, whether there is still an active and interested community
around the technology. If so, I'll get my maintenance done; if not, I'll
have a hard time. So, the more relevant criterion seems to be whether
the technology is "alive" as opposed to whether it is standardized.

> >> As far as I can see, the standard doesn't do much to help people
> >> get on top of complexity.
>
> Quite frankly Michi, if you don't see this, you need to spend more
> time working with people building long-lived, complex distributed
> systems!

See above. The complexity of the application domain doesn't disappear
by magic. So, the complexity of the application I want to build is not
reduced by the standard I think. The standard does make it more
likely though I might find people with experience in that space, or
that I might find tools to help me out somehow. So, yes, to that extent,
complexity is reduced. But that isn't reducing the complexity of the
application itself, is it?

> There's now a lot of empirical evidence (i.e., gathered from
> detailed cost/schedule/quality metrics collected over many years) from
> companies like Boeing, Siemens, Raytheon, SAIC, LMCO, etc. that
> illustrates the lifecycle cost savings of developing these types of
> systems using standards-based approaches.

I'm a little bit skeptical. Not that I doubt that these companies haven't
done the studies or shown that they saved money -- I'm sure that they
have. On the other hand, we've been pushing standardization for so
long that we sometimes accept it as a mantra without looking as closely
as we should. For example, I have also seen studies that showed the
tremendous cost savings and quality improvements that companies
experienced when they switched from UNIX to Windows, or from
sendmail to Exchange. I'm sure you'd have no problem finding lots
of people who'd laugh at that :-)

> >> Rather, a standard is meant to provide cross-vendor
> >> interoperability, source code portability, and a well-known
> >> API. But I honestly don't see how a standard would help me to build
> >> complex systems more easily. (I mean, it's not as if the standard
> >> would make the inherent complexity go away, is it?)
>
> I disagree here again Michi. In fact, if you look at MATURE IT
> industries (e.g., micro-processor manufacturers and the IP equipment
> provider market) you'll see that the use of standards is ESSENTIAL to
> obtaining the economies of scale necessary to focus their R&D
> activities on actually resolving the inherent complexities, rather
> than wasting time rearranging the accidental complexities (which
> ultimately end up being like rearranging deck chairs on the Titanic).

Hmmm... Yes. Clearly, things like a standardized fitting for light bulbs
makes everyone's life easier. The more wide-spread the standard, the
more useful it is, as a rule. And the better the standard works, the more
useful too. I guess that's where I'm having problems with CORBA. It's
a standard, no doubt, but it isn't as good a standard as it should be, not
by a long shot. We know how to do this sort of thing better now, just as
we did when we started CORBA, and DCE started to fade (and DCE
was a standard too).

> Having said that, of course, standards are no panacea. However, the
> LACK of standards in the middleware domain is SERIOUSLY hurting the
> competitiveness of the world IT distributed systems market.

I think that lack of a good standard definitely hurts the market. I'm not
so sure about lack of poor one though :-)

Michi Henning

unread,

Jul 28, 2003, 7:20:59 AM7/28/03

"Douglas C. Schmidt" <sch...@macarena.cs.wustl.edu> wrote in message

news:bfrre8$b...@macarena.cs.wustl.edu...

> >>
> >> Some CORBA vendors even tried to downplay the fact that they are
> >> CORBA vendors.
>
> The fact that there are (or were) CEOs at certain companies that
> couldn't manage their way out of a wet paper bag should be an
> indictment of their (lack of) leadership skills and vision, rather
> than an indictment of the technology!!! Fortunately, other CORBA
> vendors are doing quite well, so the overall balance is positive.

I thought it was the standard that mattered, not the technology? Haven't
you been arguing all along that the problems I quoted with CORBA
don't matter, and that CORBA is standard is what matters? As I said
in another post, the usefulness of a standard depends a lot on how
popular it is, how many people are using it, and how many vendors
there are. I've seen quite a few CORBA vendors disappear over the past
three years or so and, for public companies that sell CORBA, the revenue
figures are declining, according to their quarterly reports. (Small wonder,
with half the world chasing the next silver bullet in form of web services...)
That in itself worries me. I remember five years ago, there was something
new and exciting happening with CORBA all the time. Now, it seems
to be comparatively quiet. (Just look at the traffic in this news group. There
was a *lot* more a few years ago.)

> >> And the OMG now focuses much more on MDA than on CORBA.
>
> Of course - that strategy makes a lot of sense since DOC middleware
> has largely been successful and there's a LOT more effort required to
> address the MDA-related challenges.

Forgive me for being skeptical, but I think it will be quite a long time before
computing advances sufficiently to make something like MDA real. The idea
of platform- and architecture-independent modeling isn't new. In essence, it's
just the old dream of capturing the essence of semantics and then mapping
the semantics onto specific platforms. The problem with this is that, to deal
with the complexity, we raise the level of abstraction and model at a higher
abstraction level. But, to do that, by necessity, we have throw detail away
(otherwise we wouldn't be raising the level of abstraction). But it's all the
detail that ends up killing the attempt to then map down to a specific
platform.
(If we retain all the detail, the modeling gets bogged down, if we throw away
the detail. the modeling works, but we don't have the detail anymore when we
need it, namely, when it comes time to deal with the specifics of a platform.)

I'm afraid that these problems are in the nature of the beast and that no
amount
of modeling will ever make them go away.

Michi Henning

unread,

Jul 28, 2003, 7:24:03 AM7/28/03

"Douglas C. Schmidt" <sch...@macarena.cs.wustl.edu> wrote in message

news:bfru9m$b...@macarena.cs.wustl.edu...

> >> However, you could also argue that bypassing the process and
> >> publishing something on your own is the easy way out.
>
> Bingo - that was Steve and my point, as well. While it's the easy way
> out, this approach has a habit of not working well in the long-run
> (unless you are one of a handful of giant companies). I've listed
> examples of operating systems (e.g., Be-OS, NextStep/OpenStep, etc.)
> that bypassed standards to no avail. There are also plenty of
> middleware technologies in the same boat (e.g., Xshell, Inferno, RMI,
> etc.).

Yep, no doubt, there are plenty of non-standard attempts that have failed.
There are also plenty of standard attempts that have failed. I think we can
each pick the cases to suit our purpose. There are plenty of non-standard
things that have succeeded too.

I guess the conclusion has to be that something being standard or
non-standard is neither a necessary nor a sufficient prerequisite for
success.

Michi Henning

unread,

Jul 28, 2003, 7:48:23 AM7/28/03

"Steve Vinoski" <vin...@ieee.org> wrote in message
news:6c2690b5.03072...@posting.google.com...

> If you guys were still
> selling CORBA, you'd both be posting about how great it is and
> defending it, as my "quotes" posting proved. The fact that you guys
> can't seem to admit that is amusing at best, misleading at worst, and
> perhaps even delusional.

What surprises me is that you seem to think that the ZeroC team would
just go and build something that is no better than CORBA. Ice was built
by people who have a lot of experience in this domain, and with a proven
track record. (We previously built ORBacus, which most people seemed
to think was a very good ORB.) If we'd just gone and built something
no better than CORBA, we'd have to be very naive indeed.

> One of the things I find amusing about this thread is the implication
> that somehow CORBA lives and dies by its C++ mapping. Technical people
> often make the mistake of thinking that technical details actually
> matter!

Long term, I think they actually do. Short term, not so much, because
market forces, fads, fashions, politics, etc carry a lot of weight. But
it doesn't matter how much people hype up a technology: if it doesn't
deliver, technical reality will set in eventually.

> CORBA did not succeed because it was the best technical thing
> going.

I would disagree with that. It succeeded because it was the best thing
going at the time. (Just like troff in its day.) If I didn't use CORBA,
I couldn't build a heterogenous distributed system at all. So, I used
the only tool available for the job at the time.

> Rather, it succeeded due to superior marketing and superior
> mindshare, both on the part of the OMG and the many vendors that
> support CORBA.

Mindshare certainly had a lot to do with too, yes. The mindshare is
slipping badly though, and has been for over two years. The web
services crowd seem to be getting it all these days... (Pity really --
I've rarely seen something more lacking in technical excellence...)

> If the C++ mapping is as bad as Michi's exaggerations
> have claimed it to be, then why didn't CORBA die in 1995 or 1996?

Like I said: it was the only thing that could do the job. When I have
the choice between using a complex tool to get something done, or
not getting it done at all, I put up with the complex tool. That doesn't
mean that I love the tool...

> In other words, it's a business thing, not a technical thing. That's why
> no C++ mapping has succeeded the existing one -- one hasn't had to!

Pity though that it's still hanging around, with no update in sight.

> Another way to put it is that the C++ mapping could have been 10 times
> worse and it wouldn't have mattered.

No. If it were ten times worse, no-one could use it.

> It could have been 10 times
> better, and that wouldn't have mattered either.

No. If it were ten times better, a significant hurdle to understanding and
programming with CORBA in C++ would be removed and a lot of
people who decided that "CORBA is too complex" would still be
using it.

Language mappings probably have more influence on developer perception
than any other part of a platform. That's because the APIs are the main and
most important human-machine interface for a developer. Give the developer
a complex API, and he/she won't like it. Give him/her a nice and easy API,
and he/she will like the platform as a result.

Douglas C. Schmidt

unread,

Jul 28, 2003, 8:34:21 AM7/28/03

Hi Michi,

>> > >> By the way, I agree with you that writing a good C++ mapping isn't
>> > >> so hard. This makes it even more confusing to me why there is no
>> > >> new C++ mapping for CORBA. The only answer I can think of is that
>> > >> neither the CORBA vendors nor the OMG care.
>> >
>> > Is there a reason why you just can't stay away from slinging FUD Marc?
>>
>> I really don't see the FUD here. I think it's a legitimate question.

The reason that it's FUD is because it's NOT stated as a question at
all - it's a statement that's basically in the same league as "I've
heard rumors you've stopped beating your wife." There are CORBA
vendors who DO care about the C++ mapping, and there are people in the
OMG who care as well (improving the C++ mapping was one of the major
topics at the OMG Real-time Middleware workshop a couple of weeks
ago). As Steve pointed out in his reply, however, there are other
forces at work (largely business forces) that perpetuate the status
quo. I don't think this is a "good thing," BTW, but I think that Marc
is simply spewing FUD by claiming that no one "cares." Here's an
example of a non-FUD perspective on this:

. "In our experience trying to improve the C++ mapping, there was
resistence from key vendors in accepting our suggested
improvements."

I suspect that statement is factually correct, whereas Marc's claim that

. "The only answer I can think of is that neither the CORBA vendors nor
the OMG care."

is just plain FUD since it implies a grand conspiracy on the part of
CORBa and OMG to perpetuate an inadequate mapping, which is NOT
factually correct and is stated this way just to score marketing
points.

>> Hmmm... The most optimistic estimate I can come up with for getting
>> a new OMG-approved C++ mapping done is 12 months (and I think that
>> I'm being *really* optimistic here). Then add the time it takes
>> vendors to implement the final version and bring it to market, and
>> add the time it takes for customers to switch to the new mapping
>> and get over the learning curve. That will take some time too.

Sure - but the end result will be a *standard* mapping that will be
available from multiple vendors over a very long period of time. This
is precisely the benefit of a standard, i.e., it may take longer but
it will also last longer (assuming it solves business needs). When
you consider that people are developing applications that live for
decades, the fact that the mapping took 12 months or so to be improved
is really in the noise!

>> Ice isn't burdened by a standards process and historical mistakes,
>> which makes it comparatively easy to excel technically because we
>> are free to apply the lessons of the past.

Again, as Steve and I and others have pointed out, it's pretty easy to
improve stuff technically if you're not constrained by key forces that
are necessarily for technology to remain viable over the long-term.
Microsoft has used this as a rationale to modify their distributed
computing technologies every 2-3 years for more than a decade. I can
remember you criticizing this strategy MANY times during various
discussions over the years, yet now you embrace it - how ironic!

>> CORBA simply can't do that -- that's the price of standardization.

Exactly - and as you yourself have argued for many years (until
recently), there are also many benefits that accrue from having a
standard.

>> What surprises me though is how strongly you and Steve react to
>> Ice.

Actually, I don't have any negative reactions to *Ice* - I think it
sounds cool. My negative reactions are to the way that you and Marc
are spewing FUD and making a number of unsubstantiated claims (e.g.,
about Ice's performance), which is really unbecoming of both of you
and shouldn't be necessary in order to promote Ice.

In your case Michi, I'm also disappointed in the way that you've
"changed your stripes" and gone from being a person who harshly
criticized CORBA vendors in the past for using comp.object.corba as an
advertising venue to turning this forum into an "Ice promo." While
it's certainly your right and privilege to do this, it just strikes me
as being rather hypocritical. I have no such complains about Marc -
he never beat up people for doing this in the first place, so he's not
being inconsistent.

>> We've gone and done something new that, in our opinion, is better
>> and more elegant than CORBA. So what? I would have thought that
>> you'd appreciate it if someone advanced the state of the art
>> another notch or two.

There's certainly nothing wrong with advancing the state of the art -
that's the whole point of R&D. I'm largely just criticizing your
methods here, not your motives.

Doug

Marc Laukien

unread,

Jul 28, 2003, 9:22:18 AM7/28/03

Douglas C. Schmidt wrote:
> The reason that it's FUD is because it's NOT stated as a question at
> all - it's a statement that's basically in the same league as "I've
> heard rumors you've stopped beating your wife." There are CORBA
> vendors who DO care about the C++ mapping, and there are people in the
> OMG who care as well (improving the C++ mapping was one of the major
> topics at the OMG Real-time Middleware workshop a couple of weeks
> ago). As Steve pointed out in his reply, however, there are other
> forces at work (largely business forces) that perpetuate the status
> quo. I don't think this is a "good thing," BTW, but I think that Marc
> is simply spewing FUD by claiming that no one "cares." Here's an
> example of a non-FUD perspective on this:
>
> . "In our experience trying to improve the C++ mapping, there was
> resistence from key vendors in accepting our suggested
> improvements."
>
> I suspect that statement is factually correct, whereas Marc's claim that
>
> . "The only answer I can think of is that neither the CORBA vendors nor
> the OMG care."
>
> is just plain FUD since it implies a grand conspiracy on the part of
> CORBa and OMG to perpetuate an inadequate mapping, which is NOT
> factually correct and is stated this way just to score marketing
> points.

This is getting really silly. Are you now the authority for which
wording somebody has to use to express an opinion, in order for the
opinion not to be labelled as FUD? Also, is it possible to get at some
point beyond the debate about what you consider FUD and what not?

>
> Actually, I don't have any negative reactions to *Ice* - I think it
> sounds cool. My negative reactions are to the way that you and Marc
> are spewing FUD and making a number of unsubstantiated claims (e.g.,
> about Ice's performance), which is really unbecoming of both of you
> and shouldn't be necessary in order to promote Ice.

Michi made claims about *efficiency*. You completely ignored my recent
posting in which I explained why we believe that Ice is more efficient
than CORBA. For example, the much more compact data encoding, or the
faster message forwarding.

If efficiency only means latency and throughput to you, then I also
pointed out several times that certain real-time CORBA ORBs are better
in this respect. (But we are working on that, too.)

So to say that we are spreading FUD, because our claims are
unsubtantiated, while at the same time ignoring the technical detail we
provide to explain our claims, is quite unprofessional.

-- Marc

Douglas C. Schmidt

unread,

Jul 28, 2003, 9:40:28 AM7/28/03

Hi Marc,

>> This is getting really silly. Are you now the authority for which
>> wording somebody has to use to express an opinion, in order for the
>> opinion not to be labelled as FUD?

Nope - I just call 'em as I see 'em.

>> Also, is it possible to get at some point beyond the debate about
>> what you consider FUD and what not?

As I said earlier, if you stick to technical arguments rather than FUD
I won't complain.

>> Michi made claims about *efficiency*. You completely ignored my
>> recent posting in which I explained why we believe that Ice is more
>> efficient than CORBA. For example, the much more compact data
>> encoding, or the faster message forwarding.

And as usual, the "proof" is in the pudding, i.e., we need to get some
objective benchmarks to determine whether these claims hold up in
practice. Moreover, given that many CORBA ORBs have pluggable
protocol frameworks, it's straightforward to enable an ORB to achieve
the same benefits as Ice here (especially if interoperability isn't
important). Thus, I don't think this is a particularly relevant
differentiator (particularly now that CORBA has an extensible
transport framework).

>> If efficiency only means latency and throughput to you, then I also
>> pointed out several times that certain real-time CORBA ORBs are
>> better in this respect. (But we are working on that, too.)

Ok - that sounds like a good technical discussion. Let's see how
things stack up once Gautam's back on line. He did some preliminary
measurements late last week that showed Ice was about twice as slow as
ORBexpress for data types like structs and sequences. We hope to get
more definitive measurements shortly with a broader range of ORBs and
data types, at which point we can have a detailed TECHNICAL
discussion, as opposed to marketing fluff.

Take care,

Doug

Marc Laukien

unread,

Jul 28, 2003, 10:31:04 AM7/28/03

Douglas C. Schmidt wrote:
> Hi Marc,
>
>
>>>This is getting really silly. Are you now the authority for which
>>>wording somebody has to use to express an opinion, in order for the
>>>opinion not to be labelled as FUD?
>
>
> Nope - I just call 'em as I see 'em.

Then you should look more carefully.

>
>
>>>Also, is it possible to get at some point beyond the debate about
>>>what you consider FUD and what not?
>
>
> As I said earlier, if you stick to technical arguments rather than FUD
> I won't complain.

We gave you many technical arguments, some of which you conveniently
ignored.

>
>
>>>Michi made claims about *efficiency*. You completely ignored my
>>>recent posting in which I explained why we believe that Ice is more
>>>efficient than CORBA. For example, the much more compact data
>>>encoding, or the faster message forwarding.
>
>
> And as usual, the "proof" is in the pudding, i.e., we need to get some
> objective benchmarks to determine whether these claims hold up in
> practice. Moreover, given that many CORBA ORBs have pluggable
> protocol frameworks, it's straightforward to enable an ORB to achieve
> the same benefits as Ice here (especially if interoperability isn't
> important). Thus, I don't think this is a particularly relevant
> differentiator (particularly now that CORBA has an extensible
> transport framework).

The proof is in the math. You can simply calculate the message sizes.

>
>>>If efficiency only means latency and throughput to you, then I also
>>>pointed out several times that certain real-time CORBA ORBs are
>>>better in this respect. (But we are working on that, too.)
>
>
> Ok - that sounds like a good technical discussion. Let's see how
> things stack up once Gautam's back on line. He did some preliminary
> measurements late last week that showed Ice was about twice as slow as
> ORBexpress for data types like structs and sequences. We hope to get
> more definitive measurements shortly with a broader range of ORBs and
> data types, at which point we can have a detailed TECHNICAL
> discussion, as opposed to marketing fluff.

Are you actually reading what I write, or do you just respond to further
attack Ice? This is now the 3rd time I told you that ORBexpress has
better latency and throughput than Ice. Why do you insist on proving
something which I already stated as being correct?

-- Marc

Mogens Hansen

unread,

Jul 28, 2003, 10:37:05 AM7/28/03

"Douglas C. Schmidt" <sch...@macarena.cs.wustl.edu> wrote in message

news:<bfrpkn$b...@macarena.cs.wustl.edu>...

> > How about we talk about this at JAOO? Steve Vinoski, Doug Lea,
> > Bjarne Stroustrup, and Jim Coplien will all be there too. Should
> > make for a lively evening over a few beers :-)
>
> Sounds like a great plan! Now, all we need to do is invite Com Box
> and we'll REALLY have a row!

Early june (before this thread started) I asked the organizers of JAOO
to arrange for a discussion of "CORBA vs. ICE - complexity and future",
because Douglas C. Schmidt, Michi Henning og Steve Vinosky would be
present.
They were positive, and it seems like you guys would be positive as well.
I hope for a Goldfish Bowl.

The topics are basicly what has been discussed in this thread, and it
would be very interesting to have a discussion for those who come to JAOO.

I didn't realize that the other people mentioned here where relevant in such
a discussion - but of course they are.

Some of the discussion is very similar to C++ vs. ????, like:
* Is C++ to complex to be usefull (if the claim is repeated often enough,
some people might even believe that it's more complex than it actually is) ?
* Is the C++ standardization process usefull if it is not perfect ?
* Has the C++ Standard done any good, since most compiler vendors
doesn't implementent it 100 % (only very close to 100%) now 5-6 years
after the Standard was completed ?
* Wouldn't it be better to replace C++ by some simpler, proprietary
programming language (it can always be extended later on :-) ) ?

I would expect (I don't _know_ for a fact) that Frank Bushmann, who will
also come to JAOO, has some interesting experience from Siemens, on how
hard it actually is to use CORBA, how hard it actually to switch between
CORBA implementation, how important standards like CORBA are for project
that he knows in the real world.

Kind regards

Mogens Hansen

Douglas C. Schmidt

unread,

Jul 28, 2003, 10:52:31 AM7/28/03

Hi Marc,

>> We gave you many technical arguments, some of which you
>> conveniently ignored.

In general, if I ignore something it's either because I agree with
you, don't know enough about a particular topic to argue one way or
the other, or because the point is not worth arguing.

>> > And as usual, the "proof" is in the pudding, i.e., we need to get some
>> > objective benchmarks to determine whether these claims hold up in
>> > practice. Moreover, given that many CORBA ORBs have pluggable
>> > protocol frameworks, it's straightforward to enable an ORB to achieve
>> > the same benefits as Ice here (especially if interoperability isn't
>> > important). Thus, I don't think this is a particularly relevant
>> > differentiator (particularly now that CORBA has an extensible
>> > transport framework).
>>
>> The proof is in the math. You can simply calculate the message sizes.

Unfortunately, I do systems R&D, not theory. Thus, as I mentioned
above, the key questions are:

. Do the differences in the message size actually make a difference
empirically, and if so, under what conditions. We've done all sorts
of experiements with TAO over the years shaving off various amounts of
bytes in the GIOP headers and we've found that in many cases it doesn't
make much difference at all since that's not where the bottleneck is.
There are published papers on this at

http://www.cs.wustl.edu/~schmidt/ACE_wrappers/TAO/docs/pluggable_protocols/

for empirical results.

. Is there something inherent to what Ice does vs. what a CORBA
implementation can do using either the ETF and/or its own
proprietary messaging format (while still preserving the standard
CORBA programming API). As David Janello pointed out in a recent
post, a lot of the stuff you're doing in Ice can be (or already has
been) integrated into CORBA, thereby providing a standards-based
programming API with a custom implementation.

>> Are you actually reading what I write, or do you just respond to
>> further attack Ice?

Whew, you and Michi are sure defensive about Ice! As I mentioned to
Michi, I'm not objecting to Ice per se, I'm objecting to your
marketing tactics, which are often (though by no means always) heavily
based on FUD. When you don't use FUD, I don't object (as much).

>> This is now the 3rd time I told you that ORBexpress has better
>> latency and throughput than Ice. Why do you insist on proving
>> something which I already stated as being correct?

When you calm down, please go back and read my original posting more

carefully. Here's what it said:

>> > Ok - that sounds like a good technical discussion. Let's see how
>> > things stack up once Gautam's back on line. He did some preliminary
>> > measurements late last week that showed Ice was about twice as slow as
>> > ORBexpress for data types like structs and sequences. We hope to get
>> > more definitive measurements shortly with a broader range of ORBs and

^^^^^^^^^^^^^^^^^^^^^
In other words, we need to empirically validate whether your claims
that only so-called "Real-time ORBs" are faster than Ice. If
general-purpose ORBs are also faster, it calls into question a lot of
the stuff you guys were claiming initially about the "inherent"
inefficiency of CORBA.

Matthew Newhook

unread,

Jul 28, 2003, 10:56:24 AM7/28/03

Doug, I think its very disappointing to see someone that I highly
respect resort to personal attacks on Michi in an attempt to prove your
argument.

I find it amazing to hear you claim that the OMG isn't losing momemtum.
It was very clear to me after a few years of regularly attending the
OMG meetings that the interest was seriously waning. Historically I
find this similar to DCE. An open standard which was cool for a while,
but interest waned and many of the contributors moved onto CORBA. Now
when I look at the list of contributors to the fashionable W3C
committees, many of them look very familiar.

You go on at great length about the benefits of standardization.
However, I suspect that many companies have failed realized the full
benefit with the CORBA standards because the standards were incomplete,
and overly complex. You attempt to prove some of his points below.

Douglas C. Schmidt wrote:
> ...

>> Vendors insist on adding their own extensions (often incompatible
>> with the specification), much of what is needed is underspecified,
>> and the much-touted freedom of choosing a vendor largely does not
>> exist: even with 100% CORBA compliance, another vendor may not
>> support the platform I need, may not provide the language mapping I
>> need, may not support the compiler I need, or may not implement
>> the particular part of the CORBA spec I need.
>
>
> While this is often true for proprietary ORBs, it just doesn't make
> sense given the availability of very good open-source ORBs.
> Companies like OCI and PrismTech make a good business catering
> PRECISELY for customers with the types of needs you mention above,
> and they support multipe ORBs (e*ORB, TAO, JacORB, and ORBit).

And:

> ...
>> And, to boot, it provides features that neither general-purpose nor
>> DRE CORBA implementations can provide: a persistence service that
>> is incredibly easy to use,
>
>
> BTW, it's worth pointing out that the AMD approach you mention here
> is remarkably similar to the AMH approach implemented by TAO back in
> 2000!

This is obviously a very useful proprietary feature that locks the
enduser into using TAO.

BTW, why was such an obviously useful and necessary feature never
standardized?

> ...
>> You mean painful because of the BOA? But the BOA was a standard
>> too!
>
>
> Pulleeeeeze Michi, don't EVEN go there!!!!

Why not? From the point of view of source code portability code *all*
BOA implementations were proprietary. What is your point here? That such
things never occur anymore? Because that isn't the case either!

>> Bidirectional IIOP and CORBA security were standards too, as I
>> recall. What has become of those?
>
>
> As far as I know, TAO's supported bi-directional GIOP/IIOP for the
> past 3-4 years. As for CORBA security, please see the discussion
> above about this.

CORBA security prior to CSIV2 was so ill specified that any commercial
implementation was for all intents and purposes proprietary. Where was
the benefits of standardization for companies that used these
implementations?

From what I can tell the only two ORBs to implement bi-dir GIOP/IIOP
are JacORB and TAO (can they interoperate? The last message I can find
on this indicates that they cannot). In addition bi-dir GIOP/IIOP has a
number of specification problems...

> ...
>> Last time I looked, there wasn't a single commercial vendor that
>> would provide CCM, load balancing, transactions, and fault
>> tolerance. (Pick any two, and you just might be lucky.)
>
>
> Well, there's at least one commercially supported ORB where load
> balancing, fault tolerance, transactions, and CCM are all supported
> (I'll let you guess which one it is ;-)) and I'll let the other ORB
> vendors do their own marketing.

Do you think that xots (working on alpha 0.80?) is ready for prime
time? That notwithstanding...

- Can the TAO transaction service interoperate with another ORBs
transaction service? I highly doubt it since up until very recently the
XA format ids could clash. This was fixed by a recent RTF (finally),
but as of this date the OMG hasn't assigned any... This means a clash
of transaction ids is possible.

- Load balancing isn't specified, so this is proprietary.<br>

> .. Hum, I guess you haven't read the Real-time CORBA spec then? It's
> had a standard threading model since 1998? Please see
>
> http://www.cs.wustl.edu/~schmidt/report-doc.html
>
> for a serious of columns on Real-time CORBA and its threading model
> that Steve and I wrote several years ago.

Well, its great that this is standardized for a RT ORB. However, most
of the market wants this in a non-RT ORB. How is that effort coming
along?

>> And it provides that performance with APIs that are a fraction of
>>> CORBA's in complexity, and with a smaller footprint.
>
> Yes, again, this claim needs to be substantiated empirically.

Which claim needs to be substantiated? How about a line count of the
POA API vs. the Ice API that offers equivalent functionality.

I took the PortableServer.idl and removed the blank lines and comments.
Then I took ObjectAdapter.ice, removed the commands and merged in
ServantLocator.ice.

I claim these offer equivalent functionality (FUD? Take a look at the
ice documentation).

I get 29 lines of slice code for the Ice object adapter, and 211 lines
of IDL for the POA.

> ... Doug

Best Regards, Matthew
--
matthew at zeroc.com

Marc Laukien

unread,

Jul 28, 2003, 12:12:08 PM7/28/03

Douglas C. Schmidt wrote:
>>>
>>>The proof is in the math. You can simply calculate the message sizes.
>
>
> Unfortunately, I do systems R&D, not theory. Thus, as I mentioned
> above, the key questions are:

So in systems R&D you shouldn't even consider the number of bytes a
protocol message takes as relevant? You must be speaking about a
different kind of systems R&D than what I have in mind.

>
> . Do the differences in the message size actually make a difference
> empirically, and if so, under what conditions. We've done all sorts
> of experiements with TAO over the years shaving off various amounts of
> bytes in the GIOP headers and we've found that in many cases it doesn't
> make much difference at all since that's not where the bottleneck is.
> There are published papers on this at
>
> http://www.cs.wustl.edu/~schmidt/ACE_wrappers/TAO/docs/pluggable_protocols/
>
> for empirical results.

In many cases, it doesn't make a difference. In other cases, such over
slow modem connections, it makes a huge difference.

>
> . Is there something inherent to what Ice does vs. what a CORBA
> implementation can do using either the ETF and/or its own
> proprietary messaging format (while still preserving the standard
> CORBA programming API). As David Janello pointed out in a recent
> post, a lot of the stuff you're doing in Ice can be (or already has
> been) integrated into CORBA, thereby providing a standards-based
> programming API with a custom implementation.

Of course you can implement a more efficient encoding for CORBA, too.
However, not without changing CDR, so the standardized pluggable
transport interface won't help.

If we continue the discussion this way, we might end up with concluding
that you can improve CORBA in all kinds of areas to make it more similar
to Ice. Well, good luck, then you have a major CORBA re-write before you.

>
>
>>>Are you actually reading what I write, or do you just respond to
>>>further attack Ice?
>
>
> Whew, you and Michi are sure defensive about Ice! As I mentioned to
> Michi, I'm not objecting to Ice per se, I'm objecting to your
> marketing tactics, which are often (though by no means always) heavily
> based on FUD. When you don't use FUD, I don't object (as much).

I'm not sure if we should continue this thread. This becomes a flame
war, for which I don't like to waste my time.

-- Marc

Douglas C. Schmidt

unread,

Jul 28, 2003, 12:20:19 PM7/28/03

Hi Matt,

>> Doug, I think its very disappointing to see someone that I highly
>> respect resort to personal attacks on Michi in an attempt to prove
>> your argument.

Well, it looks like everyone is just going to be very disappointed
with everyone these days. I'm disappointed that Michi and Marc have
resorted to FUD in an attempt to prove their arguments. I'm
disappointed that Michi isn't abiding by his own rules for USENET
postings, etc. There's plenty of disappointment to go around.

>> I find it amazing to hear you claim that the OMG isn't losing
>> momemtum.

I don't recall ever saying that. IIRC, my point was that CORBA is
doing quite well, particularly in the realm of mission-critical
distributed real-time and embedded (DRE) systems, which is the area
that I care about.

>> You go on at great length about the benefits of standardization.
>> However, I suspect that many companies have failed realized the
>> full benefit with the CORBA standards because the standards were
>> incomplete, and overly complex.

As Steve and I have pointed out repeatedly, this can be said for
pretty much all de facto and de jure standards, e.g., UNIX/POSIX, C,
C++, Windows, X-Windows, MFC, ACE, SOAP, COM/DCOM, etc. The fact that
there are flaws in all these standards doesn't (necessarily)
invalidate their utility.

>> This is obviously a very useful proprietary feature that locks the
>> enduser into using TAO.

Precisely - which is no different than Ice in this regard. I was
simply pointing out that (1) Ice's AMD and TAO's AMH were very similar
and (2) it's certainly possible to add these capabilities to CORBA.

>> BTW, why was such an obviously useful and necessary feature never
>> standardized?

It would be a great thing to standardize! If I worked for a company
that would be one of the top things on my list to standardize.
Hopefully, it WILL be standardized at some point by the OMG, at which
point this discussion will be moot. The difference, of course, is
that with Ice it is unlikely to EVER be standardized (unless Ice
becomes adopted by a standardization effort), whereas with CORBA it
COULD be standardized.

Check out

http://www.cs.wustl.edu/~schmidt/gifs/futility.jpeg

for my earlier perspective on this issue in case you don't want to
re-read what I wrote earlier.

>> >> You mean painful because of the BOA? But the BOA was a standard
>> >> too!
>> >
>> >
>> > Pulleeeeeze Michi, don't EVEN go there!!!!

>> Why not?

Because everyone with half a brain knows the BOA was a COMPLETE botch!

>> From the point of view of source code portability code *all* BOA
>> implementations were proprietary.

Yup.

>> What is your point here?

That focusing obsessively on fiascos like the BOA and POS is a
strawman.

>> That such things never occur anymore? Because that isn't the case
>> either!

Matt, you seem to be mistaking me for someone who is an ardent
defender of the OMG, which isn't the case. I'm therefore not going to
feel compelled to respond to these points you're making since you're
arguing with a strawman.

>> CORBA security prior to CSIV2 was so ill specified that any
>> commercial implementation was for all intents and purposes
>> proprietary. Where was the benefits of standardization for
>> companies that used these implementations?

Nope!

>> From what I can tell the only two ORBs to implement bi-dir
>> GIOP/IIOP are JacORB and TAO (can they interoperate? The last
>> message I can find on this indicates that they cannot).

That would be a good question to ask to PrismTech
<a...@prismtechnologies.com> and OCI <spen...@ociweb.com>, both of
whom support JacORB and TAO commercially. My guess is that if there
are customers who need this capability, it works (or can be trivially
made to work).

>> In addition bi-dir GIOP/IIOP has a number of specification
>> problems...

Ok, so these are things that should be fixed. I find it interesting
that the ZeroC "solution" is to scrap the entire CORBA specification
and write something that doesn't interoperate with ANYTHING!

>> Do you think that xots (working on alpha 0.80?) is ready for prime
>> time? That notwithstanding...

I don't work on XOTS, but that's a good question to ask Christoph
Liebig <xfro...@yahoo.com>.

>> - Can the TAO transaction service interoperate with another ORBs
>> transaction service? I highly doubt it since up until very recently the
>> XA format ids could clash. This was fixed by a recent RTF (finally),
>> but as of this date the OMG hasn't assigned any... This means a clash
>> of transaction ids is possible.

Again, this isn't my bailwick, but Christoph would know the status.

>> - Load balancing isn't specified, so this is proprietary.<br>

As you may or may not know, there's an effort to standardize Load
Balancing within the OMG. At this point, there are several
implementations (in TAO and in JacORB from PrismTech) of the
prototypical Load Balancing specification that was developed for an
earlier round of the OMG LB specification effort. Check out

http://www.cs.wustl.edu/~schmidt/corba-research-design.html
http://www.cs.wustl.edu/~schmidt/corba-research-performance.html

for papers that describe the initial prototypes of the spec.

>> Well, its great that this is standardized for a RT ORB. However,
>> most of the market wants this in a non-RT ORB. How is that effort
>> coming along?

If you check out the column that Steve and I wrote at

http://www.cuj.com/experts/2003/vinoski.htm

or the tutorial on the topic we wrote at

http://www.cs.wustl.edu/~schmidt/RT-CORBA.ppt

you'll see that there's really nothing "real-time" specific in the
threading model defined in the Real-time CORBA spec. As a result, any
CORBA vendor can implement this and non-real-time ORBs will be able to
use a standardized API for threading in CORBA. TAO, ORBexpress, and
e*ORB all support this capability - and if customers of other ORBs
want it, I'm sure their vendors can/will add it without any problems.

>> >> And it provides that performance with APIs that are a fraction of
>> >>> CORBA's in complexity, and with a smaller footprint.
>> >
>> > Yes, again, this claim needs to be substantiated empirically.
>>
>> Which claim needs to be substantiated?

Two things:

1. That the performance of Ice is comparable with top CORBA ORBs

2. That the footprint of Ice is comparable with top CORBA ORBs

Again, I'm not arguing that this isn't the case - I just haven't seen
any empirical justifications for these claims from you folks yet. As
I said to Michi, once these claims are substantiated empirically
(e.g., by Gautam's middleware comparitor environment) we can have an
actual technical discussion, rather than a marketing FUD discussion.

>> How about a line count of the POA API vs. the Ice API that offers
>> equivalent functionality.

It's not exactly clear what that proves. One of my earlier points was
that most large-scale systems provide domain-specific wrappers for the
underlying middleware, which is often MUCH smaller to the server
application programmers than any general-purpose mapping. Moreover,
as model-based software development tools continue to evolve, most (if
not all) of this sort of "glue" code will be generated automatically.
In both cases, the fact that the Ice POA is simpler than the CORBA POA
is really in the noise. However, the fact that CORBA is a STANDARD
makes a HUGE difference for organizations who are developing complex
mission-critical DRE systems since these systems need to live for a
long time.

BTW, I complement you on actually sticking with technical issues in
your email.

Marc Laukien

unread,

Jul 28, 2003, 12:50:42 PM7/28/03

Douglas C. Schmidt wrote:
> Ok, so these are things that should be fixed. I find it interesting
> that the ZeroC "solution" is to scrap the entire CORBA specification
> and write something that doesn't interoperate with ANYTHING!

We actually considered adding IIOP compatibility to Ice. However, IIOP
is very strongly coupled with the CORBA type system, therefore this is
very difficult. We didn't want to use the CORBA type system, because we
feel that it is both too complex and too limiting. (Please don't tell me
that this is FUD!)

While you are right that Ice currently doesn't interoperate with
anything, this will most likely change. While we are certainly no SOAP
fans, we can add SOAP or XML-RPC support in the future. Ice is already
prepared for that: It can marshal Ice data types in a format that is
already very close to SOAP/XML-RPC, for our persistence service
"Freeze". It also makes use of XML schemas to provide for database
migration, if the Slice description of the stored data changes. (CORBA
doesn't offer anything like this...)

For more information, please have look at our documentation at
http://www.zeroc.com/download.html

-- Marc

Douglas C. Schmidt

unread,

Jul 28, 2003, 12:53:32 PM7/28/03

Hi Michi,

>> I thought it was the standard that mattered, not the technology?
>> Haven't you been arguing all along that the problems I quoted with
>> CORBA don't matter,

No, I haven't said that don't matter - I've been saying that they
aren't the showstoppers that the Ice team would have everyone believe.
As Steve pointed out recently, people reading your early posts in this
thread would think that no one had ever managed to write a successful
CORBA application in C++!!

>> and that CORBA is standard is what matters?

CORBA as a standard is certainly important - though it's more than
just the standard that users/customers ultimately want - they also
want technology that WORKS!

>> As I said in another post, the usefulness of a standard depends a
>> lot on how popular it is, how many people are using it, and how
>> many vendors there are.

No disagreement there.

>> I've seen quite a few CORBA vendors disappear over the past three
>> years or so and, for public companies that sell CORBA, the revenue
>> figures are declining, according to their quarterly reports.

As I mentioned in my earlier reply to Marc, at the same time we see a
huge increase in the adoption of open-source implementations of CORBA,
with many commercial companies providing support a la RedHat, SuSe,
Debian, etc. Just as there's been a decrease in the number of
proprietary versions of UNIX (only to be replaced with a consolidation
around Linux), I think we're seeing the same thing happening in the
CORBA market. Check out

http://www.cs.wustl.edu/~schmidt/commercial-support.html

for a small sampling of what's going on with ACE+TAO, where there are
now companies in six countries and three continents providing support
for ACE+TAO.

>> (Small wonder, with half the world chasing the next silver bullet
>> in form of web services...)

Yes, indeed! This is something I believe you and I still agree on ;-)

>> That in itself worries me. I remember five years ago, there was
>> something new and exciting happening with CORBA all the time. Now,
>> it seems to be comparatively quiet. (Just look at the traffic in
>> this news group. There was a *lot* more a few years ago.)

Yes, that was back when you were generating a lot of it ;-) ;-). But
seriously, this issue was discussed on comp.object.corba about six
months ago. My response at the time still holds: most CORBA users are
posting questions on the newsgroups and mailing for the ORB(s) they
are using since they get much more in-depth feedback from active user
communities. On any given day, comp.soft-sys.ace (which also serves
as the TAO newsgroup) gets 2-3 times more CORBA-related postings than
comp.object.corba.

>> Forgive me for being skeptical, but I think it will be quite a long
>> time before computing advances sufficiently to make something like
>> MDA real.

Actually, it's already working quite nicely - particularly in the
realm of DRE systems. If you do a google search on "MoBIES" you'll
find dozens of links to projects that are part of the DARPA
Model-based Integration of Embedded Systems (MoBIES) program. Some of
the flagship work is being done at the Institute for Software
Integrated Systems (ISIS) at Vanderbilt University. Check out

http://www.isis.vanderbilt.edu/mda.html
http://www.isis.vanderbilt.edu/research/mic.html

for information on the overall technology thrusts. Many of these
tools are available for online download, in particular the Generic
Modeling Environment (GME), which you can obtain from

http://www.isis.vanderbilt.edu/Projects/gme/default.html

These tools and technologies are being used successfully in a number
of very large-scale DRE systems in domains such as avionics,
vehtronics, and software defined radios. There is also an effort
afoot to standardize these capabilities. Please see

http://www.omg.org/news/meetings/tc/MIC_Emb_day.pdf

for meetings at the September 2003 OMG meeting that will address these
topics.

>> I'm afraid that these problems are in the nature of the beast and
>> that no amount of modeling will ever make them go away.

There's no denying that the problems are hard. However, there are
some extremely useful model-based software development solutions that
are maturing now, so I recommend you spend some time to check it out.
A lot of this stuff is making the middleware types of issues that
we've historically wrestled with "disappear", which is ultimately a
"Good Thing"[TM] - though it'll be a "disruptive technology" for
middleware vendors. If you want to see the Innovator's Dilemma at
work for our field, this is the place to look! There's additional
thoughts on these topics in our paper at

http://www.cs.wustl.edu/~schmidt/PDF/MDA4DRE.pdf

Douglas C. Schmidt

unread,

Jul 28, 2003, 1:00:18 PM7/28/03

Hi Marc,

>> We actually considered adding IIOP compatibility to Ice.

That would be very cool. Ironically, we've also discussed adding an
Ice binding to TAO ;-)

>> However, IIOP is very strongly coupled with the CORBA type system,
>> therefore this is very difficult. We didn't want to use the CORBA
>> type system, because we feel that it is both too complex and too
>> limiting. (Please don't tell me that this is FUD!)

Ok, ok, you're off the hook (this time ;-) ;-)).

>> While you are right that Ice currently doesn't interoperate with
>> anything, this will most likely change. While we are certainly no
>> SOAP fans, we can add SOAP or XML-RPC support in the future.

Sure, that makes good sense.

>> Ice is already prepared for that: It can marshal Ice data types in
>> a format that is already very close to SOAP/XML-RPC, for our
>> persistence service "Freeze". It also makes use of XML schemas to
>> provide for database migration, if the Slice description of the
>> stored data changes. (CORBA doesn't offer anything like this...)

BTW, this is an area where I think ultimately that model-based
software development tools are the way to go since they can handle the
typesystem transformation issues at a more effective level of
abstraction than an interface definition language approach. For
example, the MoBIES project at DARPA has illustrated all sorts of ways
to generate different types of Rose -> API/protocol mappings from
their modeling tools. At some level, these tools render the debate
between Ice vs. CORBA vs. SOAP, etc. moot, which is why I think they
are the way of the future. To use different terminology, these tools
raise the level of abstraction for defining systems so that the choice
of middleware largely becomes an "accidental complexity."

Matthew Newhook

unread,

Jul 28, 2003, 1:36:28 PM7/28/03

sch...@tango.doc.wustl.edu (Douglas C. Schmidt) wrote in message news:<bg358d$5...@tango.doc.wustl.edu>...
> ...

This is grossly unfair & untrue. You make it seem like Michi is
posting hundreds of articles on Ice in this newsgroup, when the
reality is that Michi *still* provides helpful advice to everyone on
CORBA to this very day!

Before this thread Michi posted one article on Ice in this newsgroup
announcing it as a possible alternative to CORBA. How is that pimping
Ice? I could more fairly accuse you of pimping ACE + TAO on this
newsgroup. A casual google search (author:schmidt ACE
group:comp.object.corba) shows 710 articles. A google search for Michi
(author:michi group:comp.object.corba) shows 3,840 - of which
precisely 2 mentioned Ice.

I don't have a problem with anyone questioning our technical claims --
in fact, I welcome it. I strongly believe in the value of our
technology and use it in implementing a production system every day (I
eat my own dogfood). But I do have a severe problem with attacking
anyone personally.

Best Regards, Matthew

Douglas C. Schmidt

unread,

Jul 28, 2003, 1:40:56 PM7/28/03

Hi Michi,

>> Hmmm. There are a lot of interesting issues coming up here. One is
>> the life time of distributed systems. That's an interesting one in
>> itself. What *is* the average life time of software, and what does
>> the distribution curve look like? I know that we have the full
>> gamut of life time from days (as in the financial world, where a
>> lot of financial modelling programs are written with a life
>> expentance of less than week),

Right - and in time-to-market-driven environments like this, I agree
with your point that simplicity is a MAJOR determinant, rather than
standards-compliance, super low-latency, etc.

>> to to years (as for air traffic control system, which tend to live
>> for decades).

Agreed - large-scale mission-critical DRE systems have different time
scales. Check out

http://www.cs.wustl.edu/~schmidt/PDF/MetaTechniques.pdf

for a paper we wrote that describes some of the technologies that are
needed to address the challenges of long-lived DRE systems.

>> I have to admit that I've never thought much about this -- I
>> honestly don't know what the distribution curve would look like, or
>> how skewed it would be. (Bi-modal or even try-modal maybe?)

Or perhaps even triodia ;-)

>> I know that a lot of software I have written myself was out of date
>> after maybe three or four years. But that's simply because I tend
>> to work at the systems level, and I often write tools to make up
>> for some deficiency or lack of functionaly in some software that
>> I'm using. Quite often, the tool I wrote becomes obsolete when the
>> software I wrote it for now offers the functionality of the tool,
>> of the software I wrote the tool for no longer exists (or I stop
>> using it). Anyway, I digress...

;-) Your point is well taken, however. Not all types of systems
require the benefits (and costs) of standardization. Complex
mission-critical DRE systems just happen to be a class of system that
often does.

>> It's interesting to think about the benefits of standardization
>> though. There are several I can see off-hand:
>>
>> - A standard makes it more likely that I'll be able to hire people with the
>> skill I need.

Agreed.

>> - A standard makes it more likely that the people I hire will understand each
>> other.

Right.

>> - A standard makes it more likely that I'll be able to switch software, or
>> hardware, or vendor, or whatever.

Yes - depending on how defined/implemented the standard, of course ;-)

>> - A standard makes it more likely that I'll be able to find
>> literature, training courses, etc.

Right, though I would also add:

- A standard that gets suffcient "traction" in the market place (e.g.,
IP, the x86 instruction set, POSIX, CORBA, etc.) enables major
improvements in quality of service because it enables companies to
leverage/amortize their R&D efforts "below" the API/protocol defined
by the standard. This is literally the reason why there's a
"Moore's Law" and a "Metcalf's Law" for hardware and networks.

>> To extent of the above points, the standard helps to reduce
>> complexity. (It's less complex to not have to train a new engineer
>> than to have to train him.)

Agreed.

>> But I'm not aware of how standards would reduce complexity of the
>> actual application. The problem I want to solve doesn't get
>> magically simpler because there is standard, I would think.

I don't think anyone ever claimed this stuff is "magic"!!! But let's
see if we can apply some context to speak concretely here. For
example, assume that we want to build a product-line architecture for
real-time avionics mission computing systems, e.g., the type of DRE
systems described in our papers at

http://www.cs.wustl.edu/~schmidt/corba-research-realtime.html

Before the advent of middleware technologies like Real-time CORBA
these systems were heavily stovepiped, where each different airplane
(e.g., F-18 vs. F-15) and airplane VARIANT (e.g., F-15 E vs. F-15 K)
was COMPLETELY different. As you might expect, in this situation the
complexity of applications written for these platforms was VERY high
since each development team had to not only understand the application
domain, but also had to understand the complexities of all the
distributed computing "stuff" we now call "middleware." This was
ENORMOUSLY tedious, error-prone, time-consuming, and expensive.

The major win of moving to a standard like Real-time CORBA in this
domain was push the complexity of the distributed computing "stuff"
into the middleware, thereby GREATLY simplifying the tasks of
application developers. There is now plenty of evidence that
illustrates how effectively this stuff works in practice, i.e.,
companies like Boeing have tracked the productivity and quality
increases of standards-based middleware solutions and show that they
have substantial savings over the lifecycle.

As for what SPECIFICALLY the standard contributes to all of this -
companies developing complex, long-lived mission-critical DRE systems
are VERY leary of getting themselves wrapped around the axle of
proprietary COTS solutions since they know from experience this leads
them into ALL sorts of problems with recurring lifecycle costs. So,
while there's no "magic" here, the absence of a STANDARD often makes
it impossible to adopt COTS solutions - which are important for all
sorts of other business reasons.

>> Yes and no. I agree that people who use ancient software suffer
>> from the cost of maintaining that software. The question is how
>> much standards actually help with that. When you are talking twenty
>> years plus, it seems that a lot of standards disappear before the
>> software gets a chance to get as old as that, meaning that, by the
>> end of that period, it seems irrelevant whether the software was
>> built on what once was a standard.

As usual, it depends on the domain, the experience of the
developers/architects, and the standard(s). For example, there's a
lot of 10-20 year old software written using standards like
C/C++/UNIX/TCP-IP that still works quite nicely and can be evolved
readily over time since these are still "active" technologies, despite
their age, e.g., people still learn this stuff in schools and training
courses. In contrast, 10-20 year old software written using stuff
like Jovial, Hal-S, CMS-2, and proprietary
languages/executives/protocols, etc. is usually in a world of hurt
since NO ONE learns this stuff anymore in schools and training
courses.

>> More relevant seems to be whether, at the time I need maintenance
>> for my software, whether there is still an active and interested
>> community around the technology.

Agreed.

>> If so, I'll get my maintenance done; if not, I'll have a hard
>> time. So, the more relevant criterion seems to be whether the
>> technology is "alive" as opposed to whether it is standardized.

Right, I agree with this, as well. Ada's a good example of a
"standard" that isn't really "alive" much anymore (outside of a few
domains).

>> See above. The complexity of the application domain doesn't
>> disappear by magic.

Agreed - but standards-based COTS middleware can DEFINITELY help
considerably, particularly for certain classes of systems.

>> So, the complexity of the application I want to build is not
>> reduced by the standard I think.

Well, I think differently on this, but I suspect perhaps we have
different perspectives since we work in different domains.

>> The standard does make it more likely though I might find people
>> with experience in that space, or that I might find tools to help
>> me out somehow. So, yes, to that extent, complexity is reduced. But
>> that isn't reducing the complexity of the application itself, is
>> it?

Yes, as described above ;-)

>> I'm a little bit skeptical.

If you're interested, please send me email and I can send you some
names of folks to contact for me info.

>> Not that I doubt that these companies haven't done the studies or
>> shown that they saved money -- I'm sure that they have. On the
>> other hand, we've been pushing standardization for so long that we
>> sometimes accept it as a mantra without looking as closely as we
>> should. For example, I have also seen studies that showed the
>> tremendous cost savings and quality improvements that companies
>> experienced when they switched from UNIX to Windows, or from
>> sendmail to Exchange. I'm sure you'd have no problem finding lots
>> of people who'd laugh at that :-)

Sure - you and I both know about "lies, damn lies, and statistics"!
However, the people who are collecting these metrics aren't trying to
"sell" a product (unlike the stuides you mention above, most of which
are published by a vendor to help their marketing) - they are
collecting these metrics internally to validate whether they are
obtaining improvements in their lifecycle costs and cycle-time
productivity. But I agree with you that all studies and metrics (or
claims based on the lack therein ;-)) should be carefully scrutinized.

>> Hmmm... Yes. Clearly, things like a standardized fitting for light
>> bulbs makes everyone's life easier. The more wide-spread the
>> standard, the more useful it is, as a rule. And the better the
>> standard works, the more useful too. I guess that's where I'm
>> having problems with CORBA. It's a standard, no doubt, but it isn't
>> as good a standard as it should be, not by a long shot.

You'll get no disagreement from me that the CORBA standard shouldn't
be better! But again, if you check out other de facto and de jure
standards, such as UNIX, C/C++/C#, Perl, TCP-IP, Windows, X-Windows,
MFC, SOAP, COM, they all have deficiencies - in many cases much worse
that CORBA does! And yet they have all thrived in comparison to much
"cleaner" solutions.

>> We know how to do this sort of thing better now, just as we did
>> when we started CORBA, and DCE started to fade (and DCE was a
>> standard too).

Sure, but DCE was the "dying gasp" of the C-based way of developing
complex systems (X-windows faced a similar fate), so I don't think
it's really comparable with CORBA in this regard. Plus, CORBA's lived
MUCH longer than DCE ever did!

>> I think that lack of a good standard definitely hurts the
>> market. I'm not so sure about lack of poor one though :-)

Well, again, we're just going to have to agreed to disagree on the
core issues here. I guess my perspective on this is closer to the
pre-2002 Michi than this year's model... ;-)

Douglas C. Schmidt

unread,

Jul 28, 2003, 1:51:51 PM7/28/03

Hi Matthew,

>> This is grossly unfair & untrue. You make it seem like Michi is
>> posting hundreds of articles on Ice in this newsgroup, when the
>> reality is that Michi *still* provides helpful advice to everyone
>> on CORBA to this very day!

Agreed - and I compliment him on this. He's done a great job
explaining the intricacies of CORBA for many, many years. I'm
impressed that he still continues to contribute to the group. It says
a lot about him as a person and as a technologist.

>> Before this thread Michi posted one article on Ice in this newsgroup
>> announcing it as a possible alternative to CORBA. How is that pimping
>> Ice? I could more fairly accuse you of pimping ACE + TAO on this
>> newsgroup. A casual google search (author:schmidt ACE
>> group:comp.object.corba) shows 710 articles. A google search for Michi
>> (author:michi group:comp.object.corba) shows 3,840 - of which
>> precisely 2 mentioned Ice.

You're missing my point Matthew. I've never told vendors "not to post
stuff about their CORBA products on comp.object.corba" (though I try
to refrain from doing this unless it's in response to a discussion
like this). Michi did this REPEATEDLY - berating vendors for not
focusing exclusively on technical issues in their posts. I just find
it sad that now that he's changed his "allegiance" all of a sudden,
i.e., it's now ok with him for vendors to post non-technical
marketing-related stuff to comp.object.corba, whereas he never would
have countenanced this in the past.

>> I don't have a problem with anyone questioning our technical claims
>> -- in fact, I welcome it. I strongly believe in the value of our
>> technology and use it in implementing a production system every day
>> (I eat my own dogfood). But I do have a severe problem with
>> attacking anyone personally.

You'll find that when the postings are technical and not FUD-filled,
my responses are technical too. Ironically, I think this was Michi's
original goal when he was the "anti-hype/marketing policeman" of
comp.object.corba. The Ice team seems to want to have it both ways,
however, i.e., you want to be able to "bash" CORBA with FUD when it
suits your purposes, yet then draw back and claim the "high road" when
that suits your purposes. If you stop doing that, you'll find Steve
and I will stop calling you on it - it's that simple!

Take care,

Doug

Marc Laukien

unread,

Jul 28, 2003, 2:16:38 PM7/28/03

Douglas C. Schmidt wrote:
> You're missing my point Matthew. I've never told vendors "not to post
> stuff about their CORBA products on comp.object.corba" (though I try
> to refrain from doing this unless it's in response to a discussion
> like this). Michi did this REPEATEDLY - berating vendors for not
> focusing exclusively on technical issues in their posts. I just find
> it sad that now that he's changed his "allegiance" all of a sudden,
> i.e., it's now ok with him for vendors to post non-technical
> marketing-related stuff to comp.object.corba, whereas he never would
> have countenanced this in the past.

I cannot recall each and every posting that Michi made to this
newsgroup. However, if my memory serves me right, Michi only criticized
postings that were pure marketing, by people who never contributed
anything technical or otherwise helpful to this newsgroup. I don't think
Michi ever complained about somebody announcing a new
TAO/MICO/OmniORB/etc. release, or somebody announcing a paper about
middleware.

So, since I'm sure that you don't want to spread FUD, how about a few
references, Doug? Show me where Michi criticized others that contributed
to this forum for posting information about new releases, new papers,
etc. Since he did this "repeatedly", I'm sure it must be easy for you to
find several posts in Google that you can quote here?

>
>>>I don't have a problem with anyone questioning our technical claims
>>>-- in fact, I welcome it. I strongly believe in the value of our
>>>technology and use it in implementing a production system every day
>>>(I eat my own dogfood). But I do have a severe problem with
>>>attacking anyone personally.
>
>
> You'll find that when the postings are technical and not FUD-filled,
> my responses are technical too. Ironically, I think this was Michi's
> original goal when he was the "anti-hype/marketing policeman" of
> comp.object.corba. The Ice team seems to want to have it both ways,
> however, i.e., you want to be able to "bash" CORBA with FUD when it
> suits your purposes, yet then draw back and claim the "high road" when
> that suits your purposes. If you stop doing that, you'll find Steve
> and I will stop calling you on it - it's that simple!

We definitely will not stop voicing our opinion just because you decide
that it's FUD - it's that simple.

-- Marc

Douglas C. Schmidt

unread,

Jul 28, 2003, 3:10:40 PM7/28/03

Hi Marc,

>> I cannot recall each and every posting that Michi made to this
>> newsgroup. However, if my memory serves me right, Michi only
>> criticized postings that were pure marketing, by people who never
>> contributed anything technical or otherwise helpful to this
>> newsgroup. I don't think Michi ever complained about somebody
>> announcing a new TAO/MICO/OmniORB/etc. release, or somebody
>> announcing a paper about middleware.
>>
>> So, since I'm sure that you don't want to spread FUD,

Nope - I leave that to others - I just comment on it.

>> how about a few references, Doug?

Sure Marc, here's one for starters. I got it from:

http://groups.google.com/groups?q=Spence+%2B+Henning&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=Pine.HPX.4.05.10002170803060.3886-100000%40bobo.ooc.com.au&rnum=3

It's particularly amusing since Michi's first paragraph (the one
starting with "Right".) is pretty much what you folks have been doing
the past week, i.e., "extolling all the virtues of [Ice], and why it
is better than everything else under the sun, and tell everybody that
it is the best thing since sliced bread". I think that's the most
concise plot summary of our recent comp.object.corba soap opera I've
read!!!

----------------------------------------
On Wed, 16 Feb 2000 spen...@ociweb.com wrote:

> Hi Dimitry this is a "shameless plug" but rather than sending you off
> to research a thousand options with multiple URLs, I can tell you we
> meet your requirements very closely.
>
> We provide commercial support for the open source CORBA 2.2 (with
> some .3) ORB called TAO. We sell CDs of TAO precompiled for various
> platforms including Microsft NT and Visual C++ version 5 and 6.

[...]

Right. Shall I now follow up with a long article extolling all the
virtues of ORBacus, and why it is better than everything else under
the sun, and tell everybody that it is the best thing since sliced
bread?

Shall we then have similar follow-up postings from BEA, IONA, Inprise,
MICO, OIS, and a whole pile of others?

Would that improve what this newsgroup is supposed to be for? Would that
endear us to our audience?

Come on -- let's lay off this nonsense. Everyone here knows that we are
ORB vendors, and everyone knows what the advice from someone with a
vested interest in their product is worth...

Spence, if you really feal the urge to tell someone about your product
in more detail, I suggest you do it by e-mail, not by posting to this
group.

Cheers,

Michi.
--
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
AUSTRALIA http://www.ooc.com.au/staff/michi-henning.html
----------------------------------------

>> We definitely will not stop voicing our opinion just because you
>> decide that it's FUD - it's that simple.

Ok, have it your way! But you'll find that a well-reasoned technical
discussion will be a more effective way to promote your technology.
Besides, as Michi said himself:

>> Come on -- let's lay off this nonsense. Everyone here knows that we
>> are ORB vendors, and everyone knows what the advice from someone
>> with a vested interest in their product is worth...

This reminds me of that old maxim about "keep your words nice since
you may need to eat them some day" ;-)

Marc Laukien

unread,

Jul 28, 2003, 3:52:15 PM7/28/03

Douglas C. Schmidt wrote:
> Hi Marc,
>
>
>>>I cannot recall each and every posting that Michi made to this
>>>newsgroup. However, if my memory serves me right, Michi only
>>>criticized postings that were pure marketing, by people who never
>>>contributed anything technical or otherwise helpful to this
>>>newsgroup. I don't think Michi ever complained about somebody
>>>announcing a new TAO/MICO/OmniORB/etc. release, or somebody
>>>announcing a paper about middleware.
>>>
>>>So, since I'm sure that you don't want to spread FUD,
>
>
> Nope - I leave that to others - I just comment on it.
>
>
>>>how about a few references, Doug?
>
>
> Sure Marc, here's one for starters. I got it from:
>
>
http://groups.google.com/groups?q=Spence+%2B+Henning&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=Pine.HPX.4.05.10002170803060.3886-100000%40bobo.ooc.com.au&rnum=3

That's funny - I was expecting you to respond with *exactly* with this link.

This pretty much confirms what I was saying: You are comparing Malcom
S., who did nothing other for this newsgroup than responding with plugs
for TAO to each question about what ORB to use, with Michi who wrote
countless of postings about technical issues and helped other CORBA users.

Just compare the two posts: One is an annoucement about new
documentation being available (just like the many posts with the links
to your TAO/ACE papers), while the other one is simply TAO marketing.

Besides, you spoke of many such posts. Where are all the others? May we
see more?

>
> It's particularly amusing since Michi's first paragraph (the one
> starting with "Right".) is pretty much what you folks have been doing
> the past week, i.e., "extolling all the virtues of [Ice], and why it
> is better than everything else under the sun, and tell everybody that
> it is the best thing since sliced bread". I think that's the most
> concise plot summary of our recent comp.object.corba soap opera I've
> read!!!

I read this thread differently: You try to unfairly attack us because we
have an opinion that differs from yours.

I agree on the soap opera, and I would like to end this rather sooner
than later.

>
>>>We definitely will not stop voicing our opinion just because you
>>>decide that it's FUD - it's that simple.
>
>
> Ok, have it your way! But you'll find that a well-reasoned technical
> discussion will be a more effective way to promote your technology.
> Besides, as Michi said himself:

Doug, it's you who resorts to personal attacks, not Michi or me! And you
completely turn around what I said above: To us, our opinions are formed
because of technological reasons, and you can call it FUD all you want,
that won't make us stop posting our opinions.

-- Marc

Douglas C. Schmidt

unread,

Jul 28, 2003, 4:29:43 PM7/28/03

Hi Marc,

>> This pretty much confirms what I was saying: You are comparing
>> Malcom S., who did nothing other for this newsgroup than responding
>> with plugs for TAO to each question about what ORB to use, with
>> Michi who wrote countless of postings about technical issues and
>> helped other CORBA users.

Michi's certainly done a lot of great things, but it doesn't change
the irony of the fact that everything Michi said in his response
applies to what you folks have been doing the past week. Go back and
read Michi's posting carefully and you'll see that there was wisdom in
his words, which seems to have been lost on you folks recently.

>> Just compare the two posts: One is an annoucement about new
>> documentation being available (just like the many posts with the
>> links to your TAO/ACE papers), while the other one is simply TAO
>> marketing.

You seem to have a knack for missing the points of my postings Marc.
But here is a summary of my points (again):

1. I don't think anyone (at least not me) has a problem with your
posting Ice documentation to the newsgroup. That's purely
informational and of interest to many people.

2. The problem is with all the follow ups, in which you folks are
"extolling all the virtues of Ice, and why it is better than
everything else under the sun, and telling everybody that it is the
best thing since sliced bread?" (or at least since CORBA).

3. Even #2 isn't too bad (though it does pretty flagrantly violate
"Michi's Rule"), as long as you can back up your claims. However,
in many cases, you're simply making baseless claims, e.g., Ice
performance being inherently better than CORBA performance - which
is a groundless claim as far as I can tell since the benchmark's
we've seen thus far from Gautam show that both ORBexpress and TAO
are faster than Ice!

4. Moreover, to quote Steve V. "you're also exaggerating CORBA's
problems to the point of being misleading, just to make Ice appear
better." In other words, this thread has long since ceased to be
an "Ice documentation posting" message and become an Ice
infomercial!!!

>> Besides, you spoke of many such posts. Where are all the others?
>> May we see more?

Michi posted this stuff whenever he felt ORB vendors got out of line.
I don't have the time to chase it all down (I just remembered when he
said it to Malcolm, which is how I found the article so quickly), but
you're welcome to check out the archives for yourself. Regardless of
how many times he made this point, however, and irrespective of how
much you've "contributed" to CORBA in the past - that doesn't give you
a free pass to make groundless and exaggerated claims without being
taken to task for it! When I make a claim about CORBA or MDA I try as
much as possible to provide documentation for it.

>> I read this thread differently: You try to unfairly attack us
>> because we have an opinion that differs from yours.

Well, you're welcome to your view, but a careful reading of my
responses will show that I don't "unfairly attack" your technical
opinions (i.e., ones backed up with reasoned evidence), just your FUD.
For the record, Michi's recent postings have been quite technical and
well reasoned - and aside from kidding him about a few things (which
are well marked with ';-)') I've replied in kind.

>> I agree on the soap opera, and I would like to end this rather
>> sooner than later.

That's fine with me.

>> Doug, it's you who resorts to personal attacks, not Michi or me!

Hum, how about the following posting from Michi in which he says:

"Fortunately, the people who worked on ISO C++ standardization were,
on average, much better at C++ than the ones who worked on the CORBA
C++ mapping."

Hum, let's see now, he just insulted Steve Vinoski, Doug Lea, and Mark
Linton, who were three of the best C++ programmers in their day!
Yowza!

>> And you completely turn around what I said above: To us, our
>> opinions are formed because of technological reasons, and you can
>> call it FUD all you want, that won't make us stop posting our
>> opinions.

Like I said before Marc, have it your way - you can stop this any time
you'd like.

Take care,

Michi Henning

unread,

Jul 28, 2003, 5:23:36 PM7/28/03

"Douglas C. Schmidt" <sch...@ace.cs.wustl.edu> wrote in message
news:bg413n$i...@ace.cs.wustl.edu...

>
> Hum, how about the following posting from Michi in which he says:
>
> "Fortunately, the people who worked on ISO C++ standardization were,
> on average, much better at C++ than the ones who worked on the CORBA
> C++ mapping."
>
> Hum, let's see now, he just insulted Steve Vinoski, Doug Lea, and Mark
> Linton, who were three of the best C++ programmers in their day!
> Yowza!

I also retracted that statement as over the top and apologized for it.
I apologize again: I got carried away and it was a cheap shot. What
I should have said is that the ISO C++ mapping is better written
than the CORBA one. (The ISO C++ mapping is far more precise
in its language and, IMO, simply a better-quality specification.)

Cheers,

Michi.

Michi Henning

unread,

Jul 28, 2003, 5:24:12 PM7/28/03

"Douglas C. Schmidt" <sch...@tango.doc.wustl.edu> wrote in message
news:bg358d$5...@tango.doc.wustl.edu...

>
> >> Ice isn't burdened by a standards process and historical mistakes,
> >> which makes it comparatively easy to excel technically because we
> >> are free to apply the lessons of the past.
>
> Again, as Steve and I and others have pointed out, it's pretty easy to
> improve stuff technically if you're not constrained by key forces that
> are necessarily for technology to remain viable over the long-term.
> Microsoft has used this as a rationale to modify their distributed
> computing technologies every 2-3 years for more than a decade. I can
> remember you criticizing this strategy MANY times during various
> discussions over the years, yet now you embrace it - how ironic!

Doug, that's preposterous!

It is correct that I have criticised MS for many times for having a new
distributed computing thing every 2-3 years. It is not true that I
embrace or approve of that. (Who is spreading FUD now?)

Ice hasn't changed into something completely unrelated once every
two or three years -- it's only been released a few months ago. If we
indeed go and throw away Ice after two or three years and replace
it with something else, and then keep doing that a few more times,
you can accuse me of doing what MS did, not before.

> Actually, I don't have any negative reactions to *Ice* - I think it
> sounds cool. My negative reactions are to the way that you and Marc
> are spewing FUD and making a number of unsubstantiated claims (e.g.,
> about Ice's performance), which is really unbecoming of both of you
> and shouldn't be necessary in order to promote Ice.

What exactly have we claimed that is unsubstantiated? I honestly
don't recall anything we said that wouldn't be true with respect
to Ice's performance.

> In your case Michi, I'm also disappointed in the way that you've
> "changed your stripes" and gone from being a person who harshly
> criticized CORBA vendors in the past for using comp.object.corba as an
> advertising venue to turning this forum into an "Ice promo." While
> it's certainly your right and privilege to do this, it just strikes me
> as being rather hypocritical. I have no such complains about Marc -
> he never beat up people for doing this in the first place, so he's not
> being inconsistent.

I posted a short notice about the Ice doc, may God forgive me.
Thereafter, I uttered a number of criticisms on CORBA. We could
have discussed the criticisms but, somehow ended up discussing Ice
and my character. I certainly didn't ask for things to go in that direction!
By all means -- as I said before, I'm keen on technical discussions.

It is loading more messages.

0 new messages