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

xmlrpc, soap, corba suck ?

118 views
Skip to first unread message

Jan Kleinsorge

unread,
Mar 13, 2004, 7:22:05 PM3/13/04
to
In a small programming-group at my university we have the task to create a
distributed manager for log-files of a certain server-software. Our idea is
to have one central unit which takes control of a couple of non-local helper
applications which actually provide the information.
I google'd around for a while to find a rpc-technology that fits. I found
SOAP, CORBA and jabber quite interesting.
on the other side I found a couple of articles stating that xml-based rpc
isn't worth using because the transfered information doesn't need to be
human-readable and that it might be - compared to binary representation-
slow (I agree).
additionally it is said that CORBA is horribly bloated and is just too much
for small distributed applications.

after reading all this, I believe that we better implement our own little
protocol - binary and lightweight. but I'm afraid we lose too much time.


what do you use ? what are your experiences with xml-based rpc ? where did
or didn't you use it ?
any comment is appreciated !

thank you


s b e c k e r _ n o s p a m@nexbridge_nospam.com Randall S. Becker

unread,
Mar 13, 2004, 8:00:51 PM3/13/04
to
"Jan Kleinsorge" <wob...@gmx.de> wrote in message
news:c308jb$gi0$06$1...@news.t-online.com...

Jan,

From very recent experience, I have seen that with minimal ramp-up time,
people can develop production-grade CORBA-based clients and servants in 1-2
hours for reasonably significant applications (for the CORBA bits anyway).
While some articles may call CORBA horribly bloated, the reduced development
and long-term maintenance time associated with it, far outweight those
objections. After all, CPUs are still and will continue to be faster than
networks.

Cheers,

Randall


Douglas C. Schmidt

unread,
Mar 13, 2004, 8:38:01 PM3/13/04
to
Hi Jan,

>> In a small programming-group at my university we have the task to
>> create a distributed manager for log-files of a certain
>> server-software. Our idea is to have one central unit which takes
>> control of a couple of non-local helper applications which actually
>> provide the information. I google'd around for a while to find a
>> rpc-technology that fits. I found SOAP, CORBA and jabber quite
>> interesting. on the other side I found a couple of articles
>> stating that xml-based rpc isn't worth using because the transfered
>> information doesn't need to be human-readable and that it might be
>> - compared to binary representation- slow (I agree). additionally
>> it is said that CORBA is horribly bloated and is just too much for
>> small distributed applications.

It sounds like you've been reading the ICE marketing literature... ;-)

>> after reading all this, I believe that we better implement our own little
>> protocol - binary and lightweight. but I'm afraid we lose too much time.
>>
>> what do you use ? what are your experiences with xml-based rpc ?
>> where did or didn't you use it ? any comment is appreciated !

It's pretty trivial to use CORBA for the type of service you're trying
to do. In fact, there are already examples of logging services
available in The ACE ORB (TAO), which you can download from

http://deuce.doc.wustl.edu/Download.html

Check out the example in

$TAO_ROOT/examples/Logging/

for a simple example of a logging service and

$TAO_ROOT/orbsvcs/Logging_Service/
$TAO_ROOT/orbsvcs/tests/log/
$TAO_ROOT/orbsvcs/orbsvcs/log/

for a full-blown implementation of the CORBA Telecom Logging Service. The
latter is probably overkill for what you're trying to achieve, but
it'll give you a sense of what an industrial-strength logging service
API looks like.

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,
Mar 14, 2004, 9:22:18 AM3/14/04
to
Douglas C. Schmidt wrote:
>
> It sounds like you've been reading the ICE marketing literature... ;-)

Thanks for the plug, Doug. For those who didn't read it yet, here is the
link:

http://www.zeroc.com/

http://www.zeroc.com/iceVsCorba.html

-- Marc

Douglas C. Schmidt

unread,
Mar 14, 2004, 12:25:01 PM3/14/04
to
Hi Marc,

>> Thanks for the plug, Doug. For those who didn't read it yet, here is the
>> link:
>>
>> http://www.zeroc.com/
>>
>> http://www.zeroc.com/iceVsCorba.html

While we're trading URLs, here are some other good documents
to read

. "Validating Henning CORBA Performance Assertions"

http://www.omg.org/docs/mars/04-02-08.pdf

In this document, Bill Beckwith uses results from Gautam Thaker's
"Middleware Comparator" project at

http://www.atl.external.lmco.com/projects/QoS/

to demonstrate how the ICE team's assertion that "CORBA is slow"
simply doesn't hold water. As usual, it's important to subject
performance assertions to careful empirical scrutiny to
differentiate marketing hype from reality.

. "The ICE Follies"

http://www.omg.org/docs/mars/04-02-07.pdf

In this document, Steve Vinoski deconstructs the claims that the ICE
team likes to make and points out how it's now in their best
buiness interest to create FUD and claim that CORBA is dying and
dead. As usual, it helps to understand the motivation for
"technical" perspectives.

Marc Laukien

unread,
Mar 14, 2004, 2:02:32 PM3/14/04
to
Hi Doug,

Douglas C. Schmidt wrote:

> Hi Marc,
>
>
>>>Thanks for the plug, Doug. For those who didn't read it yet, here is the
>>>link:
>>>
>>>http://www.zeroc.com/
>>>
>>>http://www.zeroc.com/iceVsCorba.html
>
>
> While we're trading URLs, here are some other good documents
> to read

Thanks for the URLs. I think it would have been fair if you would have
listed Michi's presentation from the same meeting as well:

http://www.omg.org/docs/mars/04-02-06.ppt

http://www.omg.org/docs/mars/04-02-06.pdf

>
> . "Validating Henning CORBA Performance Assertions"
>
> http://www.omg.org/docs/mars/04-02-08.pdf
>
> In this document, Bill Beckwith uses results from Gautam Thaker's
> "Middleware Comparator" project at
>
> http://www.atl.external.lmco.com/projects/QoS/
>
> to demonstrate how the ICE team's assertion that "CORBA is slow"
> simply doesn't hold water. As usual, it's important to subject
> performance assertions to careful empirical scrutiny to
> differentiate marketing hype from reality.

Well, this presentation mainly shows one thing: OIS's ORBExpress is damn
fast. There is no doubt, Bill and his team knows how to write fast
software. (I never claimed that Ice is faster or as fast as ORBExpress.)

As for the comparison with TAO, it would be interesting to see how Ice
1.3.0 compares with the latest version of TAO. Perhaps we could ask
Gautam to run a new test?

>
> . "The ICE Follies"
>
> http://www.omg.org/docs/mars/04-02-07.pdf
>
> In this document, Steve Vinoski deconstructs the claims that the ICE
> team likes to make and points out how it's now in their best
> buiness interest to create FUD and claim that CORBA is dying and
> dead. As usual, it helps to understand the motivation for
> "technical" perspectives.

I leave the spreading of FUD to you, we don't do this. Instead, we
concentrate on technical arguments.

Are you so upset because many TAO users are switching to Ice, or are you
just in the mood for a new flame war?

-- Marc

Douglas C. Schmidt

unread,
Mar 14, 2004, 3:12:14 PM3/14/04
to
Hi Marc,

>> Thanks for the URLs. I think it would have been fair if you would have

>> listed Michi's presentation from the same meeting as well:
>>
>> http://www.omg.org/docs/mars/04-02-06.ppt
>>
>> http://www.omg.org/docs/mars/04-02-06.pdf

As far as I can tell, the info Michi presented there is basically the
same as in the URLs you posted earlier. Besides, you folks don't need
ME to market ICE for you too do you? ;-)

>> Well, this presentation mainly shows one thing: OIS's ORBExpress is
>> damn fast. There is no doubt, Bill and his team knows how to write
>> fast software. (I never claimed that Ice is faster or as fast as
>> ORBExpress.)

Ah, there's nothing like revisionist history is there? The ICE team
has been claiming that the CORBA spec is somehow inherently "bloated
and slow" for some time now, which in fact is one of the "FUD"
statements that triggered the big flame work in comp.object.corba back
in July of '03. Here's Michi's quote on the subject from his posting
on July 19th in comp.object.corba:

++ 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.)

My point then (and now) is that claims like these simply don't bear
out when you examine them empirically, as Bill Beckwith's presentation
based on Gautam's Middleware Comparator show. BTW, it's ironic how
when someone points out an example of a standards-compliant CORBA ORB
FOO that's faster than ICE the response is "we never claimed that ICE
is faster than FOO!"

>> As for the comparison with TAO, it would be interesting to see how
>> Ice 1.3.0 compares with the latest version of TAO. Perhaps we could
>> ask Gautam to run a new test?

Sure, that would be great. Our research
<http://www.cs.wustl.edu/~schmidt/corba-research.html> has shown for
years that the performance of distributed object computing middleware
like CORBA is largely an implementation detail. A healthy
"benchmark-driven" competition between middleware is a good way to
improve performance for everyone, just like it is in the compiler
world.

Keep in mind, BTW, that I'm not claiming that ICE is slow - I'm
simplying providing well-established empirical evidence that the ICE
team's claim that CORBA is somehow inherently big/slow is marketing
hype that's not supported by actual studies that compare ICE with
standard ORBs.

>> I leave the spreading of FUD to you, we don't do this. Instead, we
>> concentrate on technical arguments.

Oh - riiiggghhhht....

>> Are you so upset because many TAO users are switching to Ice,

No, not at all (though it is amusing to see your "have you stopped
beating your wife?" tactic here - nice try ;-)). There's been a
steady increase in the use of TAO and contributions to ACE and TAO
<http://www.cs.wustl.edu/~schmidt/ACE-members.html> for years now, and
our plate is more full than ever. The number of companies that
provide commercial support for ACE and TAO is also expanding
world-wide <http://www.cs.wustl.edu/~schmidt/commercial-support.html>,
so it doesn't seem like ICE has made any difference in the rate of
adoption of TAO in commercial projects. Having said that, however,
I'm happy to hear that you folks are doing well.

>> or are you just in the mood for a new flame war?

I'm ALWAYS in the mood to respond to keep you folks honest Marc.

Marc Laukien

unread,
Mar 14, 2004, 4:24:11 PM3/14/04
to
Douglas C. Schmidt wrote:

> Hi Marc,
>
>
>>>Thanks for the URLs. I think it would have been fair if you would have
>>>listed Michi's presentation from the same meeting as well:
>>>
>>>http://www.omg.org/docs/mars/04-02-06.ppt
>>>
>>>http://www.omg.org/docs/mars/04-02-06.pdf
>
>
> As far as I can tell, the info Michi presented there is basically the
> same as in the URLs you posted earlier. Besides, you folks don't need
> ME to market ICE for you too do you? ;-)

Well, this was a panel discussion at the last OMG meeting, with three
presentations, one by Michi, one by Steve, and one by Bill. Leaving out
Michi's presentation might confuse the reader, because the context of
the other two presentations might not be clear.

>
>>>Well, this presentation mainly shows one thing: OIS's ORBExpress is
>>>damn fast. There is no doubt, Bill and his team knows how to write
>>>fast software. (I never claimed that Ice is faster or as fast as
>>>ORBExpress.)
>
>
> Ah, there's nothing like revisionist history is there? The ICE team
> has been claiming that the CORBA spec is somehow inherently "bloated
> and slow" for some time now, which in fact is one of the "FUD"
> statements that triggered the big flame work in comp.object.corba back
> in July of '03. Here's Michi's quote on the subject from his posting
> on July 19th in comp.object.corba:
>
> ++ 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.)
>
> My point then (and now) is that claims like these simply don't bear
> out when you examine them empirically, as Bill Beckwith's presentation
> based on Gautam's Middleware Comparator show. BTW, it's ironic how
> when someone points out an example of a standards-compliant CORBA ORB
> FOO that's faster than ICE the response is "we never claimed that ICE
> is faster than FOO!"

Not revisionist at all. You are just being selective about what quotes
from this infamous comp.object.corba thread you use. For example, have a
look at:

http://groups.google.com/groups?q=g:thl1673400303d&dq=&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=CYycnZF3TP0Gz4OiRTvUpQ%40speakeasy.net

Quote:

"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."

You are just playing the same game again which you already did back
then, namely to simply ignore all arguments that you don't like to hear.
To quote myself again:

http://groups.google.com/groups?q=g:thl3848505754d&dq=&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=dNCcnbvAovAQvriiXTWJkg%40speakeasy.net

"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."

>
>>>As for the comparison with TAO, it would be interesting to see how
>>>Ice 1.3.0 compares with the latest version of TAO. Perhaps we could
>>>ask Gautam to run a new test?
>
>
> Sure, that would be great. Our research
> <http://www.cs.wustl.edu/~schmidt/corba-research.html> has shown for
> years that the performance of distributed object computing middleware
> like CORBA is largely an implementation detail. A healthy
> "benchmark-driven" competition between middleware is a good way to
> improve performance for everyone, just like it is in the compiler
> world.

Again, it depends on what exactly you mean with efficiency. For example,
fast message forwarding is something that's inherently slow in CORBA,
due to the re-marshaling of data. For other measures of efficiency, such
as latency, you are correct.

>
> Keep in mind, BTW, that I'm not claiming that ICE is slow - I'm
> simplying providing well-established empirical evidence that the ICE
> team's claim that CORBA is somehow inherently big/slow is marketing
> hype that's not supported by actual studies that compare ICE with
> standard ORBs.

What studies are you referring too? Gautam's test focuses on marshaling
speed and latency. While this is a very important aspect of a middleware
platform, there are many other factors which are important for the
overall efficiency of a distributed system.

>
>>>or are you just in the mood for a new flame war?
>
>
> I'm ALWAYS in the mood to respond to keep you folks honest Marc.

Sigh... you are apparently indeed looking for a flame war :-( Well, for
my part I will simply stick with technical arguments, and leave the
hostilities to you.

-- Marc

Jan Kleinsorge

unread,
Mar 14, 2004, 4:24:25 PM3/14/04
to

"Douglas C. Schmidt" <sch...@ace.cs.wustl.edu> schrieb im Newsbeitrag
news:c32eau$6...@ace.cs.wustl.edu...


thank you for all the information. besides I learned what 'FUD' means.
unfortunately, after all I am left with FUD ;)

maybe it's best to flip a coin.


Frank Pilhofer

unread,
Mar 14, 2004, 4:30:21 PM3/14/04
to
Douglas C. Schmidt <sch...@ace.cs.wustl.edu> wrote:
>
> . "Validating Henning CORBA Performance Assertions"
> In this document, Bill Beckwith uses results from Gautam Thaker's
> "Middleware Comparator" project at
> to demonstrate how the ICE team's assertion that "CORBA is slow"
> simply doesn't hold water. As usual, it's important to subject
> performance assertions to careful empirical scrutiny to
> differentiate marketing hype from reality.
>

To be fair, this presentation did not address the performance-compromising
areas in IIOP that Michi mentioned. Also, Michi conceded that there was a
performance problem with older versions of ICE that were fixed since. The
slides concentrated on exposing this problem, the marshalling of octet
sequences, to a point that I personally considered unfair.

In general, I agree with Michi's assertion that marshalling performance
is usually not important, unless you have very large messages -- but those
typically involve long sequences of basic types, which are the easiest to
optimize in either IIOP or other protocols.

This is a CORBA newsgroup, and one would expect a CORBA bias here. But
can we please get more productive here?

I agree with the OP. Do xmlrpc, SOAP, CORBA and ICE suck? Yes. But
depending on your point of view, one may suck less than others.

Frank


--
Frank Pilhofer ........................................... f...@fpx.de
When most people put in their two cents' worth, they are not
overcharging. - Alfred E. Neuman

Michi Henning

unread,
Mar 14, 2004, 5:42:01 PM3/14/04
to
"Douglas C. Schmidt" <sch...@ace.cs.wustl.edu> wrote in message
news:c32eau$6...@ace.cs.wustl.edu...

> Hi Marc,
>
> >> Thanks for the URLs. I think it would have been fair if you would have
> >> listed Michi's presentation from the same meeting as well:
> >>
> >> http://www.omg.org/docs/mars/04-02-06.ppt
> >>
> >> http://www.omg.org/docs/mars/04-02-06.pdf
>
> As far as I can tell, the info Michi presented there is basically the
> same as in the URLs you posted earlier. Besides, you folks don't need
> ME to market ICE for you too do you? ;-)

I just would like to point out that the panel as scheduled had originally
four participants: Steve Vinoski, Bill Beckwith, Doug Schmidt, and
myself. Doug simply was a no-show on the day. No-one knew where
he was or why he hadn't shown up. (Attendance was confirmed by
Rebecca Bergeson about a week prior with all panelists.) It would
have been more interesting with Doug being there.

The few graphs Bill showed were selected from a much larger set
of graphs, and were selected to pick the case where Ice was slower
than the other ORBs. The reason for this was an inefficiency in our
marshaling code for byte sequences, which we fixed long ago.

> >> Well, this presentation mainly shows one thing: OIS's ORBExpress is
> >> damn fast. There is no doubt, Bill and his team knows how to write
> >> fast software. (I never claimed that Ice is faster or as fast as
> >> ORBExpress.)

I second that. I'm impressed by the speed of the ORBExpress
implementation. Bill, if I ever get a chance to steal your source
code, I will -- I'd love to know how your are doing it :-)

> ++ 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.)
>
> My point then (and now) is that claims like these simply don't bear
> out when you examine them empirically, as Bill Beckwith's presentation
> based on Gautam's Middleware Comparator show.

What the graphs show is that, despite the poor design of IIOP, it's
possible to build a fast implementation. What the graphs don't show is
how much faster that implementation would be if it wouldn't have to deal
with all the things that are wrong in IIOP.

> Sure, that would be great. Our research
> <http://www.cs.wustl.edu/~schmidt/corba-research.html> has shown for
> years that the performance of distributed object computing middleware
> like CORBA is largely an implementation detail. A healthy
> "benchmark-driven" competition between middleware is a good way to
> improve performance for everyone, just like it is in the compiler
> world.

What has always amused me is the strong focus on marshaling performance
for middleware. People somehow take marshaling speed as an indicator
of the quality of the entire middleware. I guess that is because it is easy
to measure marshaling performance whereas, for some of the other
important aspects of middleware, quantifying the differences is much
harder. (For example, it is difficult to put an absolute number on the
quality of an API or a language mapping, or on the quality of an object
model and all its implications.)

In terms of performance, the reality is that, beyond a certain point, it is
irrelevant: once the middleware is fast enough, further improvements
to marshaling speed are mostly pointless. To see why, consider under
what circumstances marshaling performance actually matters.

For small requests, marshaling performance is essentially irrelevant
because the round-trip performance is dominated by latency. But
there is little the middleware can do to reduce latency because latency
is incurred mostly by the cost of trapping into the kernel and, more so,
by the latency of the network between client and server. (For the
middleware to substantially affect latency, it would have to be horribly
inefficient in its call dispatch.)

For large requests, marshaling performance matters, provided that
the amount of time spent in the marshaling code is a substantial
percentage of the overall round-trip time (including the application
processing of the data at the server end). To make this clearer,
if 20% of the overall round-trip time is spent in the marshaling
code, and I make the marshaling code go twice as fast, I get
a 10% improvement in the round-trip time. On the other hand,
if only 10% of the overall round-trip time is spent in the marshaling
code, and I make the marshaling code go twice as fast, I get
only a 5% improvement in the round-trip time. So, this just
reflects the law of diminishing returns: it's not worth optimizing
something unless what I'm optimizing accounts for a significant
percentage of the overall processing cost.

All the middleware benchmarks work by measuring how long
it takes to marshal various types of data back and fourth, with
the benchmark doing nothing with the received data (that is,
tossing the data into the bit bucket). While that gives a good
indication of relative marshaling performance, it also is rather
artificial. In particular, in real applications, if the client sends
a large amount of data to the server, the server does *not*
simply throw the data into a black hole. Instead, the server
does something with the data.

What exactly the server does depends on the application.
Typically, the server will perform some I/O on the data,
such as writing it to a database or to another network, or it will
perform computation on the data, such as inverting a matrix.
But, as soon as the server spends any amount of time processing
the data, the percentage of time spent in the application code
goes up, and the percentage of time spent in the marshaling code
goes down. In turn, this means that the performance of the
marshaling code becomes less and less relevant.

Suppose that, for a given real-world application that moves a
large amount of data, the total amount of time spent
in the marshaling code is 5% (which is generous -- for
many applications, the percentage is smaller). Now, even if
I manage to do the marshaling at infinite speed, so it takes zero
time, this means that, at best, I can gain only 5% in performance.
But 5% (or, likely, even less than that), is no longer an important
percentage, at least not important enough to make marshaling
performance a major quality criterion for evaluating middleware.

The upshot of all this is that, provided that the middleware marshals
reasonbly fast, it's "fast enough", and making it faster provides
little overall payback.

There are many other criteria by which middleware can be evaluated,
such as its object model, its language bindings, the complexity of its
APIs, its architectural implications, how well it scales in specific
situations, on how many platforms it is supported, how many languages
it supports, how much it costs, how well it is supported, and so on.
(This list could be extended quite a bit.)

So, when talking about CORBA vs Ice, focusing on marshaling
performance alone largely misses the point because it picks out
a single aspect that, for many applications, isn't all that important.

BTW, a two-hour discussion followed the panel in Anaheim. It
was interesting to see that during those two hours, almost all
of the discussion centered around what the OMG could do to
make CORBA better and how to improve on the problems that
I pointed out during my talk.

It was also interesting that during those two hours, no-one
challenged the validity of any of the statements I made during
my presentation. People were *not* sitting there saying
"Michi, some of the points you made were incorrect or are
irrelevant." Instead, people were asking what could be done
to fix those problems in CORBA.

It's also interesting to note that MARS were planning to meet
at the upcoming OMG meeting in St Louis in April specifically
to go through the points I raised in my talk, to see what can
be done to address them. (Some people were talking of doing
a "CORBA Next Generation" in Anaheim -- we'll have to
wait and see whether anything comes of that.)

> Keep in mind, BTW, that I'm not claiming that ICE is slow - I'm
> simplying providing well-established empirical evidence that the ICE
> team's claim that CORBA is somehow inherently big/slow is marketing
> hype that's not supported by actual studies that compare ICE with
> standard ORBs.

IIOP is both larger and slower than it needs to be. I don't think that
there can be any argument about this. The senseless padding rules,
the complexity of marshaling TypeCodes and Anys, the lack of
encapsulation of the data carried by an Any (which makes it insanely
expensive to receive and re-marshal an Any value), the need to
negotiate byte order, the complexity of marshaling object references,
the issues around codeset negotiation -- these are all things that are
indisputably real and cause unnecessary overhead.

In other areas, things are less easy to quantify, but just as real: the
complexity of the run-time APIs, the mistakes and redundancies
in the object model, the complexity of the C++ mapping, the
larger working set sizes caused by the extra code required to
support the overly complex semantics, the lack of a well-defined
threading model -- these are all things that people have complained
about repeatedly in the past and are still complaining about.

This doesn't mean that CORBA is unworkable, or garbage, or dead,
or anything like it. (People are still building serious production-quality
and mission-critical systems with CORBA today.) But it does mean
that, after a good ten years of experience with CORBA, we have
learned a lot and that, given those lessons, we know how to build
better middleware today than we did back then.

Cheers,

Michi.

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

Bernard Normier

unread,
Mar 14, 2004, 5:45:31 PM3/14/04
to
Hi Doug,

For many years I worked at IONA on various aspects of Orbix 2000, and on a
number of CORBA specs. Like most people, I first heard about Ice with the
"Ice 1.0 released" announcement in February last year.
I had spent many years believing in and advocating the superiority of
standard-based software, so my first reaction was that this
proprietary-thing could not be a good idea.

Then I started reading ZeroC's web site, and perhaps more importantly, I
built Ice on my home PC (an Athlon 700). I was amazed that in less than 1
hour I could build a product that feature-wise was so comparable to a full
ORB (with a location service, a persistence service, even a notification
service).
How could this be possible? As a CORBA "guru", reading the Ice manual was an
eye-opening experience: the key is *simplicity*.

Simplicity like:
- no padding in on-the-wire representation
- non-opaque object references
- using Unicode instead of a complicated codeset negotiation mechanism
- in C++, using Standard Library classes instead of new String/Sequence
etc. classes
- and much more

So yes, CORBA has a number of unnecessary features. And making radical
(backward incompatible) simplifications is impossible for CORBA at this
stage, so going proprietary is the only option. Ice reuses many good CORBA
ideas, but also gets rid of many mistakes, to do a bit more with a much
simpler model/API.

ZeroC did not write Ice to be a faster ORB. Ice's first aim is simplicity.
Simplicity enables better performance: nothing in the Ice model/spec
prevents Ice from being as fast or even faster than any ORB, on the
contrary. It's just a question of careful implementation and optimization.

If you haven't done so yet, I recommend you download and build Ice to see by
yourself. I am sure it's nothing like building ACE+TAO :-).

Cheers,
Bernard
http://www.zeroc.com/vbulletin/showthread.php?s=&threadid=99
----
Bernard Normier
ZeroC, Inc
www.zeroc.com

Michi Henning

unread,
Mar 14, 2004, 6:38:04 PM3/14/04
to
"Frank Pilhofer" <f...@fpx.de> wrote in message
news:slrnc59i...@ariel.fpx.de...

>
> I agree with the OP. Do xmlrpc, SOAP, CORBA and ICE suck? Yes. But
> depending on your point of view, one may suck less than others.

There are lots of ways I can use to determine whether
something "sucks." Some criteria that come to mind:

- How simple is it to program with the platform?

- Does the platform have a large-enough feature set
*for my needs*. (The qualification is important because
features that I don't need don't do anything for me. In
fact, they are likely to hurt me because they contribute
to larger code and working set sizes and, depending on
the feature, may also have run-time footprint and performance
cost.)

- Does the platform support the languages I want to use?

- Does it scale sufficiently for my needs?

- Does the object model give me sufficient flexibility without
being more complex than necessary?

- Is the platform fast enough?

- Does the platform have a small-enough footprint?

- Does the platform support the compiler/OS/hardware
combinations I am interested in?

I've volunteered answers in the past in this group. To me,
Web Services and SOAP are a bad idea. The cost of
the protocol in terms of bandwidth and CPU cycles is
obscene -- so much so that it becomes a dominant factor.
And the notion of using XML (a document description language) to
do RPC is simply misguided, IMO, and was born of political
considerations rather than technical ones.

I also don't see the often-touted "simplicity" of Web Services.
Take any simple IDL definition and look at the XML to define
the equivalent types for Web Services. I don't have
to think long before I know which one is simpler...

And as for the arguments as to the readability of SOAP and
the self-describing nature of XML, they are simply ill-informed
and miss the point.

I see the Web Services crowd re-inventing the wheel from scratch
and, in the process, ignoring most of the lessons we learned over
the past ten years or so. As a result, the wheel is getting re-invented
with many of the same corners, plus a bunch of new ones. With any
luck, in a few years, Web Services will be as functional as CORBA
was a few years ago. This means that, after a five- to ten-year delay,
Web Services will have advanced to the point that was provided by
another technology five to ten years earlier. That's not progress, in my
book, especially when I consider the cost of introducing a new platform,
building all the tools that are required, training all the programmers in
the new technology, etc.

To me, CORBA provides a far better option than Web Services/SOAP.
At least, CORBA has a proven track record when it comes to building
serious applications whereas, for Web Services, the proof seems to still
be outstanding. Of course, CORBA isn't without its share of problems
either. Depending on your situation, Ice may be a viable alternative to
CORBA that addresses these problems. But, as many people have
pointed out, Ice does not have a standards base, which can disqualify
it as an alternative. And, if someone already has deployed CORBA
applications that they need to interoperate with, Ice may not be that
great either because throwing another middleware platform into the
mix is not something that should be done light-heartedly. On the other
hand, we have many customers without a CORBA legacy situation;
for such customers, Ice can be a great choice.

So, you get to pick your poison -- the perfect solution that suits everyone
simply does not exist, and likely never will. To me, the challenge is to
base the decision which middleware to use on realistic evaluation criteria
that matter for what I need and want to do, instead of using feature
tick lists, irrelevant performance comparisons, industry hype, or any
number of other, equally useless, criteria.

And, of course, building distributed systems is harder than building
non-distributed ones. Some of the complexity is simply in the nature
of the beast and no amount of middleware will ever change that. In
that sense, no existing RPC platform "sucks". They all make building
distributed systems easier than building the same systems
without middleware. It's just that one may be better suited to the
problem I'm trying to solve than another.

Mariusz

unread,
Mar 15, 2004, 3:20:10 AM3/15/04
to
Hi,

If You need to build this software really fast, and it have to be simple and
small use Ice. It's really good piece of software, and is easy to use.
Of course, if You prefer CORBA, then there is few good ORB's. Try TAO, or
Orbix if You like. But as i said - if You need something that is simple and
can be used without lot of doc reading then use Ice...

> thank you for all the information. besides I learned what 'FUD' means.
> unfortunately, after all I am left with FUD ;)
>
> maybe it's best to flip a coin.

--
Mariusz

Eric Marsden

unread,
Mar 15, 2004, 5:52:45 AM3/15/04
to
>>>>> "mh" == Michi Henning <mi...@triodia.com> writes:

[benchmarking marshalling speed]

mh> There are many other criteria by which middleware can be
mh> evaluated, such as its object model, its language bindings, the
mh> complexity of its APIs, its architectural implications, how well
mh> it scales in specific situations, on how many platforms it is
mh> supported, how many languages it supports, how much it costs,
mh> how well it is supported, and so on. (This list could be
mh> extended quite a bit.)

another criterion which is often overlooked in the comparison of
different middleware implementations is their robustness: the extent
to which their behaviour in the presence of invalid inputs is
acceptable. My work on dependability benchmarking during my PhD showed
that there is a considerable difference between CORBA implementations,
and that some are unacceptable for systems with any degree
of dependability requirements.

Quite a few ORBs have vulnerabilities in their marshalling code that
make it possible for a remote attacker immediately to crash the
process that hosts CORBA objects. For instance, a simple unix command

perl -e 'print pack("H*", "47494F50010201006C000080"), "\n"' \
| telnet <machine> <port>

is sufficient to crash an application hosted using TAO version 1.2.1,
and similar (though longer) corrupt messages provoke crashes in
current versions of TAO, in MICO, in ORBit, in ORBacus/C++ etc. The
vulnerabilities are generally due to the ORB being too trusting of
data while unmarshalling the IIOP stream; for instance the message
above contains a large value in the GIOP header, which leads the ORB
to request the allocation of a very large buffer to contain the
request, which the operating system refuses, but the ORB doesn't check
for failure, tries to use the buffer, and is aborted by the operating
system for a segmentation violation.

There are numerous other facets to an implementation's robustness, such
as its response to unexpected behaviour of the operating system (does
it check all possible return codes from each system call?), its
response to invalid messages at the GIOP level (for instance, does it
crash when you send it lots of message fragments?), its response to
corrupted object references embedded in requests, etc.

Dependability benchmarking is more difficult than performance
benchmarking (which is already notorious for the ability to produce
meaningless results), but I would argue that for many of the
situations where CORBA is now used (command-control systems, telecom
supervision systems etc) robustness is at least as important as
performance.


[BTW I haven't run any robustness tests on ICE, so I can't contribute
to that aspect of the flamewar debate. I can however say that
ORBacus/C++ (to which Michi was a major contributor) is one of the
most robust CORBA implementations that I tested; omniORB isn't far
behind.]

--
Eric Marsden <URL:http://www.laas.fr/~emarsden/>

Michi Henning

unread,
Mar 15, 2004, 6:56:18 AM3/15/04
to
"Eric Marsden" <emar...@laas.fr> wrote in message
news:wzi3c8a...@melbourne.laas.fr...

> Quite a few ORBs have vulnerabilities in their marshalling code that
> make it possible for a remote attacker immediately to crash the
> process that hosts CORBA objects. For instance, a simple unix command
>
> perl -e 'print pack("H*", "47494F50010201006C000080"), "\n"' \
> | telnet <machine> <port>
>
> is sufficient to crash an application hosted using TAO version 1.2.1,
> and similar (though longer) corrupt messages provoke crashes in
> current versions of TAO, in MICO, in ORBit, in ORBacus/C++ etc.

Yes. The unmarshaling code has to be very defensive, holding everything
at arm's length because the packets that arrive may have deliberately
been crafted to be malicious. Generally, it's not too hard to be robust.
The main danger is buffer overruns -- the marshaling code has to make
sure that it never reads or writes beyond the end of a buffer. With the
proper abstractions, that's quite easy to ensure but, unfortunately,
slows the marshaling code down a little because it must repeatedly
check that it is still within buffer bounds.

> The
> vulnerabilities are generally due to the ORB being too trusting of
> data while unmarshalling the IIOP stream; for instance the message
> above contains a large value in the GIOP header, which leads the ORB
> to request the allocation of a very large buffer to contain the
> request, which the operating system refuses, but the ORB doesn't check
> for failure, tries to use the buffer, and is aborted by the operating
> system for a segmentation violation.

Well, that's a plain bug -- the code shouldn't assume that an allocation will
succeed, especially when the amount of memory that was requested comes
from a packet sent by a potentially hostile machine.

> There are numerous other facets to an implementation's robustness, such
> as its response to unexpected behaviour of the operating system (does
> it check all possible return codes from each system call?), its
> response to invalid messages at the GIOP level (for instance, does it
> crash when you send it lots of message fragments?), its response to
> corrupted object references embedded in requests, etc.

Yes. These are all quality-of-implementation issues. It's possible to guard
against all these errors, but it's not simple and requires a lot of attention
to
detail.

> [BTW I haven't run any robustness tests on ICE, so I can't contribute
> to that aspect of the flamewar debate.

The unmarshaling code in Ice is robust. Buffer overruns are impossible
due to the way the data is handled. Ice allows you to configure maximum
request sizes, so any request that is larger than the limit, or any
variable-length
data item that would exceed the limit, are simply rejected. This limits the
amount of memory that a request can allocate to the configured limit.
In turn, that makes it impossible for attacks to kill a machine by simply
asking for insane amounts of memory and consuming all available
swap space.

> I can however say that
> ORBacus/C++ (to which Michi was a major contributor) is one of the
> most robust CORBA implementations that I tested; omniORB isn't far
> behind.]

Thanks. Actually, I wrote little of the ORBacus code -- back then, I was
doing mostly the training and documentation, plus a lot of OMG work, so
the credit has to go to my collegues. Fortunately, that's changed for Ice --
I've written (and am still writing) lots of code for Ice. It's fun :-)

ORBacus did a pretty good job protecting itself against marshaling errors,
although, as you say above, it seems that something fell through the cracks.
Fortunately, because the Ice protocol is a lot simpler than IIOP, it's easier
for us to convince ourselves that the code is correct, and it's less likely
for bugs to creep in in the first place.

Eric Marsden

unread,
Mar 15, 2004, 7:27:30 AM3/15/04
to
>>>>> "mh" == Michi Henning <mi...@triodia.com> writes:

mh> Yes. The unmarshaling code has to be very defensive, holding
mh> everything at arm's length because the packets that arrive may
mh> have deliberately been crafted to be malicious. Generally, it's
mh> not too hard to be robust.

it requires a lot of rigour and attention to detail, which may not be
intrinsically hard, but are disappointingly rare in practice. It's
compounded (in my opinion) by primitive programming languages and
runtimes that require programmers to manage memory manually, offer
poor support for abstraction and for error handling.

The problem is probably exacerbated by the fact that it's difficult to
measure the robustness (or more generally the quality) of a software
component, which means that developers have little incentive to pay
attention to it: deadlines, feature enhancements and performance are
more important to them.


mh> slows the marshaling code down a little because it must repeatedly
mh> check that it is still within buffer bounds.

yep, dependability always has a cost: more expensive to build, more
expensive to run. It's up to clients to make it clear that they are
prepared to pay these costs.


mh> ORBacus did a pretty good job protecting itself against
mh> marshaling errors, although, as you say above, it seems that
mh> something fell through the cracks.

the problem I detected in ORBacus demarshalling seems (from analyzing
stack backtraces and looking at the source code) to be due to a bug in
g++, the C++ compiler+runtime that I used. ORBacus' buffer management
uses C++ templates, and it seems that an allocation failure was not
correctly signaled as a C++ exception, that would have been caught by
ORBacus. Possibly this is fixed in recent versions of GCC.

Michi Henning

unread,
Mar 15, 2004, 7:56:51 AM3/15/04
to
"Eric Marsden" <emar...@laas.fr> wrote in message
news:wzillm2...@melbourne.laas.fr...

> the problem I detected in ORBacus demarshalling seems (from analyzing
> stack backtraces and looking at the source code) to be due to a bug in
> g++, the C++ compiler+runtime that I used. ORBacus' buffer management
> uses C++ templates, and it seems that an allocation failure was not
> correctly signaled as a C++ exception, that would have been caught by
> ORBacus. Possibly this is fixed in recent versions of GCC.

Ah, good. Seems like we are redeemed then :-)

Marc Laukien

unread,
Mar 15, 2004, 2:10:48 PM3/15/04
to
Douglas C. Schmidt wrote:

>>>As for the comparison with TAO, it would be interesting to see how
>>>Ice 1.3.0 compares with the latest version of TAO. Perhaps we could
>>>ask Gautam to run a new test?
>
>
> Sure, that would be great. Our research
> <http://www.cs.wustl.edu/~schmidt/corba-research.html> has shown for
> years that the performance of distributed object computing middleware
> like CORBA is largely an implementation detail. A healthy
> "benchmark-driven" competition between middleware is a good way to
> improve performance for everyone, just like it is in the compiler
> world.
>
> Keep in mind, BTW, that I'm not claiming that ICE is slow - I'm
> simplying providing well-established empirical evidence that the ICE
> team's claim that CORBA is somehow inherently big/slow is marketing
> hype that's not supported by actual studies that compare ICE with
> standard ORBs.

Just FYI: We ran a very simple latency test today, to compare Ice with
TAO. We used the tests $ICE_HOME/demo/Ice/latency and
$TAO_ROOT/performance_test/Latency/Ice_Single_Threaded, respectively.
The latter we modified as follows:

- We reduced the 100 ping warm-up to just one ping.
- We reduced the total number of pings from 250,000 to 100,000.
- We changed the return value to void.
- We removed the parameter.
- We simplified the iteration to not collect timing per-invocation.

We applied these changes so that the test is equivalent to the Ice test.
We run each test 10 times, and took the best result out of these 10 runs.

Here are the results:

Ice 1.3 without NPTL: 0.082 ms
Ice 1.3 with NPTL: 0.078ms

TAO 1.4 without NPTL: 0.107ms
TAO 1.4 with NPTL: 0.099ms

Both TAO and Ice were compiled with -O3 (no -g). Otherwise we used the
default configuration for both TAO and Ice. The test was performed on a
Dual Xeon 2.8GHz with RedHat 9 (2.4.20-20.9smp).

I hope that an independent third party will confirm these results.

Let me point out again that I believe that latency is only one factor
out of many which are important. In general, I think it's pointless to
just look at latency or marshaling speed to determine the overall
performance of a middleware platform.

A much more interesting test would for example be to compare the
performance of message forwarding in the context of an event service.
Given that Ice does not have to unmarshal and remarshal Anys, I expect
Ice to be a lot faster than CORBA implementations.

Another interesting performance test would be to use slow connections,
such as DSL or Cable Modem. Here the more compact data encoding of the
Ice protocol, and especially the built-in bzip2 compression, are a huge
advantage.

-- Marc

Christopher Browne

unread,
Mar 15, 2004, 3:52:30 PM3/15/04
to
Quoth Marc Laukien <ma...@zeroc.com>:

Hmm. So this means that despite having apparently vast advantages,
there is _maybe_ a 20% improvement in latency.

We lose portability, but gain a little bit of speed.

Furthermore, that does not provide any comparison against SOAP, RMI,
XML-RPC, or others of the would-be "competition."

I expect that what we would discover, in a more widely ranging
comparison, is that CORBA is like greased lightning compared to nearly
all of its competitors; that it is much lighter weight than nearly all
of its competitors, and that in a few cases, there can be relatively
minor marginal gains attained by using nonstandard nonportable
protocols.
--
If this was helpful, <http://svcs.affero.net/rm.php?r=cbbrowne> rate me
http://www.ntlug.org/~cbbrowne/corba.html
Rules of the Evil Overlord #97. "My dungeon cells will not be
furnished with objects that contain reflective surfaces or anything
that can be unravelled." <http://www.eviloverlord.com/>

Marc Laukien

unread,
Mar 15, 2004, 4:24:32 PM3/15/04
to
> Hmm. So this means that despite having apparently vast advantages,
> there is _maybe_ a 20% improvement in latency.
>
> We lose portability, but gain a little bit of speed.

No, the 20% speed gain has nothing to do with Ice vs. CORBA. For a
simple latency test such as this, the marshaling format or the protocol
doesn't matter much. Good latency is a matter of good software
engineering, regardless of whether it's Ice or CORBA.

The advantage of Ice is not latency. However, since Doug is apparently
so obsessed with latency that he uses it every time to "debunk claims"
which we never made, I felt that it would be important to set the record
straight, and show that latency in Ice is quite good. (But not as good
as some high-quality real-time CORBA ORBs, such as ORBexpress.)

Ice has many other advantages. Most of them don't have to do with
performance at all, but rather with ease of use. I really don't think it
makes sense if I repeat all of them here again. Please see the various
other posts by Michi or myself, or have a look at our Web page and the
Ice manual. (http://www.zeroc.com)

>
> Furthermore, that does not provide any comparison against SOAP, RMI,
> XML-RPC, or others of the would-be "competition."

No, of course not.

>
> I expect that what we would discover, in a more widely ranging
> comparison, is that CORBA is like greased lightning compared to nearly
> all of its competitors; that it is much lighter weight than nearly all
> of its competitors, and that in a few cases, there can be relatively
> minor marginal gains attained by using nonstandard nonportable
> protocols.

With respect to performance, I'm convinced that both CORBA and Ice beat
the XML-based RPC mechanism by a wide margin.

-- Marc

Christopher Browne

unread,
Mar 15, 2004, 5:52:49 PM3/15/04
to
After takin a swig o' Arrakan spice grog, Marc Laukien <ma...@zeroc.com> belched out:

>> Furthermore, that does not provide any comparison against SOAP, RMI,
>> XML-RPC, or others of the would-be "competition."
>
> No, of course not.

That was, of course, the reason for the discussion. The original
poster had heard that "CORBA is horribly bloated and is just too much
for small distributed applications."

>> I expect that what we would discover, in a more widely ranging


>> comparison, is that CORBA is like greased lightning compared to nearly
>> all of its competitors; that it is much lighter weight than nearly all
>> of its competitors, and that in a few cases, there can be relatively
>> minor marginal gains attained by using nonstandard nonportable
>> protocols.
>
> With respect to performance, I'm convinced that both CORBA and Ice
> beat the XML-based RPC mechanism by a wide margin.

I would think so too. That _is_ the point of the comparison; the
O.P. was interested in:
a) SOAP
b) CORBA
c) Jabber.
--
wm(X,Y):-write(X),write('@'),write(Y). wm('cbbrowne','cbbrowne.com').
http://www.ntlug.org/~cbbrowne/internet.html
Rules of the Evil Overlord #146. "If my surveillance reports any
un-manned or seemingly innocent ships found where they are not
supposed to be, they will be immediately vaporized instead of brought
in for salvage." <http://www.eviloverlord.com/>

Jan Kleinsorge

unread,
Mar 15, 2004, 7:13:35 PM3/15/04
to

"Christopher Browne" <cbbr...@acm.org> schrieb im Newsbeitrag
news:c35c41$23uhe1$1...@ID-125932.news.uni-berlin.de...

> After takin a swig o' Arrakan spice grog, Marc Laukien <ma...@zeroc.com>
belched out:
> >> Furthermore, that does not provide any comparison against SOAP, RMI,
> >> XML-RPC, or others of the would-be "competition."
> >
> > No, of course not.
>
> That was, of course, the reason for the discussion. The original
> poster had heard that "CORBA is horribly bloated and is just too much
> for small distributed applications."
>
> >> I expect that what we would discover, in a more widely ranging
> >> comparison, is that CORBA is like greased lightning compared to nearly
> >> all of its competitors; that it is much lighter weight than nearly all
> >> of its competitors, and that in a few cases, there can be relatively
> >> minor marginal gains attained by using nonstandard nonportable
> >> protocols.
> >
> > With respect to performance, I'm convinced that both CORBA and Ice
> > beat the XML-based RPC mechanism by a wide margin.
>
> I would think so too. That _is_ the point of the comparison; the
> O.P. was interested in:
> a) SOAP
> b) CORBA
> c) Jabber.
> --

That is exactly the point. I was watching the discussion with great interest
and it
helped to come to a conclusion, although it partly became I little bit
off-topic ;)
Personally I'm glad to see that with ICE there seems to be a competitor
to CORBA which is taken quite seriously.

Thank you


Jan


Ke Jin

unread,
Mar 15, 2004, 8:28:42 PM3/15/04
to
Marc Laukien <ma...@zeroc.com> wrote in message news:<bq6dnUq_DIx...@speakeasy.net>...

>
> A much more interesting test would for example be to compare the
> performance of message forwarding in the context of an event service.
> Given that Ice does not have to unmarshal and remarshal Anys, I expect
> Ice to be a lot faster than CORBA implementations.

OMG does not require a "Event Service" to unmarshal/remarshal Anys!!
VisiNotify has supported directly event forwarding in event service
for two years.

>
> Another interesting performance test would be to use slow connections,
> such as DSL or Cable Modem. Here the more compact data encoding of the
> Ice protocol, and especially the built-in bzip2 compression, are a huge
> advantage.

OMG never mandates a compliant ORB implementation could only use
GIOP/IIOP. Within an ORB interoperate domain, an ORB can use whatever
protocol it likes.
Even if GIOP on top and TCP on botten are given, in a given ORB
interoperable domain, an ORB still can freely add compression layer,
encryption layer or monitoring layer between them. Similar to the the
way ORB implementations add SSL data encryption between GIOP and TCP
layers. These layers can easily be added by application developers
using plugable transport support, or by ORB vendors in more efficient
and tightly integrated approach.

Regards,
Ke

>
> -- Marc

Michi Henning

unread,
Mar 15, 2004, 11:40:16 PM3/15/04
to
On 15 Mar 2004, Ke Jin wrote:

>> Given that Ice does not have to unmarshal and remarshal Anys,
>> I expect Ice to be a lot faster than CORBA implementations.
>
> OMG does not require a "Event Service" to unmarshal/remarshal Anys!!
> VisiNotify has supported directly event forwarding in event
> service for two years.

I am aware of the Visibroker implementation of the Notification
Service. (For those interested, a white paper can be found at
http://www.borland.com/products/white_papers/pdf/corba_borland_notification_services.pdf.)

But, to be fair, I'd like to point out a few technical details
regarding this. It is possible to build a CORBA event service
that can unmarshal and remarshal events without marshaling through
the TypeCode and the data inside the Any. However, this optimization
applies only in one very specific case and is useless in the
general case. In particular, it is useless to CORBA applications:

1) To pick an Any off the wire without marshaling through it, I need
to know where the Any starts and ends. For a single-parameter
method that transmits a single Any value, that is possible: I can
work out where in the receive buffer the value starts (on the first
4-byte boundary following the request header), and I know from
the message header how long the entire request is, so I can work
out where the end of the Any value is.

However, this is possible only for single-parameter methods. As
soon as an Any is preceded or followed by something else (in
particular, something that has variable length), this trick no
longer works.

2) The relevant APIs to implement an event service as you suggest
do not exist in the CORBA spec. In effect, avoiding unmarshaling
and remarshaling amounts to writing a special-purpose
marshaling engine for a CORBA event service. This cannot be
done without access to the ORB's source code (or without writing
the whole protocol stack by hand).

3) The technique only applies to GIOP version 1.2 and 1.3. For 1.0
and 1.1, the request body is not aligned on an 8-byte boundary,
so remarhaling in this fashion simply fails because that can
violate CDR alignment rules. This means that VisiNotify must
disable the optimization for any consumers that are using
IIOP 1.0 or 1.1.

4) If the sender and the receiver of an event have opposite
endian-ness, the service implementation must be careful
to send a request header to each down-stream receiver that
matches the endian-ness of the data inside the Any. Of
course, no standard API is available to do this, and it makes
the endian-ness of a message context-sensitive because the
forwarder can no longer simply send messages in its native
byte order.

So, in summary, the technique applies only to methods that take a
single Any parameter and requires special-purpose modifications
to the ORB internals, and only works with IIOP 1.2 and 1.3.
If an application sends Any values, or if an Any parameter is
preceeded or followed by other parameters, the optimization does
not apply. This makes the optimization completely useless in
the general case.

And, of course, with a properly designed protocol, no such
optimization is necessary. With the correct design,
event forwarding (or, more generally, request forwarding)
automatically avoids unmarshaling and remarshaling cost, so
all applications benefit without additional effort, or an
ORB-internal special-case implementation.

With the Ice protocol, any request with any number of parameters
of any type can be received and re-sent without marshaling and
remarshaling, via a public API known as "Blobjects". This is
possible because the Ice protocol encapsulates things where
necessary, so they can be treated as an opaque blob. Because
there are no alignment restrictions, and because everything
is marshaled in a fixed byte order, nothing is context-sensitive
either. The receiver simply grabs a request as an opaque blob of
bytes off the wire and throws it out on another wire. This always
works, regardless of the number or type of the parameters.

>> Another interesting performance test would be to use slow connections,
>> such as DSL or Cable Modem. Here the more compact
>> data encoding of the Ice protocol, and especially the built-in bzip2
>> compression, are a huge advantage.
>
> OMG never mandates a compliant ORB implementation could only use GIOP/IIOP.
> Within an ORB interoperate domain, an ORB can use whatever protocol it likes.

Sure. But I thought the discussion was about IIOP and the Ice protocol,
not about some fictitious protocol that an ORB might use.

Cheers,

Michi.

Duncan Grisby

unread,
Mar 16, 2004, 5:46:25 AM3/16/04
to
In article <wzi3c8a...@melbourne.laas.fr>,
Eric Marsden <emar...@laas.fr> wrote:

>Quite a few ORBs have vulnerabilities in their marshalling code that
>make it possible for a remote attacker immediately to crash the
>process that hosts CORBA objects.

This sounds like a very valuable bit of research. Have you reported
your findings to the maintainers of the CORBA implementations you have
tested? As the omniORB maintainer, I would certainly consider any
problems you have found with that to be bugs that should be fixed as
soon as possible.

Cheers,

Duncan.

--
-- Duncan Grisby --
-- dun...@grisby.org --
-- http://www.grisby.org --

Douglas C. Schmidt

unread,
Mar 16, 2004, 8:42:24 AM3/16/04
to
Hi Duncan,

>> This sounds like a very valuable bit of research. Have you reported
>> your findings to the maintainers of the CORBA implementations you
>> have tested?

Check out

http://www.laas.fr/~emarsden/research/

for info on some papers that Eric published on these topics. We just
came upon these recently and are planning on integrating these
capabilities into a open-source tool we're developing that can be used
to evaluate ORB robustness.

Eric Marsden

unread,
Mar 16, 2004, 11:04:35 AM3/16/04
to
>>>>> "dg" == Duncan Grisby <dunca...@grisby.org> writes:

dg> This sounds like a very valuable bit of research. Have you
dg> reported your findings to the maintainers of the CORBA
dg> implementations you have tested? As the omniORB maintainer, I
dg> would certainly consider any problems you have found with that
dg> to be bugs that should be fixed as soon as possible.

I haven't done so yet, because this means checking the latest
release, attempting to fix, rerunning the robustness tests and
submitting patches, but I do intend to do so now that I've defended
my PhD.


>>>>> "ds" == Douglas C Schmidt <sch...@ace.cs.wustl.edu> writes:

ds> http://www.laas.fr/~emarsden/research/
ds>
ds> for info on some papers that Eric published on these topics.

parts of my work on GIOP-level corruptions, error propagation from
the operating system and code mutation techniques are not yet
published, but I'm working on it.

ds> came upon these recently and are planning on integrating these
ds> capabilities into a open-source tool we're developing that can
ds> be used to evaluate ORB robustness.

that sounds great! I think there is a need for tools of this nature,
but my current testbed is somewhat lacking in documentation and
user-friendliness.

Dilip

unread,
Mar 16, 2004, 3:46:24 PM3/16/04
to
"Michi Henning" <mi...@triodia.com> wrote in message

> And the notion of using XML (a document description language) to
> do RPC is simply misguided, IMO, and was born of political
> considerations rather than technical ones.

> I also don't see the often-touted "simplicity" of Web Services.
> Take any simple IDL definition and look at the XML to define
> the equivalent types for Web Services. I don't have
> to think long before I know which one is simpler...

> And as for the arguments as to the readability of SOAP and
> the self-describing nature of XML, they are simply ill-informed
> and miss the point.
>

> I see the Web Services crowd re-inventing the wheel from scratch....


>
> To me, CORBA provides a far better option than Web Services/SOAP.

Michi, come on! You are doing it again. Many times in the past it
has been pointed out to you nobody is thinking of reinventing RPC
using angle brackets, most notably by Dr. Gerald Brose. Plus no one
to my knowledge in the XML space have claimed they want to use a
text-based payload because they are self-describing. And lastly Web
Services are *NOT* distributed objects and you know that very well
Michi.

Maybe you will cut some slack if you read this:
http://weblogs.cs.cornell.edu/AllThingsDistributed/archives/000343.html

--Dilip

Dilip

unread,
Mar 16, 2004, 3:46:33 PM3/16/04
to
"Michi Henning" <mi...@triodia.com> wrote in message

> And the notion of using XML (a document description language) to


> do RPC is simply misguided, IMO, and was born of political
> considerations rather than technical ones.

> I also don't see the often-touted "simplicity" of Web Services.
> Take any simple IDL definition and look at the XML to define
> the equivalent types for Web Services. I don't have
> to think long before I know which one is simpler...

> And as for the arguments as to the readability of SOAP and
> the self-describing nature of XML, they are simply ill-informed
> and miss the point.
>

> I see the Web Services crowd re-inventing the wheel from scratch....


>
> To me, CORBA provides a far better option than Web Services/SOAP.

Michi, come on! You are doing it again. Many times in the past it

Ke Jin

unread,
Mar 16, 2004, 4:45:08 PM3/16/04
to
Michi Henning <mi...@triodia.com> wrote in message news:<Pine.LNX.4.44.040316...@diadora.client.uq.net.au>...

> On 15 Mar 2004, Ke Jin wrote:
>
> >> Given that Ice does not have to unmarshal and remarshal Anys,
> >> I expect Ice to be a lot faster than CORBA implementations.
> >
> > OMG does not require a "Event Service" to unmarshal/remarshal Anys!!
> > VisiNotify has supported directly event forwarding in event
> > service for two years.
>
> I am aware of the Visibroker implementation of the Notification
> Service. (For those interested, a white paper can be found at
> http://www.borland.com/products/white_papers/pdf/corba_borland_notification_services.pdf.)
>
> But, to be fair, I'd like to point out a few technical details
> regarding this. It is possible to build a CORBA event service
> that can unmarshal and remarshal events without marshaling through
> the TypeCode and the data inside the Any. However, this optimization
> applies only in one very specific case and is useless in the
> general case. In particular, it is useless to CORBA applications:

Sorry, your judgement is wrong. This technique applies to almost all
general cases. For instance, it applies to structured and typed
events, where an event can contain arbitrary number of Anys or even
valuetypes. VisiNotify is shipped with various examples covering many
cases that you claimed this technique wouldn't apply.

>
> 1) To pick an Any off the wire without marshaling through it, I need
> to know where the Any starts and ends. For a single-parameter
> method that transmits a single Any value, that is possible: I can
> work out where in the receive buffer the value starts (on the first
> 4-byte boundary following the request header), and I know from
> the message header how long the entire request is, so I can work
> out where the end of the Any value is.
>
> However, this is possible only for single-parameter methods. As
> soon as an Any is preceded or followed by something else (in
> particular, something that has variable length), this trick no
> longer works.

VisiNotify doesn't pick Anys off the wire, it picks a entire message
and doesn't care how many Anys it containes. VisiNotify directly
forward entire messages, rather than forwarding individual Any or
Anys. The only cases it needs to pick Anys out of a message are:

* it needs to evalutate events for filtering or event level QoS (only
demarshal)
* it needs to do event translation (demarshal and remarshal).
* it needs to concatenate sequence events (demarshal and remarshal).

I don't see ICE can avoid demarsal/remarshal in above cases (except
for sequence event concatenation)!

Also, for general application cases, the actual costing part of Any
marshal/demarshal is on complex typecode, rather than on simple
typecode or on the encoded value. Even if demarshal and remarshal on a
Any with complex typecode is needed, a decent CORBA implementation,
such as VisiBroker, will not demarshal and remarshal every complex
typecode it received. Complex typecodes are already defined as
encapsulation in CORBA! Therefore, regardless how expensive, it is at
most a one time cost for each new complex typecode.

>
> 2) The relevant APIs to implement an event service as you suggest
> do not exist in the CORBA spec. In effect, avoiding unmarshaling
> and remarshaling amounts to writing a special-purpose
> marshaling engine for a CORBA event service. This cannot be
> done without access to the ORB's source code (or without writing
> the whole protocol stack by hand).

First, if you write a Java implementation, you should be able to do it
with OMG standardized API.

Second, I don't see a notification service implementation that
integrated with ORB is a disadvantage or bad design. Why an
notification application would care how it was implemented? And also,
OMG never specifies the notification service should only be
implemented on user level, but not on ORB level. Most implementations
happen to be built on user level is merely b/c they can be done
easily, rather than correctly.

Third, this design isn't something new. Many other similar CORBA
features, such as OMG firewall proxy, are mostly implemented in the
same way and tightly integrated with a specific ORB.

>
> 3) The technique only applies to GIOP version 1.2 and 1.3. For 1.0
> and 1.1, the request body is not aligned on an 8-byte boundary,
> so remarhaling in this fashion simply fails because that can
> violate CDR alignment rules. This means that VisiNotify must
> disable the optimization for any consumers that are using
> IIOP 1.0 or 1.1.

You are wrong again! GIOP 1.2 just makes it easy to implement direct
message forward. It doesn't mean it can not be done with GIOP 1.0.
Don't you know people were able to implement GIOP firewall proxy,
which directly forward GIOP 1.0 request/reply, before CORBA 2.3
introduced GIOP 1.2? In fact, when we did the implementation, we
examined much more backward/forward interoperating issues then you
throught, including GIOP 1.0/1.1, cross interoperating, typed channel,
structured channel, push and pull, etc..

To be specific, VisiNotify does not need to disable message forward
when GIOP 1.0/1.1 suppliers and/or consumers are involved. Pls
download an eval version and do you own test. You can send a bogus Any
(an Any with undefined typecode) through a VN channel from a supplier
using GIOP 1.0. If VN did demarshal/remarshal, it would not able to
pass this bogus Any through the channel.

Also, it is very funny you brought up GIOP 1.0/1.1 as an negative
evidence here. Even if a notification implementation were not able to
forward mesasge in case of GIOP 1.0/1.1, it wouldn't imply ice was
superior. For legacy applications, at most, one just upgrade their
ORBs from using GIOP 1.0 to 1.2 exclusively. How would your ICE help
those applications already running on top of GIOP 1.0 ORBs? Are they
interoperable with ice without a upgrade?

OMG recoganized drawbacks of 1.0/1.1 long before you defined your
proprietary protocol. OMG's solution is upgrade the protocol and
retain application portability, at least. And your approach is
redefine everything from scratch. For interoperating with those
existing legacy applications, I don't see your approach is better then
OMG's.

>
> 4) If the sender and the receiver of an event have opposite
> endian-ness, the service implementation must be careful
> to send a request header to each down-stream receiver that
> matches the endian-ness of the data inside the Any. Of
> course, no standard API is available to do this, and it makes
> the endian-ness of a message context-sensitive because the
> forwarder can no longer simply send messages in its native
> byte order.

This is a trivial issue, with least challenge for any entry level
developer. The answer is, VisiNotify simply forwards messages in their
original byte orders. This technique isn't new. GIOP firewall proxy
deals with this same issue for at least 8 years.

>
> So, in summary, the technique applies only to methods that take a
> single Any parameter and requires special-purpose modifications
> to the ORB internals, and only works with IIOP 1.2 and 1.3.
> If an application sends Any values, or if an Any parameter is
> preceeded or followed by other parameters, the optimization does
> not apply. This makes the optimization completely useless in
> the general case.

Wrong! Pls download VisiNotify and test it. You would see it applies
to all your negative cases claimed above. To verify VN doesn't
demarshal/remarshal messages, you can send a bogus Any (a Any with
typecode not defined by OMG) through the channel.

>
> And, of course, with a properly designed protocol, no such
> optimization is necessary.

We don't call this "optimization". We call it a way to implement.

> With the correct design,
> event forwarding (or, more generally, request forwarding)
> automatically avoids unmarshaling and remarshaling cost, so
> all applications benefit without additional effort, or an
> ORB-internal special-case implementation.

Fine, so, you believe unable to direct forward mesasge is not a
restriction of GIOP protocol, but a feature not exposed to
applications via standardized CORBA API? Then, I will not argue with
you. B/c that will be a politic issue, rather than a technic issue.

Besides, we don't feel that be able to forward messages by a channel
is the only key issue of a notification implementation. Even if OMG
did define an API for message forwarding, there are still much more
critical issues a notification implementation needs to deal with.
Otherwise, a user level implementation will at most be a prototype or
an academic exercise. The complicity and low level nature of these
issues in an industry strengthed implementation are much more complex
than message forwarding. They are best to be developed by middleware
vendors, rather than average application developers.

>
> >> Another interesting performance test would be to use slow connections,
> >> such as DSL or Cable Modem. Here the more compact
> >> data encoding of the Ice protocol, and especially the built-in bzip2
> >> compression, are a huge advantage.
> >
> > OMG never mandates a compliant ORB implementation could only use GIOP/IIOP.
> > Within an ORB interoperate domain, an ORB can use whatever protocol it likes.
>
> Sure. But I thought the discussion was about IIOP and the Ice protocol,
> not about some fictitious protocol that an ORB might use.

I thought the discussion was about CORBA vs something non-CORBA. Also,
almost all CORBA implementations include some "fictitious" protocols
of their own. For instance, almost all ORB implementations will have
some kind optimized local IPC mechanism, rather than using IIOP on TCP
loopback.

Regards,
Ke

>
> Cheers,
>
> Michi.

Dilip

unread,
Mar 16, 2004, 4:49:00 PM3/16/04
to
"Michi Henning" <mi...@triodia.com> wrote in message > I've volunteered answers in the past in this group. To me,

> Web Services and SOAP are a bad idea. The cost of
> the protocol in terms of bandwidth and CPU cycles is
> obscene -- so much so that it becomes a dominant factor.
> And the notion of using XML (a document description language) to
> do RPC is simply misguided, IMO, and was born of political
> considerations rather than technical ones.

you should take a look at this paper:
http://www.theserverside.com/articles/content/NetKernel/article.html

There is no telling what people can come up with given sufficient
experience with any technology... (can someone say ICE?)

--Dilip

Michi Henning

unread,
Mar 16, 2004, 8:18:23 PM3/16/04
to
Ke Jin" <ke...@borland.com> wrote in message
news:887a1f78.04031...@posting.google.com...

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

> > However, this optimization


> > applies only in one very specific case and is useless in the
> > general case. In particular, it is useless to CORBA applications:
>
> Sorry, your judgement is wrong. This technique applies to almost all
> general cases.

I meant the "specific case of a notification or event service", not
specific cases of using such a service.

> For instance, it applies to structured and typed
> events, where an event can contain arbitrary number of Anys or even
> valuetypes. VisiNotify is shipped with various examples covering many
> cases that you claimed this technique wouldn't apply.

I'm sorry, but I don't understand... Suppose I have the following operation:

void op(in string s2, in any a, in string s2);

I don't see how I can possibly pick off the Any value in this
request without marshaling through the Any -- without doing
this, I have no idea where in the byte stream parameter s2 starts.

> VisiNotify doesn't pick Anys off the wire, it picks a entire message
> and doesn't care how many Anys it containes. VisiNotify directly
> forward entire messages, rather than forwarding individual Any or
> Anys.

OK. There are still few cases I don't understand though. For
example, what if the sender and receiver don't use the same
codeset and the Any contains character or string data?

> The only cases it needs to pick Anys out of a message are:
>
> * it needs to evalutate events for filtering or event level QoS (only
> demarshal)
> * it needs to do event translation (demarshal and remarshal).
> * it needs to concatenate sequence events (demarshal and remarshal).
> I don't see ICE can avoid demarsal/remarshal in above cases (except
> for sequence event concatenation)!

Obviously, unmarshaling is unavoidable for translation because
the service must re-write the data. (BTW -- I've never seen
a compelling use case for translation. Is there one? Is the use case
frequent enough to justify the existence of the feature in the service?)

For filtering, Ice doesn't filter on the request parameters, but on
the request context (not to be confused with IDL contexts.)
For concatenation, Ice batches multiple requests into a single message,
which GIOP cannot do, so neither of these cases requires
unmarshaling and remarshaling.

But this isn't what I was concerned about. My concern is with
marshaling of Anys in the general case, not just for the event or
the notification service. Suppose I write:

interface MichisEventChannel {
void send(in any a);
any receive();
};

I don't see how this can possibly benefit from your technique. After all,
I can only use the CORBA APIs. That's what I meant in
that the technique is not useful in the general case. At the very
least, what is missing is an API that would allow me to treat the
payload of a message as a blob and to re-send that payload
in another message to another receiver.

> Also, for general application cases, the actual costing part of Any
> marshal/demarshal is on complex typecode, rather than on simple
> typecode or on the encoded value. Even if demarshal and remarshal on a
> Any with complex typecode is needed, a decent CORBA implementation,
> such as VisiBroker, will not demarshal and remarshal every complex
> typecode it received. Complex typecodes are already defined as
> encapsulation in CORBA! Therefore, regardless how expensive, it is at
> most a one time cost for each new complex typecode.

Hmmm... I need to understand what you are getting at here. In general, if a
TypeCode arrives on the wire, I can only find out what type it denotes
by looking at the contents of the type code. So, I don't see immediately
how VisiNotify could recognize that some complex TypeCode that
arrives on the wire is the same as a TypeCode that was received previously.

Of course, it is possible to come up with TypeCode caching schemes
that avoid retransmission or remarshaling, but that wouldn't be IIOP anymore
then, would it?

I can look at the TCKind enumerator at the beginning of the
TypeCode and, if the TypeCode is for a complex type, look at
the repository ID to check whether I have seen this TypeCode
before. But the repository ID isn't guaranteed to be available
prior to IIOP 1.2, so this technique works only if a
repository ID is actually present, no?

> > 2) The relevant APIs to implement an event service as you suggest
> > do not exist in the CORBA spec. In effect, avoiding unmarshaling
> > and remarshaling amounts to writing a special-purpose
> > marshaling engine for a CORBA event service. This cannot be
> > done without access to the ORB's source code (or without writing
> > the whole protocol stack by hand).
>
> First, if you write a Java implementation, you should be able to do it
> with OMG standardized API.

I hadn't considered that you might be able to do this in Java. Interesting
idea. Would be nice though if I could do this in any language. And,
certainly, the complexity of doing this correctly would be beyond
many CORBA users. Even if it isn't beyond them, I can't see
CORBA developers ever doing this. After all, they are using
CORBA to avoid having to deal with all the low-level protocol
stuff...

> Second, I don't see a notification service implementation that
> integrated with ORB is a disadvantage or bad design. Why an
> notification application would care how it was implemented?

I completely agree with you there and I wasn't suggesting that the
service is badly designed. What I did suggest is that, with a properly
designed protocol, all this effort would be unnecessary -- Any values would
be encapsulated, so I could pick them off the wire even when they are
surrounded by other parameters, and I would have an API that would
allow me to forward request payloads as a blob at user level.

There are scenarios where applications want to forward event-like
data without having to use a full-blown event or notification service
(both of which have atrociously designed APIs). It would be
nice if applications could do this as efficiently as a full-blown
service.

> And also,
> OMG never specifies the notification service should only be
> implemented on user level, but not on ORB level. Most implementations
> happen to be built on user level is merely b/c they can be done
> easily, rather than correctly.

Right. With the right protocol and API though, I could do it at user
level, and just about as efficiently.

> Third, this design isn't something new. Many other similar CORBA
> features, such as OMG firewall proxy, are mostly implemented in the
> same way and tightly integrated with a specific ORB.

I don't really see anything good about that. If the firewall has to be
implemented inside the ORB, third parties can't deliver the firewall as a
third-party add-on, and power users cannot write a firewall
themselves. For example, the customer may not want to trust
the ORB vendor, or may have a special-purpose security
infrastructure that they need to integrate with (as is often the case
for banking or military applications).

I should be able to build the firewall at user-level like everything
else, and I should be able to do that without undue complexity
or performance penalty. With proper protocol and API design,
that is quite possible (and that's how the the Ice firewall is
implemented).

The motivation for VisiNotify to do its work at the ORB
level is not that this is inherently desirable, but that
the poorly-designed protocol encourages doing it that way.
With a better protocol and an appropriate API, it could
be done at user level instead.

> > 3) The technique only applies to GIOP version 1.2 and 1.3. For 1.0
> > and 1.1, the request body is not aligned on an 8-byte boundary,
> > so remarhaling in this fashion simply fails because that can
> > violate CDR alignment rules. This means that VisiNotify must
> > disable the optimization for any consumers that are using
> > IIOP 1.0 or 1.1.
>
> You are wrong again! GIOP 1.2 just makes it easy to implement direct
> message forward. It doesn't mean it can not be done with GIOP 1.0.

I'm confused here. Maybe I've missed something. The case I have in
mind is an Any containing a double value (possibly nested inside some
other data structure). Doubles must be aligned on an 8-byte boundary.
Prior to GIOP 1.2, the request body was aligned on a 4-byte boundary.
So, if I forward a request that was sent by a 1.0 sender to a 1.2
receiver, the double could end up on the wrong byte boundary, depending
on whether the sender's Any data was originally aligned on a 4-byte or
an 8-byte boundary.

Also, the header size may change because the object key of the receiver
may have a different length than the object key of the sender, again causing
a shift in alignment of the request body.

We changed the body alignment to 8 bytes with GIOP 1.2 specifically
to get rid of these scenarios. So, what am I missing?

> To be specific, VisiNotify does not need to disable message forward
> when GIOP 1.0/1.1 suppliers and/or consumers are involved.

I honestly don't see how this works, given the 8-byte/4-byte alignment
issue. Can you explain?

> OMG recoganized drawbacks of 1.0/1.1 long before you defined your
> proprietary protocol. OMG's solution is upgrade the protocol and
> retain application portability, at least.

Hmmm... Let's see. The OMG have changed the CDR encoding
with every dot release of CORBA. They changed alignment rules
and added new types, such as fixed-point, value types, the new
types introduced by the component model, etc., and there have been
numerous changes to the codeset negotiation. In fact,
CORBA can't interoperate with itself in some cases. For example,
if a CORBA 2.1 sender sends an Any to a 2.0 receiver, the receiver
gets a marshaling error if the Any contains one of the types introduced
later.

The problem really is that CDR encapsulations do not carry a separate
version number, and that things that should be encapsulated (such as
the data of an Any) are not encapsulated. There are as many different
and non-interoperable CDR encodings as there are dot releases of
CORBA. That doesn't strike me as retaining application portability,
to be honest.

> And your approach is
> redefine everything from scratch. For interoperating with those
> existing legacy applications, I don't see your approach is better then
> OMG's.

The Ice protocol has a well-defined versioning scheme, for each
the protocol state machine and the encoding rules. This allows
us to set up well-defined backward compatibility rules and to
properly diagnose incompatible versions at run time. For GIOP, the
way to notice that an incompatible version change has happend
is to get incomprehensible data when unmarshaling an encapsulation
or a type code.

> > 4) If the sender and the receiver of an event have opposite
> > endian-ness, the service implementation must be careful
> > to send a request header to each down-stream receiver that
> > matches the endian-ness of the data inside the Any. Of
> > course, no standard API is available to do this, and it makes
> > the endian-ness of a message context-sensitive because the
> > forwarder can no longer simply send messages in its native
> > byte order.
>
> This is a trivial issue, with least challenge for any entry level
> developer. The answer is, VisiNotify simply forwards messages in their
> original byte orders. This technique isn't new. GIOP firewall proxy
> deals with this same issue for at least 8 years.

Of course! Most everyone knows how to write the code for that.
The point is that I can't do it as a CORBA customer. And, even if
I could, I shouldn't have to do it -- there is no point in having
receiver-makes-it-right, other than to make things more complex.

> > This makes the optimization completely useless in
> > the general case.
>
> Wrong! Pls download VisiNotify and test it. You would see it applies
> to all your negative cases claimed above.

See above -- I'm not so much concerned with the event service specifically,
but with the inability for applications to forward things efficiently.
That's what I meant by the general case. I shouldn't have to be in a
privileged position with access to the ORB source code to be
able to do this.

> > And, of course, with a properly designed protocol, no such
> > optimization is necessary.
>
> We don't call this "optimization". We call it a way to implement.

I call it an optimization because it applies specifically
a particular service, with a-priori knowledge of that service's
semantics. If arbitrary applications could do what you have done
for VisiNotify, I would agree with you.

> > With the correct design,
> > event forwarding (or, more generally, request forwarding)
> > automatically avoids unmarshaling and remarshaling cost, so
> > all applications benefit without additional effort, or an
> > ORB-internal special-case implementation.
>
> Fine, so, you believe unable to direct forward mesasge is not a
> restriction of GIOP protocol, but a feature not exposed to
> applications via standardized CORBA API? Then, I will not argue with
> you. B/c that will be a politic issue, rather than a technic issue.

Well, yes, it *is* a political issue. That strikes me as sad. After all,
how to encode data on the wire should be a purely technical issue,
I would have thought, but history proves me wrong.

> Besides, we don't feel that be able to forward messages by a channel
> is the only key issue of a notification implementation. Even if OMG
> did define an API for message forwarding, there are still much more
> critical issues a notification implementation needs to deal with.

Absolutely. We built a notification service in our previous lives and are
well aware of the details.

> Otherwise, a user level implementation will at most be a prototype or
> an academic exercise.

The whole point of CORBA is that people can easily build *user-level*
implementations. GIOP extracts a far higher complexity penalty
than necessary and does not permit such user-level efficient
implementations.

> The complicity and low level nature of these
> issues in an industry strengthed implementation are much more complex
> than message forwarding. They are best to be developed by middleware
> vendors, rather than average application developers.

It's interesting to hear you say that a high-quality implementation is
best developed by ORB vendors. To me, a good platform
empowers the end users just as much as the implementors of the
platform.

GIOP is a horribly botched job that was designed by foul compromise,
and shaped by a war between the DCE and non-DCE factions in the
OMG. The result is a mess. The effects of the poor GIOP design
on the platform are with us to this day, and every single dot release
of CORBA has deemed it necessary to make changes to GIOP in
a futile attempt to get rid of some of the defects. With better design,
none of this would have been necessary.

Frank Pilhofer

unread,
Mar 16, 2004, 9:00:26 PM3/16/04
to
Eric Marsden <emar...@laas.fr> wrote:
>
> Quite a few ORBs have vulnerabilities in their marshalling code that
> make it possible for a remote attacker immediately to crash the
> process that hosts CORBA objects. For instance, a simple unix command
>
> perl -e 'print pack("H*", "47494F50010201006C000080"), "\n"' \
> | telnet <machine> <port>
>
> is sufficient to crash an application hosted using TAO version 1.2.1,
> and similar (though longer) corrupt messages provoke crashes in
> current versions of [...] MICO [...]
>

Note that Mico has a -ORBGIOPMaxSize command-line option to refuse
arbitrarily large GIOP packets, so "-ORBGIOPMaxSize 1M" should help.
Of course, it should handle memory allocation failures more gracefully,
so I would appreciate a bug report on the mico-devel mailing list.

Frank

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

Ever notice that to entertain some people all you have to do is
listen? - Alfred E. Neuman

Michi Henning

unread,
Mar 16, 2004, 9:11:34 PM3/16/04
to
"Dilip" <rdi...@lycos.com> wrote in message
news:8bc3089c.04031...@posting.google.com...

>
> Michi, come on! You are doing it again. Many times in the past it
> has been pointed out to you nobody is thinking of reinventing RPC
> using angle brackets, most notably by Dr. Gerald Brose.

Hmmm... We have remotely addressable entities that accept data
and return data. Looks a lot like RPC to me.

> Plus no one
> to my knowledge in the XML space have claimed they want to use a
> text-based payload because they are self-describing.

This argument was bandied about endlessly when SOAP was proposed
as a protocol, and is still being repeated today.

> And lastly Web
> Services are *NOT* distributed objects and you know that very well
> Michi.

Right, they are not. What they are is a primitive coarse-grained interaction
between remote entities. I can achieve precisely the same semantics
with a universal CORBA interface:

interface AnyWebService {
string doSomething(string uri, string xml_document);
};

To achieve that, we didn't need a new transport now, did we?

> Maybe you will cut some slack if you read this:
> http://weblogs.cs.cornell.edu/AllThingsDistributed/archives/000343.html

I'm familiar with this document. To quote some passages:

"Web services cannot offer any of the stateful distributed computing
facilities
that most distributed object systems support as basic functionality."

So I can't do stateful things with web services, only stateless things. With
distributed objects, I can do both stateful and stateless things.

"Basic Web services provide only a networking abstraction for transferring
XML documents and for a remote service entity to process them."

Last time I looked, any number of other things provided such an abstraction
too.
FTP comes to mind, for one thing.

"Internet-wide RPC has failed in the past, and Web services are not going
to
be much help in solving the issues."

So, we have to make do without internet-wide RPC for the foreseeable future?
But the reasoning for this statement is interesting:

"The Web services infrastructure provides no magic that can suddenly
overcome
what excellent protocol architects were unable to achieve with established
RPC systems or GIOP."

"Excellent protocol architects"? Don't make me laugh.

"Although Web services might solve some of the interoperability issues,
many
challenges remain. Synchronous interactions over wide-area networks are
not
scalable, for example, and large-scale versioning of procedure interfaces
is
extremely difficult."

Translation: "We avoided dealing with the difficult bits because it was easier
to reinvent the wheel."

"Over time, Web services will need to incorporate some of the basic
distributed
systems technologies that also underpin object systems, such as
guaranteed,
in-order, exactly-once message delivery."

Too right -- the wheel is only half finished.

"[...] we must add other technologies to build complex distributed
applications.
Over time, we will see that the issues vendors are now bickering about -
reliability, transactions, asynchronous processing, and so on - will
become
reality in an interoperable manner."

So, right now, I don't have reliabilty, transactions, and asynchronous
processing, but I'm supposed to use Web Services anyway, despite
the fact that these are apparently necessary to "build complex distributed
applications?" I can only conclude that Web Services are suitable only for
building simple distributed applications then.

"Given the strong similarities between Web services and distributed
objects,
it is understandable that many people believe they are the same. After
all, both
have some sort of description language, well- defined network
interactions, and
similar mechanisms for registering and discovering available components."

If they are so similar, it makes me wonder why we needed Web Services.

"[...] One thing to remember, however, is that Web services technology
is currently very limited."

Thanks for pointing that out -- I might have missed it in among all the hype
otherwise.

"Web services technology is still evolving, even at the most basic levels,
but many
vendors, trade magazines, and venture capitalists have already tagged the
technology
as the trigger for a new wave of applications, enabled by federated
interoperability."

That's right. The industry needed a saviour in the face of the general
computing industry
depression. I'm sure that a lot of people are glad that they have a "trigger
for a new
wave of applications" that all cost money to build.

"This early exposure has generated many incomplete and incorrect
publications, toolkit
releases that have little or no architectural vision, and fights among
different standardization
bodies seeking the right to control the underpinnings of Web services. The
waters are
further muddied by the fact that many of the vendors who jumped on board
to promote
Web services also have vested interests in Web and applications servers or
distributed
object technologies."

In other words, "reinventing a wheel is not easy because there are so many
conflicting
vested interests."

And this article is supposed to convince me of the value of Web Services? I
think not.

Michi Henning

unread,
Mar 16, 2004, 10:29:05 PM3/16/04
to
On 16 Mar 2004, Dilip wrote:

> you should take a look at this paper:
> http://www.theserverside.com/articles/content/NetKernel/article.html
>
> There is no telling what people can come up with given sufficient
> experience with any technology... (can someone say ICE?)

Right. An ingenious piece of work, created to make it more
palatable to live with the limitations of a particular technology.
What could have been achieved if the same brain cycles had been
spent on something else?

The stunning thing is that people argue that object technology
has failed as a universal platform for RPC and/or document exchange.

Let's see what people actually were given to work with:

- CORBA was complex and difficult to learn, did not cooperate
with firewalls and NAT boundaries, and had no built-in
encryption, making it useless over public insecure networks.

- DCOM had all of the same problems, plus a scalability problem
due to its distributed GC, and ran only on Microsoft platforms.

Then people argue that "object technology has failed" and use
that to push a completely new technology that does not have
objects. That's throwing out the baby with the bath water
and is one of the most retrograde steps in the history of computing.

*Of course* "object technology failed", given what people
were given to work with -- the object technologies that were tried
failed to address the most fundamental requirements of
commercial computing! And, despite the fact that Web
Services share many of the same shortcomings, much of the
industry follows regardless, like lemmings over a cliff.

Knowing that I am on record here and that newsgroup archives
have long memories, I make the following prediction:

Web Services will fail as a universally-accepted distributed
computing infrastructure just as much as DCOM and CORBA have.
When we eventually get a universally-accepted infrastructure
(and I believe we will), it will have at least the following
broad characteristics:

- It will be centered around objects.

- It will have an object addressing notion that hides
neither the identity nor the address of an object.

- It will have strong static typing.

- It will have a form of multiple interfaces to deal
with the versioning problem.

- It will use a highly-efficient binary protocol with
in-built support for compression.

- It will cooperate with firewalls and NAT boundaries.

- It will have built-in encryption to allow use over
insecure networks.

- It will have a built-in and selective garbage collection
mechanism to deal with the life cycle issues of
nominated stateful objects.

- It will have built-in support for RPC and XML-style
document exchange, as well as publish-subscribe
technology, with both synchronous and asynchronous
interaction.

- It will permit both stateful and stateless interactions.

- It will have built-in support for transactions.

I believe this to be quite a safe predition because failing to address
even one of these characteristics means the infrastructure will not
be accepted universally.

Ke Jin

unread,
Mar 17, 2004, 5:27:53 PM3/17/04
to
"Michi Henning" <mi...@triodia.com> wrote in message news:<zHN5c.106709$Wa.9...@news-server.bigpond.net.au>...

> Ke Jin" <ke...@borland.com> wrote in message
> news:887a1f78.04031...@posting.google.com...
> > Michi Henning <mi...@triodia.com> wrote in message
> news:<Pine.LNX.4.44.040316...@diadora.client.uq.net.au>...
>
> > > However, this optimization
> > > applies only in one very specific case and is useless in the
> > > general case. In particular, it is useless to CORBA applications:
> >
> > Sorry, your judgement is wrong. This technique applies to almost all
> > general cases.
>
> I meant the "specific case of a notification or event service", not
> specific cases of using such a service.

What you said was, "it is useless to CORBA applications (of cases
1/2/3/4)". All of your four cases were related to applications using
our notification implementation. And what I said was, the way we
implemented VisiNotify works in all of your four cases. Is this clear?

>
> > For instance, it applies to structured and typed
> > events, where an event can contain arbitrary number of Anys or even
> > valuetypes. VisiNotify is shipped with various examples covering many
> > cases that you claimed this technique wouldn't apply.
>
> I'm sorry, but I don't understand... Suppose I have the following operation:
>
> void op(in string s2, in any a, in string s2);
>
> I don't see how I can possibly pick off the Any value in this
> request without marshaling through the Any -- without doing
> this, I have no idea where in the byte stream parameter s2 starts.

Again, the answer is, VN doesn't forward individual Any, it forwards
messages. Therefore, it doesn't care how many Anys or anything flowing
Anys in a message.

>
> > VisiNotify doesn't pick Anys off the wire, it picks a entire message
> > and doesn't care how many Anys it containes. VisiNotify directly
> > forward entire messages, rather than forwarding individual Any or
> > Anys.
>
> OK. There are still few cases I don't understand though. For
> example, what if the sender and receiver don't use the same
> codeset and the Any contains character or string data?

This is a good question. Do you remember I asked you exactly this
question in a OMG mailing list two years ago? At that time, we
encounted this issue when doing our implemenation and OMG was
discussing changes on codeset negotiation protocol.

This is not an issue specific to our notification implementation.
Anyone would have exactly same issue when implementing a OMG firewall
proxy or a OMG Messaging Request Router. Taking firewall proxy as an
example, a proxy may receive requests from different clients, using
different codesets, but addressed to same target server. How would the
proxy forward these messages? Even if the proxy wanted to demarshal,
convert and remarsahl these messages, it wouldn't be able to do so.
There are possible solution, for instance, open multiple connections
from proxy to a target server. Each individual connection uses a
different codeset. However, this solution doesn't apply to event
pulling cases. In the mailing list, I asked how this should be
addressed. Your response was (not exactly but reoughly): "a
notification channel has no obligation to convert codeset for each
consumer. A consumer application should be prepared to receive what
ever codesets from the channel".

>
> > The only cases it needs to pick Anys out of a message are:
> >
> > * it needs to evalutate events for filtering or event level QoS (only
> > demarshal)
> > * it needs to do event translation (demarshal and remarshal).
> > * it needs to concatenate sequence events (demarshal and remarshal).
> > I don't see ICE can avoid demarsal/remarshal in above cases (except
> > for sequence event concatenation)!
>
> Obviously, unmarshaling is unavoidable for translation because
> the service must re-write the data. (BTW -- I've never seen
> a compelling use case for translation. Is there one? Is the use case
> frequent enough to justify the existence of the feature in the service?)

No, I don't see any cases justify the translation. In my opinion,
event translation is a flaw in the spec.. It is restricted. For
instance, translation between an arbitrary untyped event or structured
event to a typed event will fail in general. Only a small group of
untyped/structured event can be translated into typed. Also, it is
inconsistent. Translations go through different federation path
arriving at same event type count have different result on event
content, such as:

Structed->Untyped>Struct != Struct->Struct
Untype->Typed->Structed != Untyped->Structed
Structed->Typed->Untyped != Structed->Untyped

etc. (for complete list see visinotify faq).

>
> For filtering, Ice doesn't filter on the request parameters, but on
> the request context (not to be confused with IDL contexts.)

Technically, notification implementation can certainly support this
and avoid demarshal events content. We have made similiar suggestion
to some of our customers. However, in many cases, what applications
wanted is explicitly filtering on event content, rather than on
context. Certainly, you can ask applications to copy content into
context using PI.

> For concatenation, Ice batches multiple requests into a single message,
> which GIOP cannot do, so neither of these cases requires
> unmarshaling and remarshaling.

Notification implementation can batch also. Actually, VisiNotify has
already implemented and uses message level batches for two years. See
VN's whitepaper and FAQ. I know other vendors now are also following
us and applying the same technology in their notification service
implementation.

>
> But this isn't what I was concerned about. My concern is with
> marshaling of Anys in the general case, not just for the event or
> the notification service.

I were commenting on the statement of "event service of ice doesn't
need to do demarshal/remarshal but CORBA notification implementations
have to". Therefore, I were specific to notification service.

> Suppose I write:
>
> interface MichisEventChannel {
> void send(in any a);
> any receive();
> };
>
> I don't see how this can possibly benefit from your technique.

I don't see how your question is relevant to the original statement on
CORBA event service implementation, or my original comment on that
statememt?

> After all,
> I can only use the CORBA APIs. That's what I meant in
> that the technique is not useful in the general case.

That is a political issue. Technically, OMG compliancy doesn't require
a notificaiton implementation has to be built on user level, using
standard CORBA API. Therefore, our technique applies to our
notification implemetnation and as well as others, although it means
different implementation would use different low level APIs. Also, OMG
can standardize this kind of API, if other members willing to accept
our suggestion. This is again, a poltical issue, rather than technical
issue.

> At the very
> least, what is missing is an API that would allow me to treat the
> payload of a message as a blob and to re-send that payload
> in another message to another receiver.

As said, there is no technic difficulties for OMG to standardize this
kind of API. It is just a poltical issue. I don't see any technical
challenge. Do you?

>
> > Also, for general application cases, the actual costing part of Any
> > marshal/demarshal is on complex typecode, rather than on simple
> > typecode or on the encoded value. Even if demarshal and remarshal on a
> > Any with complex typecode is needed, a decent CORBA implementation,
> > such as VisiBroker, will not demarshal and remarshal every complex
> > typecode it received. Complex typecodes are already defined as
> > encapsulation in CORBA! Therefore, regardless how expensive, it is at
> > most a one time cost for each new complex typecode.
>
> Hmmm... I need to understand what you are getting at here. In general, if a
> TypeCode arrives on the wire, I can only find out what type it denotes
> by looking at the contents of the type code. So, I don't see immediately
> how VisiNotify could recognize that some complex TypeCode that
> arrives on the wire is the same as a TypeCode that was received previously.

To clarify, this is implemented in VisiBroker.

>
> Of course, it is possible to come up with TypeCode caching schemes
> that avoid retransmission or remarshaling, but that wouldn't be IIOP anymore
> then, would it?

Why not? This is about how a ORB is implemented to do complex typecode
marshaling/demarshaling. As long as the on-the-wire-format is CDR, it
is IIOP!! How could you be able to tell any difference on a TypeCode
handled this way out side my ORB?

>
> I can look at the TCKind enumerator at the beginning of the
> TypeCode and, if the TypeCode is for a complex type, look at
> the repository ID to check whether I have seen this TypeCode
> before. But the repository ID isn't guaranteed to be available
> prior to IIOP 1.2, so this technique works only if a
> repository ID is actually present, no?

No, it doesn't assume the repository ID has to be presented. In fact,
our early implementation was made even before GIOP 1.2. 1.2 just allow
us to optimiz th e implemention to first look at repository ID, if it
is non-empty.

With current design of GIOP, it is already able to support this. I am
not defend GIOP, I know it has various issues. But I just point out
the truth that something claimed to be impossible in original post
have in fact existed for years. Also, I agree that OMG should
standardize this API to allow applications to take advantage of this
feature on user level. However, as I stated many times, this is not a
technical issue.

>
> > And also,
> > OMG never specifies the notification service should only be
> > implemented on user level, but not on ORB level. Most implementations
> > happen to be built on user level is merely b/c they can be done
> > easily, rather than correctly.
>
> Right. With the right protocol and API though, I could do it at user
> level, and just about as efficiently.

Again, with GIOP, it is possible to define such an API, as long as OMG
members feel it is necessary.

>
> > Third, this design isn't something new. Many other similar CORBA
> > features, such as OMG firewall proxy, are mostly implemented in the
> > same way and tightly integrated with a specific ORB.
>
> I don't really see anything good about that. If the firewall has to be
> implemented inside the ORB, third parties can't deliver the firewall as a
> third-party add-on, and power users cannot write a firewall
> themselves. For example, the customer may not want to trust
> the ORB vendor, or may have a special-purpose security
> infrastructure that they need to integrate with (as is often the case
> for banking or military applications).

Actually, user or ORB level is just a term to be easy for conveying
the idea. It doesn't imply any special difference compare to your
implementation. Regardless it is on user level or on ORB level, all
code are executed in one process or JVM. "ORB level" vs "user level"
just means the implementation is built with "ORB specific API" vs "OMG
standardized API". As said, there is no technical difficulties for OMG
to standardize this API, and an ORB level implemetation will
immediately become a user level implementation once this API or
similar is standardized.

>
> I should be able to build the firewall at user-level like everything
> else, and I should be able to do that without undue complexity
> or performance penalty. With proper protocol and API design,
> that is quite possible (and that's how the the Ice firewall is
> implemented).

Yes, as long as OMG specifies the message level API.

>
> The motivation for VisiNotify to do its work at the ORB
> level is not that this is inherently desirable, but that
> the poorly-designed protocol encourages doing it that way.

I don't see this has anything to do with protocol. The API we used
internally is almost transparent to protocol detail. OMG Java mapping
already has the API similar to what we used internally on top of GIOP.

> With a better protocol and an appropriate API, it could
> be done at user level instead.

See above.

>
> > > 3) The technique only applies to GIOP version 1.2 and 1.3. For 1.0
> > > and 1.1, the request body is not aligned on an 8-byte boundary,
> > > so remarhaling in this fashion simply fails because that can
> > > violate CDR alignment rules. This means that VisiNotify must
> > > disable the optimization for any consumers that are using
> > > IIOP 1.0 or 1.1.
> >
> > You are wrong again! GIOP 1.2 just makes it easy to implement direct
> > message forward. It doesn't mean it can not be done with GIOP 1.0.
>
> I'm confused here. Maybe I've missed something. The case I have in
> mind is an Any containing a double value (possibly nested inside some
> other data structure). Doubles must be aligned on an 8-byte boundary.
> Prior to GIOP 1.2, the request body was aligned on a 4-byte boundary.
> So, if I forward a request that was sent by a 1.0 sender to a 1.2
> receiver, the double could end up on the wrong byte boundary, depending
> on whether the sender's Any data was originally aligned on a 4-byte or
> an 8-byte boundary.

This is an implementation detail I can't disclouse. Ever heard about
FFT?
Anyway, if you don't believe, just do a test as I suggested yesterday,
sending a bogus Any through the channel. Pls playing with various
object key lengths to make the payload of your GIOP 1.0 requests start
on whatever offset you like.

>
> Also, the header size may change because the object key of the receiver
> may have a different length than the object key of the sender, again causing
> a shift in alignment of the request body.

Certainly, we are not as silly as not knowing this.

>
> We changed the body alignment to 8 bytes with GIOP 1.2 specifically
> to get rid of these scenarios. So, what am I missing?

Before GIOP 1.2, firewall proxy implementations already existed and
they forward GIOP 1.0 messages without demarshal/remarshal. GIOP 1.2
just make this forwarding easy.

Also, as I said yesterday, it is very funny you brought up GIOP


1.0/1.1 as an negative evidence here. Even if a notification
implementation were not able to forward mesasge in case of GIOP
1.0/1.1, it wouldn't imply ice was superior. For legacy applications,
at most, one just upgrade their ORBs from using GIOP 1.0 to 1.2
exclusively. How would your ICE help those applications already
running on top of GIOP 1.0 ORBs? Are they interoperable with ice
without a upgrade?

Your judgement standard is, you can start something from stratch and
do whatever you want without caring about all legacy applications and
industry standards, old or new. But you require other frameworks to
not upgrade (such as from GIOP 1.0 to 1.2) and not make new
improvement (such as standardize message level API) when comparing
with yours? Is this kind of judgement standard funny?

>
> > To be specific, VisiNotify does not need to disable message forward
> > when GIOP 1.0/1.1 suppliers and/or consumers are involved.
>
> I honestly don't see how this works, given the 8-byte/4-byte alignment
> issue. Can you explain?

See previous comments. Also,

Does your schema interoperate with GIOP 1.0? OMG certainly can compare
up with new protocols without changing CORBA architecture and object
model.

I agree, then, simply submit an suggestion of standardize such an API
to OMG.

>
> > > And, of course, with a properly designed protocol, no such
> > > optimization is necessary.
> >
> > We don't call this "optimization". We call it a way to implement.
>
> I call it an optimization because it applies specifically
> a particular service, with a-priori knowledge of that service's
> semantics. If arbitrary applications could do what you have done
> for VisiNotify, I would agree with you.

Bu "arbitrary applications" you mean arbitrary supplier/consumer
applications using VisiNotify, or arbitrary applications themselves to
forward message? For the first, certainly. For the second, it require
us to expose our message level API or submit it to OMG for
standardization.

>
> > > With the correct design,
> > > event forwarding (or, more generally, request forwarding)
> > > automatically avoids unmarshaling and remarshaling cost, so
> > > all applications benefit without additional effort, or an
> > > ORB-internal special-case implementation.
> >
> > Fine, so, you believe unable to direct forward mesasge is not a
> > restriction of GIOP protocol, but a feature not exposed to
> > applications via standardized CORBA API? Then, I will not argue with
> > you. B/c that will be a politic issue, rather than a technic issue.
>
> Well, yes, it *is* a political issue. That strikes me as sad. After all,
> how to encode data on the wire should be a purely technical issue,
> I would have thought, but history proves me wrong.
>
> > Besides, we don't feel that be able to forward messages by a channel
> > is the only key issue of a notification implementation. Even if OMG
> > did define an API for message forwarding, there are still much more
> > critical issues a notification implementation needs to deal with.
>
> Absolutely. We built a notification service in our previous lives and are
> well aware of the details.
>
> > Otherwise, a user level implementation will at most be a prototype or
> > an academic exercise.
>
> The whole point of CORBA is that people can easily build *user-level*
> implementations.

Yes, but "user-level" applications should be defined as applications
implementing bussiness logic. As I said, other than message forward, a
decent notification implemention should handle much more system level
logic. It should be implemented by middleware vendors, rather than
business logic developers. Certainly, I don't against the idea,
neither see it is impossible, to standardized message level API by
OMG.


> GIOP extracts a far higher complexity penalty
> than necessary and does not permit such user-level efficient
> implementations.

Again, I don't see anything in GIOP would prevent OMG to have such
kind of user level API. Our message level API used in implementing our
notification service and firewall proxy is pretty clean.

>
> > The complicity and low level nature of these
> > issues in an industry strengthed implementation are much more complex
> > than message forwarding. They are best to be developed by middleware
> > vendors, rather than average application developers.
>
> It's interesting to hear you say that a high-quality implementation is
> best developed by ORB vendors. To me, a good platform
> empowers the end users just as much as the implementors of the
> platform.

What I said was, system level features in CORBA should best be
implemented by middleware vendors. Application developers should
focuse on business logic. Is this clear?

>
> GIOP is a horribly botched job that was designed by foul compromise,
> and shaped by a war between the DCE and non-DCE factions in the
> OMG. The result is a mess. The effects of the poor GIOP design
> on the platform are with us to this day, and every single dot release
> of CORBA has deemed it necessary to make changes to GIOP in
> a futile attempt to get rid of some of the defects. With better design,
> none of this would have been necessary.

After all, GIOP is only an interoperate protocol when you need send
request/reply accross ORB domains, namely to a foriegn ORB. Within the
same ORB domain, it is 100% compliant to use whatever protocol you
like.

Regards,
Ke

>
> Cheers,
>
> Michi.

0 new messages