f



New Ice documentation available

Hi,

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

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

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

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

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

Enjoy!

Cheers,

Michi.

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

0
michi9457 (29)
7/10/2003 11:47:26 AM
comp.soft-sys.ace 20326 articles. 1 followers. marlow.andrew (167) is leader. Post Follow

104 Replies
2469 Views

Similar Articles

[PageSpeed] 19

Michi Henning <michi@triodia.com> wrote in message news:<Pine.LNX.4.44.0307102139560.20820-100000@diadora.client.uq.net.au>...

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

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

Best Regards,
gopi
---

Gopi Kumar Bulusu
Sankhya Technologies Private Limited
http://www.sankhya.com
Tel: +91 891 554 2666
Fax: +91 44 2822 7357
0
gopi
7/17/2003 9:27:55 AM
"Gopi Bulusu" <gopi@sankhya.com> wrote in message
news:2d87f439.0307170127.78b0da85@posting.google.com...
> Michi Henning <michi@triodia.com> wrote in message
news:<Pine.LNX.4.44.0307102139560.20820-100000@diadora.client.uq.net.au>...
>
> >   There is also quite a bit of material on how to make servers
> >   scalable using various techniques, such as default servants
> >   and evictors. (CORBA users should have a look and weep at
> >   how simple things can be with properly designed APIs...)
>
> There is nothing const or static about CORBA. It has evolved for more than
> a decade and will definitely evolve for years to come.

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

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

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

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

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

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

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

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

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

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

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

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

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

Cheers,

Michi.

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

0
Michi
7/20/2003 2:04:42 AM
Hi Folks,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

and 

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

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

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

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

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

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

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

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

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

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

>> I have been involved with several projects that decided to switch
>> ORB implementations at some stage during development.  In all
>> cases, the experience wasn't pretty:
 
Perhaps that's because people were switching from older versions of
Orbix to newer, standards-compliant ORBs?  I agree that this is a
painful process, though one that once done makes life MUCH better for
future migrations.

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

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

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

and 

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Take care,

        Doug
-- 
Dr. Douglas C. Schmidt, Professor           TEL: (615) 343-8197
Electrical Engineering and Computer Science FAX: (615) 343-7440
Vanderbilt University                       WEB: www.cs.wustl.edu/~schmidt/
Nashville, TN 37203                         NET: d.schmidt@vanderbilt.edu
0
7/20/2003 11:36:02 PM
"Michi Henning" <michi@triodia.com> wrote in message news:<_MmSa.4709$OM3.2483@news-server.bigpond.net.au>...
!

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

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

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

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

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

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

> 

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

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

Best Regards,
gopi

---

Gopi Kumar Bulusu
Sankhya Technologies Private Limited
http://www.sankhya.com
Tel: +91 891 554 2666
Fax: +91 44 2822 7357
0
gopi
7/21/2003 5:59:04 AM
schmidt@macarena.cs.wustl.edu (Douglas C. Schmidt) wrote in message news:<bff912$nfg@macarena.cs.wustl.edu>...
> Many of the topics that Michi brings up
> below were discussed at those meetings, so I wanted to provide my
> thoughts below.
> 
> >> Having written large sections of the CORBA specification myself, I
> >> am aware of that.  I am also aware of the impossibility to rectify
> >> even minor flaws in CORBA, let alone the major ones (and, believe
> >> me, I have tried).
> 
> There's no question (in my mind) that the CORBA specification and
> revision process has flaws.  Things do seem to get fixed, however,
> albeit not at the rate I'd like to see.  

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

> >> Unfortunately, the CORBA standard is stuck in a quagmire, I
> >> believe. There has been little activity in last two years or
> >> so. 
> 
> I disagree, though we may care about different parts of the OMG CORBA
> spec.  

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

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

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

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

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

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

I'm glad. It needed saying.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Fair point.

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

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

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

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

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

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

> Again, this is simply FUD Michi.  

I beg to differ.

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

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

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

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

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

Maybe, but that's no excuse.

> >> - Large and important parts of what you need to specify CORBA are
> >> not standardized at all: implementation repositories, configuration
> >> of all the services, build environment, administration, etc.
> 
> The CORBA Component Model is addressing some of these issues - and
> there are an increasing number of CCM implementations coming online
> (check out Diego's http://www.ditec.um.es/~dsevilla/ccm/ page for more
> details).  Moreover, it's not really clear what your point is here
> since ICE's solutions for all of these capabilities are even less
> standardized than CORBA!  

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

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

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

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

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

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

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

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

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

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

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

> To wrap up this round of the debate (since I know Michi won't let me
> get the last word yet ;-)) let me close with the following.  I respect
> the work that you ICE folks have done.  I think you guys are REALLY
> smart, do GREAT work, and I'd like to see you SUCCEED.  It bugs me,
> however, when you start spewing FUD about CORBA that simply doesn't
> hold up under closer inspection.  

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

Regards,

Andrew Marlow.
0
apm35 (156)
7/21/2003 11:32:54 AM
Hello,

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

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

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

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

-- Marc

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

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

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

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

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

-- Marc

0
Marc
7/21/2003 12:32:21 PM
schmidt@macarena.cs.wustl.edu (Douglas C. Schmidt) wrote in message 
> [snipped...]

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

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

--Dilip
0
rdilipk (138)
7/21/2003 7:01:03 PM
Hi Dilip,

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

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

        Take care,
        
                Doug

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


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

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

-- Marc

0
marc4371 (25)
7/21/2003 8:48:18 PM
Michi Henning <michi@triodia.com> wrote:
>
>  Unfortunately, the CORBA standard is stuck in a quagmire, I believe.
>  There has been little activity in last two years or so. Specifications
>  are produced that are  never implemented, and bugs in the specification
>  take ages to fix, or are never fixed at all.
>

   Hi all,

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

	Frank


-- 
Frank Pilhofer  ...........................................  fp@fpx.de
If most people said what's on their minds, they'd be speechless.
- Alfred E. Neuman
0
Frank
7/22/2003 12:43:19 AM
Marc Laukien <marc@zeroc.com> wrote in message news:<X2GdnTBQ3dLKQIaiRTvUqg@speakeasy.net>...

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

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

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

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

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

gopi

---

Gopi Kumar Bulusu
Sankhya Technologies Private Limited
http://www.sankhya.com
Tel: +91 891 554 2666
Fax: +91 44 2822 7357
0
gopi
7/22/2003 5:39:42 AM
"apm" <apm35@student.open.ac.uk> wrote in message
news:d1a33011.0307210332.27776076@posting.google.com...
>
> I fear that ICE may not catch on but it's not to do with coolness.
> It's to do with being supported in commercial development envrionments
> with old versions of Unix and old compilers. I get the impression that
> ICE was developed primarily using Linux and the GNU compiler, then
> ported to Windoze. I found terrible portability problems when I tried
> to get ICE up and running on Solaris 8 using the Forte compiler. The
> older Sparcworks compiler wouldn't stand a chance.

Hi Andrew,

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

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

Cheers,

Michi.

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

0
michi9457 (29)
7/22/2003 11:45:21 AM
"Gopi Bulusu" <gopi@sankhya.com> wrote in message
news:2d87f439.0307202159.345f113c@posting.google.com...
> "Michi Henning" <michi@triodia.com> wrote in message
news:<_MmSa.4709$OM3.2483@news-server.bigpond.net.au>...
> !
>
> > (lines deleted)
> > little activity in last two years or so. Specifications are produced that
are
> > never implemented,
>
> I believe that the process of standardization at OMG naturally leads
> to
> implemented specs. I can say this for sure, because we have
> participated
> in quite a few standardization efforts at OMG and have implemented the
> same specs that we worked on. Naturally, there are always exceptions
> (and exceptions
> prove the rule :-)

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

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

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

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

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

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

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

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

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

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

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

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

Cheers,

Michi.

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

0
Michi
7/22/2003 12:06:36 PM
"Gopi Bulusu" <gopi@sankhya.com> wrote in message
news:2d87f439.0307212139.1ffea84f@posting.google.com...
>
> If you are saying that a C++/CORBA programmer has to look up the spec
> all the time, then there is a serious problem. I completely agree that
> many of the C++ mapping rules are "not-intuitive" for C++ programmers
> who use and understand the ISO specification. One has to note that
> CORBA's C++ mapping rules predate
> ISO C++

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

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

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

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

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

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

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

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

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

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

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

Cheers,

Michi.

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

0
Michi
7/22/2003 12:24:48 PM
"Frank Pilhofer" <fp@fpx.de> wrote in message
news:slrnbhp205.oo.fp@ariel.fpx.de...

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cheers,

Michi.

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

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

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

 ....
> 
> 
> The list could be extended considerably.
>

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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


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

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


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

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

> 
> > >> Ice is proprietary, to be sure, but all the APIs, language
> > >> mappings, and the protocol are well documented, and anyone is
> > >> welcome to create something that interoperates with Ice. In return,
> > >> I get a platform that is more powerful than CORBA, doesn't take
> > >> years to learn, is simple and coherent, and scales and performs
> > >> better (and does that in a smaller footprint). To me, that makes it
> > >> worth at least a closer look.
> >
> > At last something we can agree on Michi!  It definitely makes sense to
> > take a good look at ICE (and everything else that's available to solve
> > similar problems) - that's what "due diligence" is all about.
> > Moreover, I'm *certain* that good designers and programmers like you
> > guys can come up with a cleaner/better distributed object computing
> > model than CORBA!
> 
> Thanks! We believe that Ice is better, period. It will never be all
> things to all people, just as no other technology is. But, if you are
> looking for a simple, efficient, and reliable technology for RPC, Ice
> leaves CORBA in the dust. To some people, that matters more than
> anything.
> 
> > My sense, however, is that ICE will have success with the "early
> > adopter" technologist market, but will have difficulty crossing the
> > chasm to be a mainstream product at the level of adoption of CORBA,
> > .NET, SOAP, or J2EE.
> 
> That is very well possible. And, if that's what happens, suits me fine
> -- we aren't interested in world domination, but in quality technology.
> We do provide that and leave world domination to other people :-)
>

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

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

But if I would program something totally new, not locked to existing
infrastructure -- I will think about ICE quite seriously.
0
Ruslan (5)
7/23/2003 2:17:47 AM
On Wed, 23 Jul 2003, Frank Pilhofer wrote:

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

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

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

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

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

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

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

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

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

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

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

Cheers,

Michi.

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

0
Michi
7/23/2003 4:06:21 AM
On 22 Jul 2003, Ruslan Shevchenko wrote:

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Most definitely. Ice is the next one :-)

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

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

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

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

Cheers,

Michi.

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

0
michi9457 (29)
7/23/2003 4:43:29 AM
"Michi Henning" <michi@triodia.com> wrote in message news:<k2aTa.8550$OM3.7103@news-server.bigpond.net.au>...
> Fortunately, the people who worked on
> ISO C++ standardization were, on average, much better at C++
> than the ones who worked on the CORBA C++ mapping.

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

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

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

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

--steve

-- 
Steve Vinoski                      vinoski at iona.com
Chief Engineer, Product Innovation
IONA Technologies  http://www.iona.com/hyplan/vinoski/
200 West St.                     Waltham, MA USA 02451
0
vinoski
7/23/2003 1:04:20 PM
"Michi Henning" <michi@triodia.com> wrote in message news:<%uaTa.8626$OM3.2532@news-server.bigpond.net.au>...
> To be fair, getting a mapping off the ground back then, before ISO C++
> was available, was a hard ask. But then again, there was an alternative
> mapping submitted by Hyperdesk at the time. Coincidentally, that mapping
> was quite similar in flavor (and memory-management safety) to the Ice
> C++ mapping. Sadly, the Hyperdesk mapping was rejected on political
> grounds and factional infighting as well as on (in hindsight, entirely
> inappropriate and misguided) performance grounds.

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

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

--steve

-- 
Steve Vinoski                      vinoski at iona.com
Chief Engineer, Product Innovation
IONA Technologies  http://www.iona.com/hyplan/vinoski/
200 West St.                     Waltham, MA USA 02451
0
vinoski
7/23/2003 1:12:33 PM
"Michi Henning" <michi@triodia.com> wrote in message news:<gN9Ta.8495$OM3.64@news-server.bigpond.net.au>...
> But as a world-recognized expert on CORBA, and after
> having used and implemented it daily for many years, I would think that I
> could remember what I need to know. Sadly, this isn't so. Maybe there is
> something wrong with my memory (but then, lots of other people seem to have
> the same problems, so I don't think so).

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

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

--steve

-- 
Steve Vinoski                      vinoski at iona.com
Chief Engineer, Product Innovation
IONA Technologies  http://www.iona.com/hyplan/vinoski/
200 West St.                     Waltham, MA USA 02451
0
vinoski
7/23/2003 1:15:58 PM
"Steve Vinoski" <vinoski@ieee.org> wrote in message
news:6c2690b5.0307230504.7c923eb0@posting.google.com...
> "Michi Henning" <michi@triodia.com> wrote in message
news:<k2aTa.8550$OM3.7103@news-server.bigpond.net.au>...
> > Fortunately, the people who worked on
> > ISO C++ standardization were, on average, much better at C++
> > than the ones who worked on the CORBA C++ mapping.
>
> Ignoring the personal nature of the above malignment for the moment, I can
> say that the statement is completely untrue.

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

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

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

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

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

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

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

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

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

Cheers,

Michi.

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

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

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

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

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

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

-- Marc

0
Marc
7/23/2003 1:48:09 PM
"Steve Vinoski" <vinoski@ieee.org> wrote in message
news:6c2690b5.0307230515.3868b20@posting.google.com...
>
> It's true that the C++ mapping is more difficult than it should be,
> but c'mon Michi, if you have to look up the rules every time you write
> a program, then you really must have a memory problem. We both know
> you're exaggerating.

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

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

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

    ref->foo(bar());

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

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

Again, that's a memory leak. Or just

    ref->bar();

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

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

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

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

One wonders, yes :-)

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

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

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

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

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

Cheers,

Michi.

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

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

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

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

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

-- Marc

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

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

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

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

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

--steve

--
Steve Vinoski                      vinoski at iona.com
Chief Engineer, Product Innovation
IONA Technologies  http://www.iona.com/hyplan/vinoski/
200 West St.                     Waltham, MA USA 02451
0
vinoski
7/23/2003 8:06:42 PM
"Steve Vinoski" <vinoski@ieee.org> wrote in message
news:6c2690b5.0307231206.27402003@posting.google.com...
> "Michi Henning" <michi@triodia.com> wrote in message
news:<xSwTa.10402$OM3.8583@news-server.bigpond.net.au>...
> >
> > Hmmm... I'm having problems with this (as I mentioned to you about two
years
> > ago).
> > Here is my reasoning:
> [snip]
>
> A crucial aspect that you're missing from your reasoning is that one
> of the original applications for the C++ mapping was going to be a
> non-distributed system. I'm talking about Fresco, an X Windows System
> toolkit/framework that Mark Linton was working on. Mark was using IDL
> to ensure that Fresco interfaces were as "pure" as possible (an
> approach with which I agree strongly -- IONA's Adaptive Runtime
> Technology (ART) takes the same approach). In a local-only
> environment, the overhead of reference counting was indeed too much,
> as our tests proved.
>
> You could argue that putting requirements for non-distributed systems
> on the C++ mapping was inappropriate, given that CORBA is expected to
> be used far more often in distributed environments than in local ones,
> but the relatively recent addition of the "local" IDL keyword
> (finally!) is proof that there is and always has been demand for such
> support.

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

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

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

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

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

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

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

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

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

Cheers,

Michi.

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

0
Michi
7/24/2003 12:01:07 AM
On 23 Jul 2003, Steve Vinoski wrote:

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

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

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

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

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

Cheers,

Michi.

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

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

That is indeed an interesting part of it.

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

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

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

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

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

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

Cheers,

Michi.

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

0
michi9457 (29)
7/24/2003 5:14:53 AM
vinoski@ieee.org (Steve Vinoski) wrote in message news:<6c2690b5.0307231855.689afe97@posting.google.com>...
> Michi, you've stated some very negative things about CORBA above and
> elsewhere in this thread. However, given the following quotes from
> you, which turned up in a simple search through comp.object.corba from
> the past few years, how do you explain your sudden about-face?
> 
> 06/27/2002:
> 
> "Right now, CORBA *is* the future of middleware. I'm not aware of any
> other middleware that would come even close in portability, platform
> support, features, performance, or multi-vendor support. It will be a
> minimum of six or seven years before any other middleware platform
> will be able to match that."
> 
> 08/28/2001:
> 
> "Well, I find it difficult to see how CORBA can be dead. What is more
> likely happening is that CORBA well and truly has reached the stage
> where it is mature and works. Unfortunately, there is a strong
> tendency in this industry to discard anything that works and instead
> go off to chase something that might work in three years' time.
> 
> CORBA is still the most feature-rich and mature distribution
> technology in existence. It's fast, reliable, runs on everything on
> the planet, supports all major programming languages, is available
> from a large number of vendors, is based on an open standard, and is
> growing by leaps and bounds."
> 
> 02/17/2000:
> 
> "CORBA is simple at the core, but there are lots of details to worry
> about. That's not the fault of CORBA, but the fault of distributed
> systems. They are, by nature, more complex than non-distributed ones."
> 
> 09/27/2000:
> 
> "The upshot is that, to the best of my knowledge, there simply isn't
> anything that comes anywhere near CORBA's flexibility, range of
> functionality, convenience, platform support, etc. Further, as far as
> I can see, there is nothing on the horizon that could take CORBA's
> place. It seems that CORBA's success is assured for many years to
> come. And, most certainly, the CORBA user base is growing, not
> shrinking"
> 
> 07/19/1999:
> 
> "I agree that CORBA has shortcomings. Anything of that degree of
> complexity will have shortcomings, that's inevitable. But, on the
> upside, pretty much anyone can contribute toward improving the
> situation...And, while CORBA has shortcomings, let's not forget that
> there is a much longer list of things it does extremely well. It's no
> accident that CORBA is as popular as it is..."
> 
> 11/09/1999:
> 
> "If you want multi-platform or multi-language distributed computing,
> CORBA is pretty much the only viable choice in existence."
> 
> Which Michi are we to believe?

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

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

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

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

Bruce Fountain
brucef
at
eudoramail
dot com
0
brucef (3)
7/24/2003 5:46:38 AM
On 23 Jul 2003, Bruce Fountain wrote:

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

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

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

Cheers,

Michi.

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

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

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

regards,

Marcel

0
mr8167 (3)
7/24/2003 9:08:48 PM
brucef@eudoramail.com (Bruce Fountain) wrote in message news:<cacae9d5.0307232146.8999cbe@posting.google.com>...
> This is a very interesting history, but I am not sure it is supporting
> your case Steve. Try reading the above quotes in reverse order and you
> can see a gradual process of disillusionment.

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

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

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

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

--steve
0
vinoski (4)
7/24/2003 10:29:04 PM
"Steve Vinoski" <vinoski@ieee.org> wrote in message
news:6c2690b5.0307240642.b6dafa1@posting.google.com...
>
> I think my point is that the reversal is not at all gradual. Don't
> forget that I know Michi pretty well. Michi was a top user of an ORB I
> helped build while at a previous employer, and of course there's the
> book we co-authored.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Cheers,

Michi.

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

0
michi9457 (29)
7/25/2003 12:22:35 AM
vinoski@ieee.org (Steve Vinoski) wrote in message news:<6c2690b5.0307240642.b6dafa1@posting.google.com>...
> As the quotes show, for the past N years and right up to the recent
> past, Michi basically believed that CORBA was the greatest distributed
> systems technology ever made, but almost overnight, it's suddenly
> become the worst.

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

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

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

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

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

Best regards,

Bruce Fountain
0
brucef (3)
7/25/2003 5:25:20 AM
"Gopi Bulusu" <gopi@sankhya.com> wrote in message
news:2d87f439.0307250046.2482b3fa@posting.google.com...
> "Michi Henning" <michi@triodia.com> wrote in message
news:<k2aTa.8550$OM3.7103@news-server.bigpond.net.au>...
> >
> > Well, the CORBA C++ mapping and the ISO C++ specification
> > effort proceeded concurrently.
>
> Correct, and that makes CORBA C++ mapping predate ISO C++. Because the
> C++ mapping depends on the C++ language and not the other way round.

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

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

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

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

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

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

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

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

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

Cheers,

Michi.

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

0
Michi
7/25/2003 1:31:27 PM
brucef@eudoramail.com (Bruce Fountain) writes:

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

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

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

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

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

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

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

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

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

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

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

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

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

> Best regards,
> 
> Bruce Fountain

-- 
Daniel Ortmann, LSI Logic, 3425 40th Av NW, Suite 200, Rochester MN 55901
work: Daniel.Ortmann@lsil.com / 507.535.3861 / 63861 int / 8012.3861 gdds
home: ortmann@isl.net / 507.288.7732, 2414 30Av NW #D, Rochester MN 55901
0
dortmann (10)
7/25/2003 3:17:28 PM
Hi Steve,

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

Bingo - again this is particularly ironic coming from Michi, who IIRC
was always beating up on ORB vendors/developers for "tooting their own
horn" in comp.object.corba.  My recommendation would be to start a
comp.object.ice (or whatever) newsgroup and these discussions can
continue ad nauseum in that forum!

Thanks,

        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.schmidt@vanderbilt.edu
0
7/25/2003 5:39:36 PM
Hi Michi,

>> Can't it? Why is it necessary to have a standard to build complex
>> distributed systems?

I find it strange that you would even ask this question Michi.  Pretty
much by definition, "complex distributed systems" tend to live a long
time - usually MUCH longer than the "attention span" of COTS providers
who basis their technologies on non-standard
tools/platforms/services/etc.  The world of IT is LITTERED with what
Steve Vinoski calls "Middleware Dark Matter"
<www.iona.com/hyplan/vinoski/pdfs/IEEE-Middleware_Dark_Matter.pdf>,
which causes ALL SORTS of problems wrt quality, capability, and total
ownership costs.  But don't take my word for it - check out

http://www.cs.wustl.edu/~schmidt/Tech_030612.pdf

for information from one of the major US aerospace/defense integrators
talking about the challenges they face when building complex
distributed systems, and how standards are helping them out.  In fact,
starting page 18 you'll find some interesting stuff ;-)

>> People built complex distributed systems a long time before there
>> ever was a standard.

Sure, and these systems have INEVITABLY become albatrosses around the
necks of the companies that have to maintain them over a long period
of time.  Some major telecom equipment providers have been virtually
crippled by the total ownership costs of maintaining their
cathedral-like switching systems based on proprietary technologies.

>> As far as I can see, the standard doesn't do much to help people
>> get on top of complexity.

Quite frankly Michi, if you don't see this, you need to spend more
time working with people building long-lived, complex distributed
systems!  There's now a lot of empirical evidence (i.e., gathered from
detailed cost/schedule/quality metrics collected over many years) from
companies like Boeing, Siemens, Raytheon, SAIC, LMCO, etc. that
illustrates the lifecycle cost savings of developing these types of
systems using standards-based approaches.

>> Rather, a standard is meant to provide cross-vendor
>> interoperability, source code portability, and a well-known
>> API. But I honestly don't see how a standard would help me to build
>> complex systems more easily. (I mean, it's not as if the standard
>> would make the inherent complexity go away, is it?)

I disagree here again Michi.  In fact, if you look at MATURE IT
industries (e.g., micro-processor manufacturers and the IP equipment
provider market) you'll see that the use of standards is ESSENTIAL to
obtaining the economies of scale necessary to focus their R&D
activities on actually resolving the inherent complexities, rather
than wasting time rearranging the accidental complexities (which
ultimately end up being like rearranging deck chairs on the Titanic).
For a very detailed discussion of this point, please see

http://www.cs.wustl.edu/~schmidt/PDF/middleware-chapter.pdf

Having said that, of course, standards are no panacea.  However, the
LACK of standards in the middleware domain is SERIOUSLY hurting the
competitiveness of the world IT distributed systems market.

Take care,

        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.schmidt@vanderbilt.edu
0
7/25/2003 6:20:57 PM
Hi Frank,

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

Exactly.  One of the problems with being an expert (or an academic
;-)) is that it's sometimes hard to realize that a lot of the dark
corners that are so tantalizing intellectually are actually not
something that makes any difference in practice.

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

Rigth.

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

Yup - plus the CORBA conf tools help a lot here, as well.

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

Agreed.  Again, the fact that some companies sell "CORBA" products
that implement ancient mappings and APIs is not an indictment of
CORBA, but of those companies.  Fortunately, there are enough good,
interoperable, modern ORBs available to write portable, effective,
efficient, robust distributed systems.

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

So here's a question for the ZeroC folks - if someone were to
recommend the Ice C++ mapping as the C++ language mapping 2.0 for
CORBA would that be consistent with the Ice/ZeroC license?  Put
another way, is Ice *really* that open?

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

Yes, indeed!  IMHO, the DRE domain is the key future market for CORBA.
Fortunately, it's also a rapidly growing economic force, particularly
as the general-purpose software market is increasingly outsourced to
countries that can't afford to pay high costs for software licenses
(which therefore motivates them to use zero-cost open-source
solutions).

>>  I also have high hopes for component-based development, where you
>> interconnect components into higher-level assemblies. 

This is clearly the future of middleware, particularly when combined
with model-based software technologies.

>> This design paradigm is not a CORBA exclusive, but CCM, once you
>> get past its more intimidating chapters, takes the idea the
>> farthest.

Agreed, and moreover there's a substantial amount of R&D effort going
on today to add QoS support to CCM.

>> Lightweight CCM, however unfortunate the name (it should be called
>> CCM, and the current spec should be Persistent and Transactional
>> Component Model or something like that) should make that even more
>> accessible. And I think that it will see early adoption by Open
>> Source ORBs (by coinci- dence, MicoCCM pretty much exactly
>> implements the Lightweight CCM subset already, as does OpenCCM); 

That's great news!

>> I already hear embedded systems engineers screaming for
>> commercial(ly supported) implementations.

Yup!

>>  So there's lots to be done, but I am not yet convinced that
>> there's only darkness glooming ahead.

Well, just don't read Marc's postings then - or you'll think the end
of the world is close at hand for CORBA ;-)

        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.schmidt@vanderbilt.edu
0
7/25/2003 6:39:38 PM
Hi Frank,

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

Bingo - that was Steve and my point, as well.  While it's the easy way
out, this approach has a habit of not working well in the long-run
(unless you are one of a handful of giant companies).  I've listed
examples of operating systems (e.g., Be-OS, NextStep/OpenStep, etc.)
that bypassed standards to no avail.  There are also plenty of
middleware technologies in the same boat (e.g., Xshell, Inferno, RMI,
etc.).  

I'm reminded of a classic quote by Winston Churchill, who once said
"Democracy is the worst form of government, except in comparison to
all the rest."  I think the same thing tends to be true of standards.

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.schmidt@vanderbilt.edu
0
7/25/2003 6:52:38 PM
Douglas C. Schmidt wrote:
> Hi Marc,
> 
> 
>>>It is very clear to me that CORBA is slowly dying. 
> 
> 
> This is FUD - plain and simple, i.e., there's no proof, no citations,
> no evidence, just good ol' "fear, uncertainty, and doubt".  Here's
> some counter-FUD: "Based on the meteoric rise in postings from users,
> web download, and sales of documentation and precompiled software
> kits, use of open-source CORBA is growing by leaps and bounds all
> around the world."  BTW, there's actually evidence for this ;-)

First of all Doug, I'm free to voice my opinion, and don't have to prove 
anything to you. My opinion is formed by talking to many people about 
CORBA, by looking at quarterly balance sheets of leading CORBA 
companies, and by looking at progress at the OMG, and by spending many 
years in the CORBA industry. And yes, my opinion is also formed because 
of my work on Ice, and what people tell me if they compare Ice with CORBA.

You simply call my opinion FUD because you don't like my opinion.

> 
>>>But I see very little traction in the CORBA world anymore. Fact is,
>>>that there are much fewer dollars invested in CORBA than this used
>>>to be the case, both by vendors and customers. And not only due to
>>>the poor economy, no, CORBA had an overproportional rapid decline
>>>in the last years.
> 
> 
> Again, some counter-FUD: "The overall downturn in the global IT
> enconomy, which has dried up IT budgets and caused many IT
> platform/tool providers to fail, has led many companies (particularly
> telecom and aerospace/defense companies) to move towards open-source
> operating systems (such as Linx) and middleware (such as CORBA)
> solutions.  Most telecom providers and aerospace/defense integrators
> are investing heavily in standards-based open-source OS/middleware
> solutions since they see it as a way to avoid catastrophe when small
> companies selling proprietary solutions disappear."  There's also lots
> of evidence for this, as well.

You are mixing so many things into one statement that it's impossible to 
  have evidence for or against the overall statement.

I think the only part of your statement for which there is actually 
evidence is that Linux is growing. Everything else is opinion, based on 
your perception of the industry. My opinion and my perception differs.

> 
> 
>>>Some CORBA vendors even tried to downplay the fact that they are
>>>CORBA vendors.
> 
> 
> The fact that there are (or were) CEOs at certain companies that
> couldn't manage their way out of a wet paper bag should be an
> indictment of their (lack of) leadership skills and vision, rather
> than an indictment of the technology!!!  Fortunately, other CORBA
> vendors are doing quite well, so the overall balance is positive.

If we are talking about the largest CORBA vendor, the "gorilla player in 
  the CORBA world", then I believe that this also says something about 
how investors and analysts and customer perceive CORBA these days.

> 
> 
>>>And the OMG now focuses much more on MDA than on CORBA.
> 
> 
> Of course - that strategy makes a lot of sense since DOC middleware
> has largely been successful and there's a LOT more effort required to
> address the MDA-related challenges.  I recommend you read the book
> "The Innovators Dilemma" by Clayton Christensen for good coverage of
> what happens when organizations spend too much time "looking at their
> backswing" rather than moving ahead to address next-generation
> challenges.

I read the book. But in my opinion you are making a big mistake here, 
which so many other companies did.

The book basically says that sometimes you have to take a risk and 
pursue an idea, even if it cannot be proven that the idea is really viable.

I fully agree with this in general. But to turn this around, and to 
conclude that you should pursue every idea, no matter how far-fetched 
and unrealistic it is, is wrong. Such a strategy has proven fatal to 
many companies.

> 
>>>Given this situation, I believe that Ice has a brilliant future. 
> 
> 
> That belief doesn't surprise me at all ;-)
> 
> 
>>>I can tell you from the many companies that are currently
>>>evaluating Ice, or already building it in their next-generation
>>>product, that there is a lot of interest in a new, easy-to-learn,
>>>"technical middleware" platform.  Of course, your opinion might
>>>differ, and ultimately only time will tell.
> 
> 
> No question there.  The big question is "why the $%^#& are you posting
> this FUD and ICE marketing stuff on comp.object.corba"?!?!?!  

Isn't it obvious? I want more people to check out Ice. Ice is an 
alternative to CORBA, therefore comp.object.corba is the right 
newsgroup. This group is not just for CORBA praise! I don't see anything 
wrong with this.

Besides, the original post in this newsgroup was about new Ice 
documentation being available for free download. Shouldn't something 
like this be interesting for you as a professor in particular? After 
all, we put a lot of work into this documentation, and it shows new 
possibilities with Ice in distributed computing, and how they compare to 
CORBA.

Is this marketing? If so, then you also shouldn't post information about 
papars about TAO in this newsgroup either. But this would be a really 
shame, because I always enjoyed reading your papers, and never called 
them marketing.

-- Marc

0
marc4371 (25)
7/25/2003 9:10:44 PM
> Bingo - again this is particularly ironic coming from Michi, who IIRC
> was always beating up on ORB vendors/developers for "tooting their own
> horn" in comp.object.corba.  My recommendation would be to start a
> comp.object.ice (or whatever) newsgroup and these discussions can
> continue ad nauseum in that forum!

Since Ice is positioned as an alternative to CORBA, comp.object.corba is 
exactly the right newsgroup. Again, this is not only a group for praise, 
but also to show alternatives. If somebody is not interested in 
alternatives, they don't have to read what we've got to say.

There are also have a lot of ACE/TAO developers who are currently 
looking into Ice as an alternative, therefore we also posted the 
information about the documentation release in comp.soft-sys.ace. After 
all, this is a pubic newsgroup, and we are free to post announcements 
there, as long as they are related to the topic of the newsgroup.

-- Marc

0
marc4371 (25)
7/25/2003 9:20:37 PM
Douglas C. Schmidt wrote:
> Hi Mark,
> 
> 
>>>By the way, I agree with you that writing a good C++ mapping isn't
>>>so hard. This makes it even more confusing to me why there is no
>>>new C++ mapping for CORBA. The only answer I can think of is that
>>>neither the CORBA vendors nor the OMG care.
> 
> 
> Is there a reason why you just can't stay away from slinging FUD Marc?

FUD seems to be your favorite word lately. Whenever there is an opinion 
you don't like, it's FUD to you.

> At any rate, in case you're actually interested in a rational
> technical discussion of these issues, please check out
> 
> http://www.cs.wustl.edu/~schmidt/report-doc.html
> 
> and read the three columns Steve and I wrote for the C/C++ Users
> Journal that explains the various forces involved here.  LOTS of
> people (including the OMG and ORB vendors) would like a better
> mapping.  As usual, it comes down to balancing various forces.  IMHO,
> the "Right Thing"[TM] to do would be to start an initiative to get the
> major ORB vendors who care about this to develop their own alternative
> mapping, get it working in multiple mainstream ORBs, and then submit
> this to the OMG revision task force.  The TAO group has talked with
> OIS about doing this, and if we ever get some spare cycles we'll work
> it out.  If someone wants to sponsors this work, it'll get done
> faster.

I read all the stuff about the history, but this doesn't change the fact 
that there is still only an arcane C++ mapping for CORBA. You can argue 
about history all you want, fact is that no attempt to start a new C++ 
mapping to date ever succeeded.

Perhaps the TAO group and OIS finally make a new C++ mapping happen. If 
so, then I will be the first one to congratulate you for your effort.

> 
> 
>>>Besides, Ice is not proprietary. It is available under the GPL. We
>>>only charge for licenses if somebody doesn't want to make their
>>>programs available under GPL-like terms. See
>>>http://www.zeroc.com/licensing.html
> 
> 
> I think you're mixing up your terminology here - probably
> intentionally.  Here's the bottomline, Ice isn't based on any ratified
> standard, CORBA is.  It's also not free of charge for the vast
> majority of organizations who want to develop software they aren't
> planning to give away in source-code form.  At least Michi was honest,
> he said "we're in this to make $$$."  I have no problem with that, but
> let's not play word games, ok?

Ice is GPL, and the pros and cons of GPL are well known. Furthermore, we 
have documented Ice and the Ice protocol in detail, and do not prevent 
anybody from implementing the protocol. There are no patents, no 
restrictions on how somebody could use the Ice protocol or other parts 
of the Ice specification. It might not be standards based, but I think 
Ice qualifies as non-proprietary software because of the openness of its 
specification and source code.

And yes, if you don't want to make your code available under GPL, you 
have to buy a license from us (not for the specification, but for our 
implementation). Our pricing is publicly available on our Web server, so 
we don't make a secret out of this. And yes, we want to make a living 
from selling Ice licenses and support.

If you are saying "at least Michi was honest", it implies that I was 
dishonest in my statement. Is there really any need to make personal 
insults? Did I do anything to you, other than having a different opinion?

-- Marc

0
marc4371 (25)
7/25/2003 9:47:39 PM
Michi Henning <michi@triodia.com> wrote in message news:<Pine.LNX.4.44.0307241509480.1127-100000@diadora.client.uq.net.au>...
> On 24 Jul 2003, Christopher Browne wrote:
> 
> > If there were implementations out there for other languages (Perl?
> > Python?  Lisp?), I'd be more interested; as it stands, CORBA still
> > supports a boatload more languages and environments.

How about an Eiffel mapping? There is no offical Eiffel mapping for
CORBA but there is an unoffical one currently owned by 2AB, inherited
from MICO/E. Perhaps that could be examined for inspiration. Maybe 2AB
would be interested?

-Andrew M.
0
apm35 (156)
7/26/2003 10:29:13 AM
schmidt@macarena.cs.wustl.edu (Douglas C. Schmidt) wrote in message news:<bfru2n$bes@macarena.cs.wustl.edu>...
> Hi Michi,
> 
> 
> The emerging combination of QoS-enabled Lightweight CCM + model-based
> software development, configuration, and deployment tools will provide
> a major paradigm shift in the way that complex, long-lived DRE systems
Hi Doug,

Is there anything in ICE worth ripping off and putting into TAO?

A couple of ideas seem interesting:

a) the data compressed IIOP streams, we could do a pluggable protocol
in TAO called CIOP for compressed IOP.
b) ditto for firewalls, we could have an FIOP pluggable protocol for
NAT and proxy firewalls.
c) a mapping to ISO C++, no need for new middleware here, we can
modify the IDL compiler to write translation utility methods between
CORBA and std datatypes and put these  routines into a utils.h file. 
Kind of like the -GI flag in TAO that generates default server code. 
The utility functions could hide most if not all the memory management
ugliness of the current CORBA c++ mapping.

There might be a few others, I'll probably be posting some
implementations of these ideas in the near future.
 
I think that the idea of rewriting CORBA is misplaced. Since there is
an IDL to C++ binding, it is possible to modify almost any aspect of
the OMG spec by hacking the IDL compiler and/or writing pluggable
protocols.  This approach allows users to define arbitrarily complex
modifications to the CORBA specification and preserves 100%
interoperability with other orbs by switching back to the standard
protocols.

     
--David Janello
Simulation and Searches, LLC
www.simulationandsearches.com
Argon Technology Group, Inc.
www.argon-tech.com
0
djanello (1)
7/26/2003 5:48:32 PM
"apm" <apm35@student.open.ac.uk> wrote in message
news:d1a33011.0307260229.2d8c4ed3@posting.google.com...
>
> How about an Eiffel mapping? There is no offical Eiffel mapping for
> CORBA but there is an unoffical one currently owned by 2AB, inherited
> from MICO/E. Perhaps that could be examined for inspiration. Maybe 2AB
> would be interested?

It really all depends on customer demand. We'll do those things that
customers need the most first, rather than trying to be all things to all
people and spreading ourselves too thin. In terms of adding new
language mappings in general, it's not too hard to do that, provided
the language has a C/C++ call interface. Without that, it's harder because
it means to rewrite the whole run time in that language, which is quite a
bit of work. (BTW -- that's what we did for Ice for Java, because we
wanted a pure Java implementation, not one that depends on C or C++
run-time libraries.)

Cheers,

Michi.

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

0
michi9457 (29)
7/26/2003 10:07:37 PM
Marc Laukien <marc@zeroc.com> wrote in message news:<JnSdnRalfNHgOLyiU-KYvw@speakeasy.net>...
> FUD seems to be your favorite word lately. Whenever there is an opinion 
> you don't like, it's FUD to you.

I disagree, Marc. Doug's use of the acronym "FUD" is perfect for the
unfounded references you and Michi have made regarding the poor
technical quality and fading market strength of CORBA. Does CORBA have
technical problems? Sure! Name me a standard that doesn't! As for the
CORBA market, I've heard various "industry pundits" say it's weak,
it's strong, or it's dead -- take your pick. If you guys were still
selling CORBA, you'd both be posting about how great it is and
defending it, as my "quotes" posting proved. The fact that you guys
can't seem to admit that is amusing at best, misleading at worst, and
perhaps even delusional.

> I read all the stuff about the history, but this doesn't change the fact 
> that there is still only an arcane C++ mapping for CORBA. You can argue 
> about history all you want, fact is that no attempt to start a new C++ 
> mapping to date ever succeeded.

You just have to love developer hubris.

One of the things I find amusing about this thread is the implication
that somehow CORBA lives and dies by its C++ mapping. Technical people
often make the mistake of thinking that technical details actually
matter! CORBA did not succeed because it was the best technical thing
going. Rather, it succeeded due to superior marketing and superior
mindshare, both on the part of the OMG and the many vendors that
support CORBA. If the C++ mapping is as bad as Michi's exaggerations
have claimed it to be, then why didn't CORBA die in 1995 or 1996? In
other words, it's a business thing, not a technical thing. That's why
no C++ mapping has succeeded the existing one -- one hasn't had to!
Much as we might like to think differently, in the whole scheme of
things we developers and our technical perspective have actually had
very little to do with CORBA's success.

Another way to put it is that the C++ mapping could have been 10 times
worse and it wouldn't have mattered. It could have been 10 times
better, and that wouldn't have mattered either. Get over it. From a
business perspective -- and business totally governs how, why, and
when technologies live and die -- your claims about having developed a
superior C++ mapping for Ice don't matter at all. Not at all.

--steve
0
vinoski (4)
7/28/2003 12:29:07 AM
vinoski@ieee.org (Steve Vinoski) wrote in message news:<6c2690b5.0307271629.3ec731ac@posting.google.com>...
>
> You just have to love developer hubris.
>

Indeed. Laziness, Impatience and Hubris: the three essential
traits of a great software engineer (apologies to Larry Wall). Where
would we be without them?
 
> Another way to put it is that the C++ mapping could have been 10 times
> worse and it wouldn't have mattered. It could have been 10 times
> better, and that wouldn't have mattered either. Get over it. From a
> business perspective -- and business totally governs how, why, and
> when technologies live and die -- your claims about having developed a
> superior C++ mapping for Ice don't matter at all. Not at all.

In a previous job, we built a traffic control system (now a
flagship product of the company) around CORBA. Because it was a
standard protocol? Because it was mature technology? Because there
were multiple vendors available? Because it had a great C++ mapping?

These are all good reasons (except perhaps the last), but the
reason we used CORBA was that I had used it before and I reckoned
it was pretty neat. I think you might be surprised how often this
happens.

Bruce Fountain
0
brucef (3)
7/28/2003 6:03:11 AM
Steve Vinoski wrote:
> One of the things I find amusing about this thread is the implication
> that somehow CORBA lives and dies by its C++ mapping.

Actually, I agree with you on this one. The C++ mapping is only one of 
many things that makes Ice different from CORBA. I'm not happy at all 
that this discussion seems to focus on a single detail, namely the C++ 
mapping. This gives the reader the impression that Ice is basically 
CORBA plus a better C++ mapping, which it definitely is not.

-- Marc

0
marc4371 (25)
7/28/2003 9:19:26 AM
"Douglas C. Schmidt" <schmidt@macarena.cs.wustl.edu> wrote in message
news:bfrse9$bd4@macarena.cs.wustl.edu...

> >> Can't it? Why is it necessary to have a standard to build complex
> >> distributed systems?
>
> I find it strange that you would even ask this question Michi.  Pretty
> much by definition, "complex distributed systems" tend to live a long
> time - usually MUCH longer than the "attention span" of COTS providers
> who basis their technologies on non-standard
> tools/platforms/services/etc.

Hmmm. There are a lot of interesting issues coming up here. One is the
life time of distributed systems. That's an interesting one in itself. What
*is*
the average life time of software, and what does the distribution curve look
like? I know that we have the full gamut of life time from days (as in the
financial world,
where a lot of financial modelling programs are written with a life expentance
of less than week), to to years (as for air traffic control system, which tend
to live
for decades). I have to admit that I've never thought much about this -- I
honestly don't know what the distribution curve would look like, or how
skewed it would be. (Bi-modal or even try-modal maybe?) I know that a lot
of software I have written myself was out of date after maybe three or four
years.
But that's simply because I tend to work at the systems level, and I often
write
tools to make up for some deficiency or lack of functionaly in some software
that I'm using. Quite often, the tool I wrote becomes obsolete when the
software
I wrote it for now offers the functionality of the tool, of the software I
wrote the
tool for no longer exists (or I stop using it). Anyway, I digress...

It's interesting to think about the benefits of standardization though. There
are
several I can see off-hand:

- A standard makes it more likely that I'll be able to hire people with the
skill
  I need.

- A standard makes it more likely that the people I hire will understand each
  other.

- A standard makes it more likely that I'll be able to switch software, or
hardware,
  or vendor, or whatever.

- A standard makes it more likely that I'll be able to find literature,
training courses,
  etc.

To extent of the above points, the standard helps to reduce complexity. (It's
less
complex to not have to train a new engineer than to have to train him.) But I'm
not
aware of how standards would reduce complexity of the actual application. The
problem I want to solve doesn't get magically simpler because there is
standard,
I would think.

> >> People built complex distributed systems a long time before there
> >> ever was a standard.
>
> Sure, and these systems have INEVITABLY become albatrosses around the
> necks of the companies that have to maintain them over a long period
> of time.  Some major telecom equipment providers have been virtually
> crippled by the total ownership costs of maintaining their
> cathedral-like switching systems based on proprietary technologies.

Yes and no. I agree that people who use ancient software suffer from
the cost of maintaining that software. The question is how much standards
actually help with that. When you are talking twenty years plus, it seems
that a lot of standards disappear before the software gets a chance to
get as old as that, meaning that, by the end of that period, it seems
irrelevant whether the software was built on what once was a standard.
More relevant seems to be whether, at the time I need maintenance for
my software, whether there is still an active and interested community
around the technology. If so, I'll get my maintenance done; if not, I'll
have a hard time. So, the more relevant criterion seems to be whether
the technology is "alive" as opposed to whether it is standardized.

> >> As far as I can see, the standard doesn't do much to help people
> >> get on top of complexity.
>
> Quite frankly Michi, if you don't see this, you need to spend more
> time working with people building long-lived, complex distributed
> systems!

See above. The complexity of the application domain doesn't disappear
by magic. So, the complexity of the application I want to build is not
reduced by the standard I think. The standard does make it more
likely though I might find people with experience in that space, or
that I might find tools to help me out somehow. So, yes, to that extent,
complexity is reduced. But that isn't reducing the complexity of the
application itself, is it?

> There's now a lot of empirical evidence (i.e., gathered from
> detailed cost/schedule/quality metrics collected over many years) from
> companies like Boeing, Siemens, Raytheon, SAIC, LMCO, etc. that
> illustrates the lifecycle cost savings of developing these types of
> systems using standards-based approaches.

I'm a little bit skeptical. Not that I doubt that these companies haven't
done the studies or shown that they saved money -- I'm sure that they
have. On the other hand, we've been pushing standardization for so
long that we sometimes accept it as a mantra without looking as closely
as we should. For example, I have also seen studies that showed the
tremendous cost savings and quality improvements that companies
experienced when they switched from UNIX to Windows, or from
sendmail to Exchange. I'm sure you'd have no problem finding lots
of people who'd laugh at that :-)

> >> Rather, a standard is meant to provide cross-vendor
> >> interoperability, source code portability, and a well-known
> >> API. But I honestly don't see how a standard would help me to build
> >> complex systems more easily. (I mean, it's not as if the standard
> >> would make the inherent complexity go away, is it?)
>
> I disagree here again Michi.  In fact, if you look at MATURE IT
> industries (e.g., micro-processor manufacturers and the IP equipment
> provider market) you'll see that the use of standards is ESSENTIAL to
> obtaining the economies of scale necessary to focus their R&D
> activities on actually resolving the inherent complexities, rather
> than wasting time rearranging the accidental complexities (which
> ultimately end up being like rearranging deck chairs on the Titanic).

Hmmm... Yes. Clearly, things like a standardized fitting for light bulbs
makes everyone's life easier. The more wide-spread the standard, the
more useful it is, as a rule. And the better the standard works, the more
useful too. I guess that's where I'm having problems with CORBA. It's
a standard, no doubt, but it isn't as good a standard as it should be, not
by a long shot. We know how to do this sort of thing better now, just as
we did when we started CORBA, and DCE started to fade (and DCE
was a standard too).

> Having said that, of course, standards are no panacea.  However, the
> LACK of standards in the middleware domain is SERIOUSLY hurting the
> competitiveness of the world IT distributed systems market.

I think that lack of a good standard definitely hurts the market. I'm not
so sure about lack of poor one though :-)

Cheers,

Michi.

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

0
michi9457 (29)
7/28/2003 11:11:54 AM
"Douglas C. Schmidt" <schmidt@macarena.cs.wustl.edu> wrote in message
news:bfrre8$b9f@macarena.cs.wustl.edu...
> >>
> >> Some CORBA vendors even tried to downplay the fact that they are
> >> CORBA vendors.
>
> The fact that there are (or were) CEOs at certain companies that
> couldn't manage their way out of a wet paper bag should be an
> indictment of their (lack of) leadership skills and vision, rather
> than an indictment of the technology!!!  Fortunately, other CORBA
> vendors are doing quite well, so the overall balance is positive.

I thought it was the standard that mattered, not the technology? Haven't
you been arguing all along that the problems I quoted with CORBA
don't matter, and that CORBA is standard is what matters? As I said
in another post, the usefulness of a standard depends a lot on how
popular it is, how many people are using it, and how many vendors
there are. I've seen quite a few CORBA vendors disappear over the past
three years or so and, for public companies that sell CORBA, the revenue
figures are declining, according to their quarterly reports. (Small wonder,
with half the world chasing the next silver bullet in form of web services...)
That in itself worries me. I remember five years ago, there was something
new and exciting happening with CORBA all the time. Now, it seems
to be comparatively quiet. (Just look at the traffic in this news group. There
was a *lot* more a few years ago.)

> >> And the OMG now focuses much more on MDA than on CORBA.
>
> Of course - that strategy makes a lot of sense since DOC middleware
> has largely been successful and there's a LOT more effort required to
> address the MDA-related challenges.

Forgive me for being skeptical, but I think it will be quite a long time before
computing advances sufficiently to make something like MDA real. The idea
of platform- and architecture-independent modeling isn't new. In essence, it's
just the old dream of capturing the essence of semantics and then mapping
the semantics onto specific platforms. The problem with this is that, to deal
with the complexity, we raise the level of abstraction and model at a higher
abstraction level. But, to do that, by necessity, we have throw detail away
(otherwise we wouldn't be raising the level of abstraction). But it's all the
detail that ends up killing the attempt to then map down to a specific
platform.
(If we retain all the detail, the modeling gets bogged down, if we throw away
the detail. the modeling works, but we don't have the detail anymore when we
need it, namely, when it comes time to deal with the specifics of a platform.)

I'm afraid that these problems are in the nature of the beast and that no
amount
of modeling will ever make them go away.

Cheers,

Michi.

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

0
michi9457 (29)
7/28/2003 11:20:59 AM
"Douglas C. Schmidt" <schmidt@macarena.cs.wustl.edu> wrote in message
news:bfru9m$bfe@macarena.cs.wustl.edu...

> >>  However, you could also argue that bypassing the process and
> >> publishing something on your own is the easy way out.
>
> Bingo - that was Steve and my point, as well.  While it's the easy way
> out, this approach has a habit of not working well in the long-run
> (unless you are one of a handful of giant companies).  I've listed
> examples of operating systems (e.g., Be-OS, NextStep/OpenStep, etc.)
> that bypassed standards to no avail.  There are also plenty of
> middleware technologies in the same boat (e.g., Xshell, Inferno, RMI,
> etc.).

Yep, no doubt, there are plenty of non-standard attempts that have failed.
There are also plenty of standard attempts that have failed. I think we can
each pick the cases to suit our purpose. There are plenty of non-standard
things that have succeeded too.

I guess the conclusion has to be that something being standard or
non-standard is neither a necessary nor a sufficient prerequisite for
success.

Cheers,

Michi.


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

0
michi9457 (29)
7/28/2003 11:24:03 AM
"Steve Vinoski" <vinoski@ieee.org> wrote in message
news:6c2690b5.0307271629.3ec731ac@posting.google.com...

> If you guys were still
> selling CORBA, you'd both be posting about how great it is and
> defending it, as my "quotes" posting proved. The fact that you guys
> can't seem to admit that is amusing at best, misleading at worst, and
> perhaps even delusional.

What surprises me is that you seem to think that the ZeroC team would
just go and build something that is no better than CORBA. Ice was built
by people who have a lot of experience in this domain, and with a proven
track record. (We previously built ORBacus, which most people seemed
to think was a very good ORB.) If we'd just gone and built something
no better than CORBA, we'd have to be very naive indeed.

> One of the things I find amusing about this thread is the implication
> that somehow CORBA lives and dies by its C++ mapping. Technical people
> often make the mistake of thinking that technical details actually
> matter!

Long term, I think they actually do. Short term, not so much, because
market forces, fads, fashions, politics, etc carry a lot of weight. But
it doesn't matter how much people hype up a technology: if it doesn't
deliver, technical reality will set in eventually.

> CORBA did not succeed because it was the best technical thing
> going.

I would disagree with that. It succeeded because it was the best thing
going at the time. (Just like troff in its day.) If I didn't use CORBA,
I couldn't build a heterogenous distributed system at all. So, I used
the only tool available for the job at the time.

> Rather, it succeeded due to superior marketing and superior
> mindshare, both on the part of the OMG and the many vendors that
> support CORBA.

Mindshare certainly had a lot to do with too, yes. The mindshare is
slipping badly though, and has been for over two years. The web
services crowd seem to be getting it all these days... (Pity really --
I've rarely seen something more lacking in technical excellence...)

> If the C++ mapping is as bad as Michi's exaggerations
> have claimed it to be, then why didn't CORBA die in 1995 or 1996?

Like I said: it was the only thing that could do the job. When I have
the choice between using a complex tool to get something done, or
not getting it done at all, I put up with the complex tool. That doesn't
mean that I love the tool...

> In other words, it's a business thing, not a technical thing. That's why
> no C++ mapping has succeeded the existing one -- one hasn't had to!

Pity though that it's still hanging around, with no update in sight.

> Another way to put it is that the C++ mapping could have been 10 times
> worse and it wouldn't have mattered.

No. If it were ten times worse, no-one could use it.

> It could have been 10 times
> better, and that wouldn't have mattered either.

No. If it were ten times better, a significant hurdle to understanding and
programming with CORBA in C++ would be removed and a lot of
people who decided that "CORBA is too complex" would still be
using it.

Language mappings probably have more influence on developer perception
than any other part of a platform. That's because the APIs are the main and
most important human-machine interface for a developer. Give the developer
a complex API, and he/she won't like it. Give him/her a nice and easy API,
and he/she will like the platform as a result.

Cheers,

Michi.

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

0
michi9457 (29)
7/28/2003 11:48:23 AM
Hi Michi,

>> > >> By the way, I agree with you that writing a good C++ mapping isn't
>> > >> so hard. This makes it even more confusing to me why there is no
>> > >> new C++ mapping for CORBA. The only answer I can think of is that
>> > >> neither the CORBA vendors nor the OMG care.
>> >
>> > Is there a reason why you just can't stay away from slinging FUD Marc?
>> 
>> I really don't see the FUD here. I think it's a legitimate question.

The reason that it's FUD is because it's NOT stated as a question at
all - it's a statement that's basically in the same league as "I've
heard rumors you've stopped beating your wife."  There are CORBA
vendors who DO care about the C++ mapping, and there are people in the
OMG who care as well (improving the C++ mapping was one of the major
topics at the OMG Real-time Middleware workshop a couple of weeks
ago).  As Steve pointed out in his reply, however, there are other
forces at work (largely business forces) that perpetuate the status
quo.  I don't think this is a "good thing," BTW, but I think that Marc
is simply spewing FUD by claiming that no one "cares."  Here's an
example of a non-FUD perspective on this:

.. "In our experience trying to improve the C++ mapping, there was
   resistence from key vendors in accepting our suggested
   improvements." 

I suspect that statement is factually correct, whereas Marc's claim that

.. "The only answer I can think of is that neither the CORBA vendors nor
  the OMG care."

is just plain FUD since it implies a grand conspiracy on the part of
CORBa and OMG to perpetuate an inadequate mapping, which is NOT
factually correct and is stated this way just to score marketing
points.

>> Hmmm... The most optimistic estimate I can come up with for getting
>> a new OMG-approved C++ mapping done is 12 months (and I think that
>> I'm being *really* optimistic here). Then add the time it takes
>> vendors to implement the final version and bring it to market, and
>> add the time it takes for customers to switch to the new mapping
>> and get over the learning curve. That will take some time too.

Sure - but the end result will be a *standard* mapping that will be
available from multiple vendors over a very long period of time.  This
is precisely the benefit of a standard, i.e., it may take longer but
it will also last longer (assuming it solves business needs).  When
you consider that people are developing applications that live for
decades, the fact that the mapping took 12 months or so to be improved
is really in the noise!

>> Ice isn't burdened by a standards process and historical mistakes,
>> which makes it comparatively easy to excel technically because we
>> are free to apply the lessons of the past.

Again, as Steve and I and others have pointed out, it's pretty easy to
improve stuff technically if you're not constrained by key forces that
are necessarily for technology to remain viable over the long-term.
Microsoft has used this as a rationale to modify their distributed
computing technologies every 2-3 years for more than a decade.  I can
remember you criticizing this strategy MANY times during various
discussions over the years, yet now you embrace it - how ironic!

>> CORBA simply can't do that -- that's the price of standardization.

Exactly - and as you yourself have argued for many years (until
recently), there are also many benefits that accrue from having a
standard.

>> What surprises me though is how strongly you and Steve react to
>> Ice.

Actually, I don't have any negative reactions to *Ice* - I think it
sounds cool.  My negative reactions are to the way that you and Marc
are spewing FUD and making a number of unsubstantiated claims (e.g.,
about Ice's performance), which is really unbecoming of both of you
and shouldn't be necessary in order to promote Ice.

In your case Michi, I'm also disappointed in the way that you've
"changed your stripes" and gone from being a person who harshly
criticized CORBA vendors in the past for using comp.object.corba as an
advertising venue to turning this forum into an "Ice promo."  While
it's certainly your right and privilege to do this, it just strikes me
as being rather hypocritical.  I have no such complains about Marc -
he never beat up people for doing this in the first place, so he's not
being inconsistent.

>> We've gone and done something new that, in our opinion, is better
>> and more elegant than CORBA. So what?  I would have thought that
>> you'd appreciate it if someone advanced the state of the art
>> another notch or two.

There's certainly nothing wrong with advancing the state of the art -
that's the whole point of R&D.  I'm largely just criticizing your
methods here, not your motives.

        Doug

>> Hmmm... The most optimistic estimate I can come up with for getting
>> a new OMG-approved C++ mapping done is 12 months (and I think
>> that I'm being *really* optimistic here). Then add the time it takes
>> vendors to implement the final version and bring it to market, and add
>> the time it takes for customers to switch to the new mapping and get
>> over the learning curve. That will take some time too.
>> 
>> What I find interesting in this thread is that I have raised quite a few
>> points of criticism about CORBA, but the only one that is discussed
>> is the C++ mapping. And, instead of discussing what's good and bad
>> about a particular thing, I hear "Michi, you are exaggerating, it isn't as
>> bad as you make it sound." I guess that's one way to avoid addressing
>> the specific points of criticism.
>> 
>> One advantage Ice has over a standard such as CORBA is that we have
>> a level of freedom and agility that CORBA can only dream of.
>> Ice isn't burdened by a standards process and historical mistakes, which
>> makes it comparatively easy to excel technically because we are free to
>> apply the lessons of the past. CORBA simply can't do that -- that's the
>> price of standardization. What surprises me though is how strongly
>> you and Steve react to Ice. We've gone and done something new that,
>> in our opinion, is better and more elegant than CORBA. So what?
>> I would have thought that you'd appreciate it if someone advanced the
>> state of the art another notch or two.
>> 
>> Cheers,
>> 
>> Michi.
>> 
>> --
>> Michi Henning              Ph: +61 4 1118-2700
>> ZeroC, Inc.                http://www.zeroc.com
>> 


-- 
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.schmidt@vanderbilt.edu
0
7/28/2003 12:34:21 PM
Douglas C. Schmidt wrote:
> The reason that it's FUD is because it's NOT stated as a question at
> all - it's a statement that's basically in the same league as "I've
> heard rumors you've stopped beating your wife."  There are CORBA
> vendors who DO care about the C++ mapping, and there are people in the
> OMG who care as well (improving the C++ mapping was one of the major
> topics at the OMG Real-time Middleware workshop a couple of weeks
> ago).  As Steve pointed out in his reply, however, there are other
> forces at work (largely business forces) that perpetuate the status
> quo.  I don't think this is a "good thing," BTW, but I think that Marc
> is simply spewing FUD by claiming that no one "cares."  Here's an
> example of a non-FUD perspective on this:
> 
> . "In our experience trying to improve the C++ mapping, there was
>    resistence from key vendors in accepting our suggested
>    improvements." 
> 
> I suspect that statement is factually correct, whereas Marc's claim that
> 
> . "The only answer I can think of is that neither the CORBA vendors nor
>   the OMG care."
> 
> is just plain FUD since it implies a grand conspiracy on the part of
> CORBa and OMG to perpetuate an inadequate mapping, which is NOT
> factually correct and is stated this way just to score marketing
> points.

This is getting really silly. Are you now the authority for which 
wording somebody has to use to express an opinion, in order for the 
opinion not to be labelled as FUD? Also, is it possible to get at some 
point beyond the debate about what you consider FUD and what not?

> 
> Actually, I don't have any negative reactions to *Ice* - I think it
> sounds cool.  My negative reactions are to the way that you and Marc
> are spewing FUD and making a number of unsubstantiated claims (e.g.,
> about Ice's performance), which is really unbecoming of both of you
> and shouldn't be necessary in order to promote Ice.

Michi made claims about *efficiency*. You completely ignored my recent 
posting in which I explained why we believe that Ice is more efficient 
than CORBA. For example, the much more compact data encoding, or the 
faster message forwarding.

If efficiency only means latency and throughput to you, then I also 
pointed out several times that certain real-time CORBA ORBs are better 
in this respect. (But we are working on that, too.)

So to say that we are spreading FUD, because our claims are 
unsubtantiated, while at the same time ignoring the technical detail we 
provide to explain our claims, is quite unprofessional.

-- Marc

0
marc4371 (25)
7/28/2003 1:22:18 PM
Hi Marc,

>> This is getting really silly. Are you now the authority for which
>> wording somebody has to use to express an opinion, in order for the
>> opinion not to be labelled as FUD?

Nope - I just call 'em as I see 'em.

>> Also, is it possible to get at some point beyond the debate about
>> what you consider FUD and what not?

As I said earlier, if you stick to technical arguments rather than FUD
I won't complain.

>> Michi made claims about *efficiency*. You completely ignored my
>> recent posting in which I explained why we believe that Ice is more
>> efficient than CORBA. For example, the much more compact data
>> encoding, or the faster message forwarding.

And as usual, the "proof" is in the pudding, i.e., we need to get some
objective benchmarks to determine whether these claims hold up in
practice.  Moreover, given that many CORBA ORBs have pluggable
protocol frameworks, it's straightforward to enable an ORB to achieve
the same benefits as Ice here (especially if interoperability isn't
important).  Thus, I don't think this is a particularly relevant
differentiator (particularly now that CORBA has an extensible
transport framework).

>> If efficiency only means latency and throughput to you, then I also
>> pointed out several times that certain real-time CORBA ORBs are
>> better in this respect. (But we are working on that, too.)

Ok - that sounds like a good technical discussion.  Let's see how
things stack up once Gautam's back on line.  He did some preliminary
measurements late last week that showed Ice was about twice as slow as
ORBexpress for data types like structs and sequences.  We hope to get
more definitive measurements shortly with a broader range of ORBs and
data types, at which point we can have a detailed TECHNICAL
discussion, as opposed to marketing fluff.

Take care,

        Doug
-- 
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.schmidt@vanderbilt.edu
0
7/28/2003 1:40:28 PM

"Douglas C. Schmidt" <schmidt@macarena.cs.wustl.edu> wrote in message
news:<bfrpkn$b6f@macarena.cs.wustl.edu>...

> > How about we talk about this at JAOO? Steve Vinoski, Doug Lea,
> > Bjarne Stroustrup, and Jim Coplien will all be there too. Should
> > make for a lively evening over a few beers :-)
>
> Sounds like a great plan!  Now, all we need to do is invite Com Box
> and we'll REALLY have a row!

Early june (before this thread started) I asked the organizers of JAOO
to arrange for a discussion of "CORBA vs. ICE - complexity and future",
because Douglas C. Schmidt, Michi Henning og Steve Vinosky would be
present.
They were positive, and it seems like you guys would be positive as well.
I hope for a Goldfish Bowl.

The topics are basicly what has been discussed in this thread, and it
would be very interesting to have a discussion for those who come to JAOO.

I didn't realize that the other people mentioned here where relevant in such
a discussion - but of course they are.

Some of the discussion is very similar to C++ vs. ????, like:
  * Is C++ to complex to be usefull (if the claim is repeated often enough,
some people might even believe that it's more complex than it actually is) ?
  * Is the C++ standardization process usefull if it is not perfect ?
  * Has the C++ Standard done any good, since most compiler vendors
doesn't implementent it 100 % (only very close to 100%) now 5-6 years
after the Standard was completed ?
  * Wouldn't it be better to replace C++ by some simpler, proprietary
programming language (it can always be extended later on :-) ) ?

I would expect (I don't _know_ for a fact) that Frank Bushmann, who will
also come to JAOO, has some interesting experience from Siemens, on how
hard it actually is to use CORBA, how hard it actually to switch between
CORBA implementation, how important standards like CORBA are for project
that he knows in the real world.


Kind regards

Mogens Hansen


0
mogens_h (4)
7/28/2003 2:37:05 PM
Hi Marc,

>> We gave you many technical arguments, some of which you
>> conveniently ignored.

In general, if I ignore something it's either because I agree with
you, don't know enough about a particular topic to argue one way or
the other, or because the point is not worth arguing.

>> > And as usual, the "proof" is in the pudding, i.e., we need to get some
>> > objective benchmarks to determine whether these claims hold up in
>> > practice.  Moreover, given that many CORBA ORBs have pluggable
>> > protocol frameworks, it's straightforward to enable an ORB to achieve
>> > the same benefits as Ice here (especially if interoperability isn't
>> > important).  Thus, I don't think this is a particularly relevant
>> > differentiator (particularly now that CORBA has an extensible
>> > transport framework).
>> 
>> The proof is in the math. You can simply calculate the message sizes.

Unfortunately, I do systems R&D, not theory.  Thus, as I mentioned
above, the key questions are:

.. Do the differences in the message size actually make a difference
  empirically, and if so, under what conditions.  We've done all sorts
  of experiements with TAO over the years shaving off various amounts of
  bytes in the GIOP headers and we've found that in many cases it doesn't
  make much difference at all since that's not where the bottleneck is.
  There are published papers on this at
  
  http://www.cs.wustl.edu/~schmidt/ACE_wrappers/TAO/docs/pluggable_protocols/
  
  for empirical results.

.. Is there something inherent to what Ice does vs. what a CORBA
  implementation can do using either the ETF and/or its own
  proprietary messaging format (while still preserving the standard
  CORBA programming API).  As David Janello pointed out in a recent
  post, a lot of the stuff you're doing in Ice can be (or already has
  been) integrated into CORBA, thereby providing a standards-based
  programming API with a custom implementation. 

>> Are you actually reading what I write, or do you just respond to
>> further attack Ice?

Whew, you and Michi are sure defensive about Ice!  As I mentioned to
Michi, I'm not objecting to Ice per se, I'm objecting to your
marketing tactics, which are often (though by no means always) heavily
based on FUD.  When you don't use FUD, I don't object (as much).

>> This is now the 3rd time I told you that ORBexpress has better
>> latency and throughput than Ice. Why do you insist on proving
>> something which I already stated as being correct?

When you calm down, please go back and read my original posting more
carefully.  Here's what it said:

>> > Ok - that sounds like a good technical discussion.  Let's see how
>> > things stack up once Gautam's back on line.  He did some preliminary
>> > measurements late last week that showed Ice was about twice as slow as
>> > ORBexpress for data types like structs and sequences.  We hope to get
>> > more definitive measurements shortly with a broader range of ORBs and
                                                 ^^^^^^^^^^^^^^^^^^^^^
In other words, we need to empirically validate whether your claims
that only so-called "Real-time ORBs" are faster than Ice.  If
general-purpose ORBs are also faster, it calls into question a lot of
the stuff you guys were claiming initially about the "inherent"
inefficiency of CORBA.

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.schmidt@vanderbilt.edu
0
7/28/2003 2:52:31 PM
Doug, I think its very disappointing to see someone that I highly
respect resort to personal attacks on Michi in an attempt to prove your
argument.

I find it amazing to hear you claim that the OMG isn't losing momemtum.
It was very clear to me after a few years of regularly attending the
OMG meetings that the interest was seriously waning. Historically I
find this similar to DCE. An open standard which was cool for a while,
but interest waned and many of the contributors moved onto CORBA. Now
when I look at the list of contributors to the fashionable W3C
committees, many of them look very familiar.

You go on at great length about the benefits of standardization.
However, I suspect that many companies have failed realized the full
benefit with the CORBA standards because the standards were incomplete,
and overly complex. You attempt to prove some of his points below.

Douglas C. Schmidt wrote:
> ...
>> Vendors insist on adding their own extensions (often incompatible 
>> with the specification), much of what is needed is underspecified, 
>> and the much-touted freedom of choosing a vendor largely does not 
>> exist: even with 100% CORBA compliance, another vendor may not 
>> support the platform I need, may not provide the language mapping I
>>  need, may not support the compiler I need, or may not implement
>> the particular part of the CORBA spec I need.
> 
> 
> While this is often true for proprietary ORBs, it just doesn't make 
> sense given the availability of very good open-source ORBs.
> Companies like OCI and PrismTech make a good business catering
> PRECISELY for customers with the types of needs you mention above,
> and they support multipe ORBs (e*ORB, TAO, JacORB, and ORBit).

And:

> ...
>> And, to boot, it provides features that neither general-purpose nor
>>  DRE CORBA implementations can provide: a persistence service that
>> is incredibly easy to use,
> 
> 
> BTW, it's worth pointing out that the AMD approach you mention here
> is remarkably similar to the AMH approach implemented by TAO back in 
> 2000!

This is obviously a very useful proprietary feature that locks the
enduser into using TAO.

BTW, why was such an obviously useful and necessary feature never
standardized?

> ...
>> You mean painful because of the BOA? But the BOA was a standard
>> too!
> 
> 
> Pulleeeeeze Michi, don't EVEN go there!!!!

Why not? From the point of view of source code portability code *all*
BOA implementations were proprietary. What is your point here? That such
things never occur anymore? Because that isn't the case either!

>> Bidirectional IIOP and CORBA security were standards too, as I 
>> recall. What has become of those?
> 
> 
> As far as I know, TAO's supported bi-directional GIOP/IIOP for the 
> past 3-4 years.  As for CORBA security, please see the discussion 
> above about this.

CORBA security prior to CSIV2 was so ill specified that any commercial
implementation was for all intents and purposes proprietary. Where was
the benefits of standardization for companies that used these
implementations?

From what I can tell the only two ORBs to implement bi-dir GIOP/IIOP
are JacORB and TAO (can they interoperate? The last message I can find
on this indicates that they cannot). In addition bi-dir GIOP/IIOP has a
number of specification problems...

> ...
>> Last time I looked, there wasn't a single commercial vendor that 
>> would provide CCM, load balancing, transactions, and fault 
>> tolerance. (Pick any two, and you just might be lucky.)
> 
> 
> Well, there's at least one commercially supported ORB where load 
> balancing, fault tolerance, transactions, and CCM are all supported 
> (I'll let you guess which one it is ;-)) and I'll let the other ORB 
> vendors do their own marketing.

Do you think that xots (working on alpha 0.80?) is ready for prime
time? That notwithstanding...

- Can the TAO transaction service interoperate with another ORBs
transaction service? I highly doubt it since up until very recently the
XA format ids could clash. This was fixed by a recent RTF (finally),
but as of this date the OMG hasn't assigned any... This means a clash
of transaction ids is possible.

- Load balancing isn't specified, so this is proprietary.<br>

> .. Hum, I guess you haven't read the Real-time CORBA spec then?  It's
> had a standard threading model since 1998?  Please see
> 
> http://www.cs.wustl.edu/~schmidt/report-doc.html
> 
> for a serious of columns on Real-time CORBA and its threading model 
> that Steve and I wrote several years ago.

Well, its great that this is standardized for a RT ORB. However, most
of the market wants this in a non-RT ORB. How is that effort coming
along?

>> And it provides that performance with APIs that are a fraction of
>>> CORBA's in complexity, and with a smaller footprint.
> 
> Yes, again, this claim needs to be substantiated empirically.

Which claim needs to be substantiated? How about a line count of the
POA API vs. the Ice API that offers equivalent functionality.

I took the PortableServer.idl and removed the blank lines and comments.
Then I took ObjectAdapter.ice, removed the commands and merged in
ServantLocator.ice.

I claim these offer equivalent functionality (FUD? Take a look at the
ice documentation).

I get 29 lines of slice code for the Ice object adapter, and 211 lines
of IDL for the POA.

> ... Doug

Best Regards, Matthew
--
matthew at zeroc.com
0
7/28/2003 2:56:24 PM
Douglas C. Schmidt wrote:
>>>
>>>The proof is in the math. You can simply calculate the message sizes.
> 
> 
> Unfortunately, I do systems R&D, not theory.  Thus, as I mentioned
> above, the key questions are:

So in systems R&D you shouldn't even consider the number of bytes a 
protocol message takes as relevant? You must be speaking about a 
different kind of systems R&D than what I have in mind.

> 
> . Do the differences in the message size actually make a difference
>   empirically, and if so, under what conditions.  We've done all sorts
>   of experiements with TAO over the years shaving off various amounts of
>   bytes in the GIOP headers and we've found that in many cases it doesn't
>   make much difference at all since that's not where the bottleneck is.
>   There are published papers on this at
>   
>   http://www.cs.wustl.edu/~schmidt/ACE_wrappers/TAO/docs/pluggable_protocols/
>   
>   for empirical results.

In many cases, it doesn't make a difference. In other cases, such over 
slow modem connections, it makes a huge difference.

> 
> . Is there something inherent to what Ice does vs. what a CORBA
>   implementation can do using either the ETF and/or its own
>   proprietary messaging format (while still preserving the standard
>   CORBA programming API).  As David Janello pointed out in a recent
>   post, a lot of the stuff you're doing in Ice can be (or already has
>   been) integrated into CORBA, thereby providing a standards-based
>   programming API with a custom implementation. 

Of course you can implement a more efficient encoding for CORBA, too. 
However, not without changing CDR, so the standardized pluggable 
transport interface won't help.

If we continue the discussion this way, we might end up with concluding 
that you can improve CORBA in all kinds of areas to make it more similar 
to Ice. Well, good luck, then you have a major CORBA re-write before you.

> 
> 
>>>Are you actually reading what I write, or do you just respond to
>>>further attack Ice?
> 
> 
> Whew, you and Michi are sure defensive about Ice!  As I mentioned to
> Michi, I'm not objecting to Ice per se, I'm objecting to your
> marketing tactics, which are often (though by no means always) heavily
> based on FUD.  When you don't use FUD, I don't object (as much).

I'm not sure if we should continue this thread. This becomes a flame 
war, for which I don't like to waste my time.

-- Marc

0
marc4371 (25)
7/28/2003 4:12:08 PM
Hi Matt,

>> Doug, I think its very disappointing to see someone that I highly
>> respect resort to personal attacks on Michi in an attempt to prove
>> your argument.

Well, it looks like everyone is just going to be very disappointed
with everyone these days.  I'm disappointed that Michi and Marc have
resorted to FUD in an attempt to prove their arguments.  I'm
disappointed that Michi isn't abiding by his own rules for USENET
postings, etc.  There's plenty of disappointment to go around.

>> I find it amazing to hear you claim that the OMG isn't losing
>> momemtum.

I don't recall ever saying that.  IIRC, my point was that CORBA is
doing quite well, particularly in the realm of mission-critical
distributed real-time and embedded (DRE) systems, which is the area
that I care about.

>> You go on at great length about the benefits of standardization.
>> However, I suspect that many companies have failed realized the
>> full benefit with the CORBA standards because the standards were
>> incomplete, and overly complex.

As Steve and I have pointed out repeatedly, this can be said for
pretty much all de facto and de jure standards, e.g., UNIX/POSIX, C,
C++, Windows, X-Windows, MFC, ACE, SOAP, COM/DCOM, etc.  The fact that
there are flaws in all these standards doesn't (necessarily)
invalidate their utility.

>> This is obviously a very useful proprietary feature that locks the
>> enduser into using TAO.

Precisely - which is no different than Ice in this regard.  I was
simply pointing out that (1) Ice's AMD and TAO's AMH were very similar
and (2) it's certainly possible to add these capabilities to CORBA.

>> BTW, why was such an obviously useful and necessary feature never
>> standardized?

It would be a great thing to standardize!  If I worked for a company
that would be one of the top things on my list to standardize.
Hopefully, it WILL be standardized at some point by the OMG, at which
point this discussion will be moot.  The difference, of course, is
that with Ice it is unlikely to EVER be standardized (unless Ice
becomes adopted by a standardization effort), whereas with CORBA it
COULD be standardized.

Check out

http://www.cs.wustl.edu/~schmidt/gifs/futility.jpeg

for my earlier perspective on this issue in case you don't want to
re-read what I wrote earlier.

>> >> You mean painful because of the BOA? But the BOA was a standard
>> >> too!
>> > 
>> > 
>> > Pulleeeeeze Michi, don't EVEN go there!!!!

>> Why not?

Because everyone with half a brain knows the BOA was a COMPLETE botch!

>> From the point of view of source code portability code *all* BOA
>> implementations were proprietary. 

Yup.

>> What is your point here? 

That focusing obsessively on fiascos like the BOA and POS is a
strawman.

>> That such things never occur anymore? Because that isn't the case
>> either!

Matt, you seem to be mistaking me for someone who is an ardent
defender of the OMG, which isn't the case.  I'm therefore not going to
feel compelled to respond to these points you're making since you're
arguing with a strawman.

>> CORBA security prior to CSIV2 was so ill specified that any
>> commercial implementation was for all intents and purposes
>> proprietary. Where was the benefits of standardization for
>> companies that used these implementations?

Nope!

>> From what I can tell the only two ORBs to implement bi-dir
>> GIOP/IIOP are JacORB and TAO (can they interoperate? The last
>> message I can find on this indicates that they cannot).

That would be a good question to ask to PrismTech
<awf@prismtechnologies.com> and OCI <spence_m@ociweb.com>, both of
whom support JacORB and TAO commercially.  My guess is that if there
are customers who need this capability, it works (or can be trivially
made to work).

>> In addition bi-dir GIOP/IIOP has a number of specification
>> problems...

Ok, so these are things that should be fixed.  I find it interesting
that the ZeroC "solution" is to scrap the entire CORBA specification
and write something that doesn't interoperate with ANYTHING!

>> Do you think that xots (working on alpha 0.80?) is ready for prime
>> time? That notwithstanding...

I don't work on XOTS, but that's a good question to ask Christoph
Liebig <xfrog2000@yahoo.com>.

>> - Can the TAO transaction service interoperate with another ORBs
>> transaction service? I highly doubt it since up until very recently the
>> XA format ids could clash. This was fixed by a recent RTF (finally),
>> but as of this date the OMG hasn't assigned any... This means a clash
>> of transaction ids is possible.

Again, this isn't my bailwick, but Christoph would know the status.

>> - Load balancing isn't specified, so this is proprietary.<br>

As you may or may not know, there's an effort to standardize Load
Balancing within the OMG.  At this point, there are several
implementations (in TAO and in JacORB from PrismTech) of the
prototypical Load Balancing specification that was developed for an
earlier round of the OMG LB specification effort.  Check out 

http://www.cs.wustl.edu/~schmidt/corba-research-design.html
http://www.cs.wustl.edu/~schmidt/corba-research-performance.html

for papers that describe the initial prototypes of the spec.

>> Well, its great that this is standardized for a RT ORB. However,
>> most of the market wants this in a non-RT ORB.  How is that effort
>> coming along?

If you check out the column that Steve and I wrote at

http://www.cuj.com/experts/2003/vinoski.htm

or the tutorial on the topic we wrote at

http://www.cs.wustl.edu/~schmidt/RT-CORBA.ppt

you'll see that there's really nothing "real-time" specific in the
threading model defined in the Real-time CORBA spec.  As a result, any
CORBA vendor can implement this and non-real-time ORBs will be able to
use a standardized API for threading in CORBA.  TAO, ORBexpress, and
e*ORB all support this capability - and if customers of other ORBs
want it, I'm sure their vendors can/will add it without any problems.

>> >> And it provides that performance with APIs that are a fraction of
>> >>> CORBA's in complexity, and with a smaller footprint.
>> > 
>> > Yes, again, this claim needs to be substantiated empirically.
>> 
>> Which claim needs to be substantiated?

Two things:

1. That the performance of Ice is comparable with top CORBA ORBs

2. That the footprint of Ice is comparable with top CORBA ORBs

Again, I'm not arguing that this isn't the case - I just haven't seen
any empirical justifications for these claims from you folks yet.  As
I said to Michi, once these claims are substantiated empirically
(e.g., by Gautam's middleware comparitor environment) we can have an
actual technical discussion, rather than a marketing FUD discussion.

>> How about a line count of the POA API vs. the Ice API that offers
>> equivalent functionality.

It's not exactly clear what that proves.  One of my earlier points was
that most large-scale systems provide domain-specific wrappers for the
underlying middleware, which is often MUCH smaller to the server
application programmers than any general-purpose mapping.  Moreover,
as model-based software development tools continue to evolve, most (if
not all) of this sort of "glue" code will be generated automatically.
In both cases, the fact that the Ice POA is simpler than the CORBA POA
is really in the noise.  However, the fact that CORBA is a STANDARD
makes a HUGE difference for organizations who are developing complex
mission-critical DRE systems since these systems need to live for a
long time.

BTW, I complement you on actually sticking with technical issues in
your email.

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.schmidt@vanderbilt.edu
0
7/28/2003 4:20:19 PM
Douglas C. Schmidt wrote:
> Ok, so these are things that should be fixed.  I find it interesting
> that the ZeroC "solution" is to scrap the entire CORBA specification
> and write something that doesn't interoperate with ANYTHING!

We actually considered adding IIOP compatibility to Ice. However, IIOP 
is very strongly coupled with the CORBA type system, therefore this is 
very difficult. We didn't want to use the CORBA type system, because we 
feel that it is both too complex and too limiting. (Please don't tell me 
that this is FUD!)

While you are right that Ice currently doesn't interoperate with 
anything, this will most likely change. While we are certainly no SOAP 
fans, we can add SOAP or XML-RPC support in the future. Ice is already 
prepared for that: It can marshal Ice data types in a format that is 
already very close to SOAP/XML-RPC, for our persistence service 
"Freeze". It also makes use of XML schemas to provide for database 
migration, if the Slice description of the stored data changes. (CORBA 
doesn't offer anything like this...)

For more information, please have look at our documentation at 
http://www.zeroc.com/download.html

-- Marc

0
marc4371 (25)
7/28/2003 4:50:42 PM
Hi Michi,

>> I thought it was the standard that mattered, not the technology?
>> Haven't you been arguing all along that the problems I quoted with
>> CORBA don't matter,

No, I haven't said that don't matter - I've been saying that they
aren't the showstoppers that the Ice team would have everyone believe.
As Steve pointed out recently, people reading your early posts in this
thread would think that no one had ever managed to write a successful
CORBA application in C++!!

>> and that CORBA is standard is what matters? 

CORBA as a standard is certainly important - though it's more than
just the standard that users/customers ultimately want - they also
want technology that WORKS!

>> As I said in another post, the usefulness of a standard depends a
>> lot on how popular it is, how many people are using it, and how
>> many vendors there are.

No disagreement there.

>> I've seen quite a few CORBA vendors disappear over the past three
>> years or so and, for public companies that sell CORBA, the revenue
>> figures are declining, according to their quarterly reports.

As I mentioned in my earlier reply to Marc, at the same time we see a
huge increase in the adoption of open-source implementations of CORBA,
with many commercial companies providing support a la RedHat, SuSe,
Debian, etc.  Just as there's been a decrease in the number of
proprietary versions of UNIX (only to be replaced with a consolidation
around Linux), I think we're seeing the same thing happening in the
CORBA market.  Check out

http://www.cs.wustl.edu/~schmidt/commercial-support.html

for a small sampling of what's going on with ACE+TAO, where there are
now companies in six countries and three continents providing support
for ACE+TAO.

>> (Small wonder, with half the world chasing the next silver bullet
>> in form of web services...)  

Yes, indeed!  This is something I believe you and I still agree on ;-)

>> That in itself worries me. I remember five years ago, there was
>> something new and exciting happening with CORBA all the time. Now,
>> it seems to be comparatively quiet. (Just look at the traffic in
>> this news group. There was a *lot* more a few years ago.)

Yes, that was back when you were generating a lot of it ;-) ;-).  But
seriously, this issue was discussed on comp.object.corba about six
months ago.  My response at the time still holds: most CORBA users are
posting questions on the newsgroups and mailing for the ORB(s) they
are using since they get much more in-depth feedback from active user
communities.  On any given day, comp.soft-sys.ace (which also serves
as the TAO newsgroup) gets 2-3 times more CORBA-related postings than
comp.object.corba.

>> Forgive me for being skeptical, but I think it will be quite a long
>> time before computing advances sufficiently to make something like
>> MDA real.

Actually, it's already working quite nicely - particularly in the
realm of DRE systems.  If you do a google search on "MoBIES" you'll
find dozens of links to projects that are part of the DARPA
Model-based Integration of Embedded Systems (MoBIES) program.  Some of
the flagship work is being done at the Institute for Software
Integrated Systems (ISIS) at Vanderbilt University.  Check out

http://www.isis.vanderbilt.edu/mda.html
http://www.isis.vanderbilt.edu/research/mic.html

for information on the overall technology thrusts.  Many of these
tools are available for online download, in particular the Generic
Modeling Environment (GME), which you can obtain from

http://www.isis.vanderbilt.edu/Projects/gme/default.html

These tools and technologies are being used successfully in a number
of very large-scale DRE systems in domains such as avionics,
vehtronics, and software defined radios.  There is also an effort
afoot to standardize these capabilities.  Please see

http://www.omg.org/news/meetings/tc/MIC_Emb_day.pdf

for meetings at the September 2003 OMG meeting that will address these
topics.

>> I'm afraid that these problems are in the nature of the beast and
>> that no amount of modeling will ever make them go away.

There's no denying that the problems are hard.  However, there are
some extremely useful model-based software development solutions that
are maturing now, so I recommend you spend some time to check it out.
A lot of this stuff is making the middleware types of issues that
we've historically wrestled with "disappear", which is ultimately a
"Good Thing"[TM] - though it'll be a "disruptive technology" for
middleware vendors.  If you want to see the Innovator's Dilemma at
work for our field, this is the place to look!  There's additional
thoughts on these topics in our paper at

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

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.schmidt@vanderbilt.edu
0
7/28/2003 4:53:32 PM
schmidt@tango.doc.wustl.edu (Douglas C. Schmidt) wrote in message news:<bg358d$5so@tango.doc.wustl.edu>...
> ...
> In your case Michi, I'm also disappointed in the way that you've
> "changed your stripes" and gone from being a person who harshly
> criticized CORBA vendors in the past for using comp.object.corba as an
> advertising venue to turning this forum into an "Ice promo."

This is grossly unfair & untrue. You make it seem like Michi is
posting hundreds of articles on Ice in this newsgroup, when the
reality is that Michi *still* provides helpful advice to everyone on
CORBA to this very day!

Before this thread Michi posted one article on Ice in this newsgroup
announcing it as a possible alternative to CORBA. How is that pimping
Ice? I could more fairly accuse you of pimping ACE + TAO on this
newsgroup. A casual google search (author:schmidt ACE
group:comp.object.corba) shows 710 articles. A google search for Michi
(author:michi group:comp.object.corba) shows 3,840 - of which
precisely 2 mentioned Ice.

I don't have a problem with anyone questioning our technical claims --
in fact, I welcome it. I strongly believe in the value of our
technology and use it in implementing a production system every day (I
eat my own dogfood). But I do have a severe problem with attacking
anyone personally.

Best Regards, Matthew
0
7/28/2003 5:36:28 PM
Hi Michi,

>> Hmmm. There are a lot of interesting issues coming up here. One is
>> the life time of distributed systems. That's an interesting one in
>> itself. What *is* the average life time of software, and what does
>> the distribution curve look like? I know that we have the full
>> gamut of life time from days (as in the financial world, where a
>> lot of financial modelling programs are written with a life
>> expentance of less than week),

Right - and in time-to-market-driven environments like this, I agree
with your point that simplicity is a MAJOR determinant, rather than
standards-compliance, super low-latency, etc.

>> to to years (as for air traffic control system, which tend to live
>> for decades).

Agreed - large-scale mission-critical DRE systems have different time
scales.  Check out

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

for a paper we wrote that describes some of the technologies that are
needed to address the challenges of long-lived DRE systems.

>> I have to admit that I've never thought much about this -- I
>> honestly don't know what the distribution curve would look like, or
>> how skewed it would be. (Bi-modal or even try-modal maybe?)

Or perhaps even triodia ;-)

>> I know that a lot of software I have written myself was out of date
>> after maybe three or four years.  But that's simply because I tend
>> to work at the systems level, and I often write tools to make up
>> for some deficiency or lack of functionaly in some software that
>> I'm using. Quite often, the tool I wrote becomes obsolete when the
>> software I wrote it for now offers the functionality of the tool,
>> of the software I wrote the tool for no longer exists (or I stop
>> using it). Anyway, I digress...

;-) Your point is well taken, however.  Not all types of systems
require the benefits (and costs) of standardization.  Complex
mission-critical DRE systems just happen to be a class of system that
often does.

>> It's interesting to think about the benefits of standardization
>> though. There are several I can see off-hand:
>>
>> - A standard makes it more likely that I'll be able to hire people with the
>> skill I need.

Agreed.

>> - A standard makes it more likely that the people I hire will understand each
>>   other.

Right.

>> - A standard makes it more likely that I'll be able to switch software, or
>> hardware, or vendor, or whatever.

Yes - depending on how defined/implemented the standard, of course ;-)

>> - A standard makes it more likely that I'll be able to find
>> literature, training courses, etc.

Right, though I would also add:

- A standard that gets suffcient "traction" in the market place (e.g.,
  IP, the x86 instruction set, POSIX, CORBA, etc.) enables major
  improvements in quality of service because it enables companies to
  leverage/amortize their R&D efforts "below" the API/protocol defined
  by the standard.  This is literally the reason why there's a
  "Moore's Law" and a "Metcalf's Law" for hardware and networks. 

>> To extent of the above points, the standard helps to reduce
>> complexity. (It's less complex to not have to train a new engineer
>> than to have to train him.)

Agreed.

>> But I'm not aware of how standards would reduce complexity of the
>> actual application. The problem I want to solve doesn't get
>> magically simpler because there is standard, I would think.

I don't think anyone ever claimed this stuff is "magic"!!!  But let's
see if we can apply some context to speak concretely here.  For
example, assume that we want to build a product-line architecture for
real-time avionics mission computing systems, e.g., the type of DRE
systems described in our papers at

http://www.cs.wustl.edu/~schmidt/corba-research-realtime.html

Before the advent of middleware technologies like Real-time CORBA
these systems were heavily stovepiped, where each different airplane
(e.g., F-18 vs. F-15) and airplane VARIANT (e.g., F-15 E vs. F-15 K)
was COMPLETELY different.  As you might expect, in this situation the
complexity of applications written for these platforms was VERY high
since each development team had to not only understand the application
domain, but also had to understand the complexities of all the
distributed computing "stuff" we now call "middleware."  This was
ENORMOUSLY tedious, error-prone, time-consuming, and expensive.

The major win of moving to a standard like Real-time CORBA in this
domain was push the complexity of the distributed computing "stuff"
into the middleware, thereby GREATLY simplifying the tasks of
application developers.  There is now plenty of evidence that
illustrates how effectively this stuff works in practice, i.e.,
companies like Boeing have tracked the productivity and quality
increases of standards-based middleware solutions and show that they
have substantial savings over the lifecycle.

As for what SPECIFICALLY the standard contributes to all of this -
companies developing complex, long-lived mission-critical DRE systems
are VERY leary of getting themselves wrapped around the axle of
proprietary COTS solutions since they know from experience this leads
them into ALL sorts of problems with recurring lifecycle costs.  So,
while there's no "magic" here, the absence of a STANDARD often makes
it impossible to adopt COTS solutions - which are important for all
sorts of other business reasons.

>> Yes and no. I agree that people who use ancient software suffer
>> from the cost of maintaining that software. The question is how
>> much standards actually help with that. When you are talking twenty
>> years plus, it seems that a lot of standards disappear before the
>> software gets a chance to get as old as that, meaning that, by the
>> end of that period, it seems irrelevant whether the software was
>> built on what once was a standard.

As usual, it depends on the domain, the experience of the
developers/architects, and the standard(s).  For example, there's a
lot of 10-20 year old software written using standards like
C/C++/UNIX/TCP-IP that still works quite nicely and can be evolved
readily over time since these are still "active" technologies, despite
their age, e.g., people still learn this stuff in schools and training
courses.  In contrast, 10-20 year old software written using stuff
like Jovial, Hal-S, CMS-2, and proprietary
languages/executives/protocols, etc. is usually in a world of hurt
since NO ONE learns this stuff anymore in schools and training
courses.  

>> More relevant seems to be whether, at the time I need maintenance
>> for my software, whether there is still an active and interested
>> community around the technology. 

Agreed.

>> If so, I'll get my maintenance done; if not, I'll have a hard
>> time. So, the more relevant criterion seems to be whether the
>> technology is "alive" as opposed to whether it is standardized.

Right, I agree with this, as well.  Ada's a good example of a
"standard" that isn't really "alive" much anymore (outside of a few
domains).

>> See above. The complexity of the application domain doesn't
>> disappear by magic.

Agreed - but standards-based COTS middleware can DEFINITELY help
considerably, particularly for certain classes of systems.

>> So, the complexity of the application I want to build is not
>> reduced by the standard I think.

Well, I think differently on this, but I suspect perhaps we have
different perspectives since we work in different domains.

>> The standard does make it more likely though I might find people
>> with experience in that space, or that I might find tools to help
>> me out somehow. So, yes, to that extent, complexity is reduced. But
>> that isn't reducing the complexity of the application itself, is
>> it?

Yes, as described above ;-)

>> I'm a little bit skeptical. 

If you're interested, please send me email and I can send you some
names of folks to contact for me info.

>> Not that I doubt that these companies haven't done the studies or
>> shown that they saved money -- I'm sure that they have. On the
>> other hand, we've been pushing standardization for so long that we
>> sometimes accept it as a mantra without looking as closely as we
>> should. For example, I have also seen studies that showed the
>> tremendous cost savings and quality improvements that companies
>> experienced when they switched from UNIX to Windows, or from
>> sendmail to Exchange. I'm sure you'd have no problem finding lots
>> of people who'd laugh at that :-)

Sure - you and I both know about "lies, damn lies, and statistics"!
However, the people who are collecting these metrics aren't trying to
"sell" a product (unlike the stuides you mention above, most of which
are published by a vendor to help their marketing) - they are
collecting these metrics internally to validate whether they are
obtaining improvements in their lifecycle costs and cycle-time
productivity.  But I agree with you that all studies and metrics (or
claims based on the lack therein ;-)) should be carefully scrutinized.

>> Hmmm... Yes. Clearly, things like a standardized fitting for light
>> bulbs makes everyone's life easier. The more wide-spread the
>> standard, the more useful it is, as a rule. And the better the
>> standard works, the more useful too. I guess that's where I'm
>> having problems with CORBA. It's a standard, no doubt, but it isn't
>> as good a standard as it should be, not by a long shot.

You'll get no disagreement from me that the CORBA standard shouldn't
be better!  But again, if you check out other de facto and de jure
standards, such as UNIX, C/C++/C#, Perl, TCP-IP, Windows, X-Windows,
MFC, SOAP, COM, they all have deficiencies - in many cases much worse
that CORBA does!  And yet they have all thrived in comparison to much
"cleaner" solutions.

>> We know how to do this sort of thing better now, just as we did
>> when we started CORBA, and DCE started to fade (and DCE was a
>> standard too).

Sure, but DCE was the "dying gasp" of the C-based way of developing
complex systems (X-windows faced a similar fate), so I don't think
it's really comparable with CORBA in this regard.  Plus, CORBA's lived
MUCH longer than DCE ever did!

>> I think that lack of a good standard definitely hurts the
>> market. I'm not so sure about lack of poor one though :-)

Well, again, we're just going to have to agreed to disagree on the
core issues here.  I guess my perspective on this is closer to the
pre-2002 Michi than this year's model... ;-)

        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.schmidt@vanderbilt.edu
0
7/28/2003 5:40:56 PM
Hi Matthew,

>> This is grossly unfair & untrue. You make it seem like Michi is
>> posting hundreds of articles on Ice in this newsgroup, when the
>> reality is that Michi *still* provides helpful advice to everyone
>> on CORBA to this very day!

Agreed - and I compliment him on this.  He's done a great job
explaining the intricacies of CORBA for many, many years.  I'm
impressed that he still continues to contribute to the group.  It says
a lot about him as a person and as a technologist.

>> Before this thread Michi posted one article on Ice in this newsgroup
>> announcing it as a possible alternative to CORBA. How is that pimping
>> Ice? I could more fairly accuse you of pimping ACE + TAO on this
>> newsgroup. A casual google search (author:schmidt ACE
>> group:comp.object.corba) shows 710 articles. A google search for Michi
>> (author:michi group:comp.object.corba) shows 3,840 - of which
>> precisely 2 mentioned Ice.

You're missing my point Matthew.  I've never told vendors "not to post
stuff about their CORBA products on comp.object.corba" (though I try
to refrain from doing this unless it's in response to a discussion
like this).  Michi did this REPEATEDLY - berating vendors for not
focusing exclusively on technical issues in their posts.  I just find
it sad that now that he's changed his "allegiance" all of a sudden,
i.e., it's now ok with him for vendors to post non-technical
marketing-related stuff to comp.object.corba, whereas he never would
have countenanced this in the past.

>> I don't have a problem with anyone questioning our technical claims
>> -- in fact, I welcome it. I strongly believe in the value of our
>> technology and use it in implementing a production system every day
>> (I eat my own dogfood). But I do have a severe problem with
>> attacking anyone personally.

You'll find that when the postings are technical and not FUD-filled,
my responses are technical too.  Ironically, I think this was Michi's
original goal when he was the "anti-hype/marketing policeman" of
comp.object.corba.  The Ice team seems to want to have it both ways,
however, i.e., you want to be able to "bash" CORBA with FUD when it
suits your purposes, yet then draw back and claim the "high road" when
that suits your purposes.  If you stop doing that, you'll find Steve
and I will stop calling you on it - it's that simple!

Take care,

        Doug
-- 
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.schmidt@vanderbilt.edu
0
7/28/2003 5:51:51 PM
Douglas C. Schmidt wrote:
> You're missing my point Matthew.  I've never told vendors "not to post
> stuff about their CORBA products on comp.object.corba" (though I try
> to refrain from doing this unless it's in response to a discussion
> like this).  Michi did this REPEATEDLY - berating vendors for not
> focusing exclusively on technical issues in their posts.  I just find
> it sad that now that he's changed his "allegiance" all of a sudden,
> i.e., it's now ok with him for vendors to post non-technical
> marketing-related stuff to comp.object.corba, whereas he never would
> have countenanced this in the past.

I cannot recall each and every posting that Michi made to this 
newsgroup. However, if my memory serves me right, Michi only criticized 
postings that were pure marketing, by people who never contributed 
anything technical or otherwise helpful to this newsgroup. I don't think 
Michi ever complained about somebody announcing a new 
TAO/MICO/OmniORB/etc. release, or somebody announcing a paper about 
middleware.

So, since I'm sure that you don't want to spread FUD, how about a few 
references, Doug? Show me where Michi criticized others that contributed 
to this forum for posting information about new releases, new papers, 
etc. Since he did this "repeatedly", I'm sure it must be easy for you to 
find several posts in Google that you can quote here?

> 
>>>I don't have a problem with anyone questioning our technical claims
>>>-- in fact, I welcome it. I strongly believe in the value of our
>>>technology and use it in implementing a production system every day
>>>(I eat my own dogfood). But I do have a severe problem with
>>>attacking anyone personally.
> 
> 
> You'll find that when the postings are technical and not FUD-filled,
> my responses are technical too.  Ironically, I think this was Michi's
> original goal when he was the "anti-hype/marketing policeman" of
> comp.object.corba.  The Ice team seems to want to have it both ways,
> however, i.e., you want to be able to "bash" CORBA with FUD when it
> suits your purposes, yet then draw back and claim the "high road" when
> that suits your purposes.  If you stop doing that, you'll find Steve
> and I will stop calling you on it - it's that simple!

We definitely will not stop voicing our opinion just because you decide 
that it's FUD - it's that simple.

-- Marc

0
marc4371 (25)
7/28/2003 6:16:38 PM
Hi Marc,

>> I cannot recall each and every posting that Michi made to this
>> newsgroup. However, if my memory serves me right, Michi only
>> criticized postings that were pure marketing, by people who never
>> contributed anything technical or otherwise helpful to this
>> newsgroup. I don't think Michi ever complained about somebody
>> announcing a new TAO/MICO/OmniORB/etc. release, or somebody
>> announcing a paper about middleware.
>>
>> So, since I'm sure that you don't want to spread FUD,

Nope - I leave that to others - I just comment on it.

>> how about a few references, Doug?

Sure Marc, here's one for starters.  I got it from:

http://groups.google.com/groups?q=Spence+%2B+Henning&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=Pine.HPX.4.05.10002170803060.3886-100000%40bobo.ooc.com.au&rnum=3

It's particularly amusing since Michi's first paragraph (the one
starting with "Right".) is pretty much what you folks have been doing
the past week, i.e., "extolling all the virtues of [Ice], and why it
is better than everything else under the sun, and tell everybody that
it is the best thing since sliced bread".  I think that's the most
concise plot summary of our recent comp.object.corba soap opera I've
read!!!

----------------------------------------
On Wed, 16 Feb 2000 spence_m@ociweb.com wrote:

> Hi Dimitry this is a "shameless plug" but rather than sending you off
> to research a thousand options with multiple URLs, I can tell you we
> meet your requirements very closely.
> 
> We provide commercial support for the open source CORBA 2.2 (with
> some .3) ORB called TAO. We sell CDs of TAO precompiled for various
> platforms including Microsft NT and Visual C++ version 5 and 6.

[...]

Right. Shall I now follow up with a long article extolling all the
virtues of ORBacus, and why it is better than everything else under
the sun, and tell everybody that it is the best thing since sliced
bread?

Shall we then have similar follow-up postings from BEA, IONA, Inprise,
MICO, OIS, and a whole pile of others?

Would that improve what this newsgroup is supposed to be for? Would that
endear us to our audience?

Come on -- let's lay off this nonsense. Everyone here knows that we are
ORB vendors, and everyone knows what the advice from someone with a
vested interest in their product is worth...

Spence, if you really feal the urge to tell someone about your product
in more detail, I suggest you do it by e-mail, not by posting to this
group.

       Cheers,

        Michi.
--
Michi Henning               +61 7 3891 5744
Object Oriented Concepts    +61 4 1118 2700 (mobile)
Suite 4, 904 Stanley St     +61 7 3891 5009 (fax)
East Brisbane 4169          michi@ooc.com.au
AUSTRALIA                   http://www.ooc.com.au/staff/michi-henning.html
----------------------------------------

>> We definitely will not stop voicing our opinion just because you
>> decide that it's FUD - it's that simple.

Ok, have it your way!  But you'll find that a well-reasoned technical
discussion will be a more effective way to promote your technology.
Besides, as Michi said himself:

>> Come on -- let's lay off this nonsense. Everyone here knows that we
>> are ORB vendors, and everyone knows what the advice from someone
>> with a vested interest in their product is worth...

This reminds me of that old maxim about "keep your words nice since
you may need to eat them some day" ;-)

        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.schmidt@vanderbilt.edu
0
7/28/2003 7:10:40 PM
Douglas C. Schmidt wrote:
 > Hi Marc,
 >
 >
 >>>I cannot recall each and every posting that Michi made to this
 >>>newsgroup. However, if my memory serves me right, Michi only
 >>>criticized postings that were pure marketing, by people who never
 >>>contributed anything technical or otherwise helpful to this
 >>>newsgroup. I don't think Michi ever complained about somebody
 >>>announcing a new TAO/MICO/OmniORB/etc. release, or somebody
 >>>announcing a paper about middleware.
 >>>
 >>>So, since I'm sure that you don't want to spread FUD,
 >
 >
 > Nope - I leave that to others - I just comment on it.
 >
 >
 >>>how about a few references, Doug?
 >
 >
 > Sure Marc, here's one for starters.  I got it from:
 >
 > 
http://groups.google.com/groups?q=Spence+%2B+Henning&hl=en&lr=&ie=UTF-8&oe=UTF-8&selm=Pine.HPX.4.05.10002170803060.3886-100000%40bobo.ooc.com.au&rnum=3

That's funny - I was expecting you to respond with *exactly* with this link.

This pretty much confirms what I was saying: You are comparing Malcom 
S., who did nothing other for this newsgroup than responding with plugs 
for TAO to each question about what ORB to use, with Michi who wrote 
countless of postings about technical issues and helped other CORBA users.

Just compare the two posts: One is an annoucement about new 
documentation being available (just like the many posts with the links 
to your TAO/ACE papers), while the other one is simply TAO marketing.

Besides, you spoke of many such posts. Where are all the others? May we 
see more?

 >
 > It's particularly amusing since Michi's first paragraph (the one
 > starting with "Right".) is pretty much what you folks have been doing
 > the past week, i.e., "extolling all the virtues of [Ice], and why it
 > is better than everything else under the sun, and tell everybody that
 > it is the best thing since sliced bread".  I think that's the most
 > concise plot summary of our recent comp.object.corba soap opera I've
 > read!!!

I read this thread differently: You try to unfairly attack us because we 
have an opinion that differs from yours.

I agree on the soap opera, and I would like to end this rather sooner 
than later.

 >
 >>>We definitely will not stop voicing our opinion just because you
 >>>decide that it's FUD - it's that simple.
 >
 >
 > Ok, have it your way!  But you'll find that a well-reasoned technical
 > discussion will be a more effective way to promote your technology.
 > Besides, as Michi said himself:

Doug, it's you who resorts to personal attacks, not Michi or me! And you 
completely turn around what I said above: To us, our opinions are formed 
because of technological reasons, and you can call it FUD all you want, 
that won't make us stop posting our opinions.

-- Marc

0
marc4371 (25)
7/28/2003 7:52:15 PM
Hi Marc,

>> This pretty much confirms what I was saying: You are comparing
>> Malcom S., who did nothing other for this newsgroup than responding
>> with plugs for TAO to each question about what ORB to use, with
>> Michi who wrote countless of postings about technical issues and
>> helped other CORBA users.

Michi's certainly done a lot of great things, but it doesn't change
the irony of the fact that everything Michi said in his response
applies to what you folks have been doing the past week.  Go back and
read Michi's posting carefully and you'll see that there was wisdom in
his words, which seems to have been lost on you folks recently.

>> Just compare the two posts: One is an annoucement about new
>> documentation being available (just like the many posts with the
>> links to your TAO/ACE papers), while the other one is simply TAO
>> marketing.

You seem to have a knack for missing the points of my postings Marc.
But here is a summary of my points (again):

1. I don't think anyone (at least not me) has a problem with your
   posting Ice documentation to the newsgroup.  That's purely 
   informational and of interest to many people.

2. The problem is with all the follow ups, in which you folks are
   "extolling all the virtues of Ice, and why it is better than
    everything else under the sun, and telling everybody that it is the
    best thing since sliced bread?" (or at least since CORBA).

3. Even #2 isn't too bad (though it does pretty flagrantly violate
   "Michi's Rule"), as long as you can back up your claims.  However,
   in many cases, you're simply making baseless claims, e.g., Ice
   performance being inherently better than CORBA performance - which
   is a groundless claim as far as I can tell since the benchmark's
   we've seen thus far from Gautam show that both ORBexpress and TAO
   are faster than Ice!  

4. Moreover, to quote Steve V. "you're also exaggerating CORBA's
   problems to the point of being misleading, just to make Ice appear
   better."  In other words, this thread has long since ceased to be
   an "Ice documentation posting" message and become an Ice
   infomercial!!! 

>> Besides, you spoke of many such posts. Where are all the others?
>> May we see more?

Michi posted this stuff whenever he felt ORB vendors got out of line.
I don't have the time to chase it all down (I just remembered when he
said it to Malcolm, which is how I found the article so quickly), but
you're welcome to check out the archives for yourself.  Regardless of
how many times he made this point, however, and irrespective of how
much you've "contributed" to CORBA in the past - that doesn't give you
a free pass to make groundless and exaggerated claims without being
taken to task for it!  When I make a claim about CORBA or MDA I try as
much as possible to provide documentation for it.

>> I read this thread differently: You try to unfairly attack us
>> because we have an opinion that differs from yours.

Well, you're welcome to your view, but a careful reading of my
responses will show that I don't "unfairly attack" your technical
opinions (i.e., ones backed up with reasoned evidence), just your FUD.
For the record, Michi's recent postings have been quite technical and
well reasoned - and aside from kidding him about a few things (which
are well marked with ';-)') I've replied in kind.

>> I agree on the soap opera, and I would like to end this rather
>> sooner than later.

That's fine with me.

>> Doug, it's you who resorts to personal attacks, not Michi or me! 

Hum, how about the following posting from Michi in which he says:

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

Hum, let's see now, he just insulted Steve Vinoski, Doug Lea, and Mark
Linton, who were three of the best C++ programmers in their day!
Yowza!

>> And you completely turn around what I said above: To us, our
>> opinions are formed because of technological reasons, and you can
>> call it FUD all you want, that won't make us stop posting our
>> opinions.

Like I said before Marc, have it your way - you can stop this any time
you'd like.

Take care,

        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.schmidt@vanderbilt.edu
0
7/28/2003 8:29:43 PM
"Douglas C. Schmidt" <schmidt@tango.doc.wustl.edu> wrote in message
news:bg358d$5so@tango.doc.wustl.edu...
>
> >> Ice isn't burdened by a standards process and historical mistakes,
> >> which makes it comparatively easy to excel technically because we
> >> are free to apply the lessons of the past.
>
> Again, as Steve and I and others have pointed out, it's pretty easy to
> improve stuff technically if you're not constrained by key forces that
> are necessarily for technology to remain viable over the long-term.
> Microsoft has used this as a rationale to modify their distributed
> computing technologies every 2-3 years for more than a decade.  I can
> remember you criticizing this strategy MANY times during various
> discussions over the years, yet now you embrace it - how ironic!

Doug, that's preposterous!

It is correct that I have criticised MS for many times for having a new
distributed computing thing every 2-3 years. It is not true that I
embrace or approve of that. (Who is spreading FUD now?)

Ice hasn't changed into something completely unrelated once every
two or three years -- it's only been released a few months ago. If we
indeed go and throw away Ice after two or three years and replace
it with something else, and then keep doing that a few more times,
you can accuse me of doing what MS did, not before.

> Actually, I don't have any negative reactions to *Ice* - I think it
> sounds cool.  My negative reactions are to the way that you and Marc
> are spewing FUD and making a number of unsubstantiated claims (e.g.,
> about Ice's performance), which is really unbecoming of both of you
> and shouldn't be necessary in order to promote Ice.

What exactly have we claimed that is unsubstantiated? I honestly
don't recall anything we said that wouldn't be true with respect
to Ice's performance.

> In your case Michi, I'm also disappointed in the way that you've
> "changed your stripes" and gone from being a person who harshly
> criticized CORBA vendors in the past for using comp.object.corba as an
> advertising venue to turning this forum into an "Ice promo."  While
> it's certainly your right and privilege to do this, it just strikes me
> as being rather hypocritical.  I have no such complains about Marc -
> he never beat up people for doing this in the first place, so he's not
> being inconsistent.

I posted a short notice about the Ice doc, may God forgive me.
Thereafter, I uttered a number of criticisms on CORBA. We could
have discussed the criticisms but, somehow ended up discussing Ice
and my character. I certainly didn't ask for things to go in that direction!
By all means -- as I said before, I'm keen on technical discussions.

Cheers,

Michi.

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

0
michi9457 (29)
7/28/2003 9:24:12 PM
Marc Laukien <marc@zeroc.com> wrote in message news:<oNadnc-uuNIU9biiRTvUpQ@speakeasy.net>...
> Douglas C. Schmidt wrote:
> > You're missing my point Matthew.  
[snip]
> So, since I'm sure that you don't want to spread FUD, how about a few 
> references, Doug? 
[snip]
> > You'll find that when the postings are technical and not FUD-filled,
> > my responses are technical too.  Ironically, I think this was Michi's
> > original goal when he was the "anti-hype/marketing policeman" of
> > comp.object.corba.  The Ice team seems to want to have it both ways,
> > however, i.e., you want to be able to "bash" CORBA with FUD when it
> > suits your purposes, yet then draw back and claim the "high road" when
> > that suits your purposes.  If you stop doing that, you'll find Steve
> > and I will stop calling you on it - it's that simple!
> 
> We definitely will not stop voicing our opinion just because you decide 
> that it's FUD - it's that simple.
> -- Marc

Guys, please stop before someone invokes Godwin's Law. This
mud-slinging is horrible and on-lookers such as myself are aghast. The
thread was originally to announce some updated ICE documentation,
that's all. Now it's turned into an ICE-versus-CORBA slanging match. I
appeal to both sides to quietly withdraw so we can get on with our
coding. Thank you.

-Andrew Marlow
0
apm35 (156)
7/28/2003 9:58:29 PM
>> For what it's worth, I apologize for the long-running and sometimes
>> too heated discussion.

Ditto!

        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.schmidt@vanderbilt.edu
0
7/29/2003 12:11:25 AM
Do I really want to wade into this?  All the alligators in the water have
brains much larger than I do, it's probably a bad idea.

With that said...

On 7/27/03 5:29 PM, in article
6c2690b5.0307271629.3ec731ac@posting.google.com, "Steve Vinoski"
<vinoski@ieee.org> wrote:

....
> One of the things I find amusing about this thread is the implication
> that somehow CORBA lives and dies by its C++ mapping. Technical people
> often make the mistake of thinking that technical details actually
> matter! CORBA did not succeed because it was the best technical thing
> going. Rather, it succeeded due to superior marketing and superior
> mindshare, both on the part of the OMG and the many vendors that
> support CORBA. If the C++ mapping is as bad as Michi's exaggerations
> have claimed it to be, then why didn't CORBA die in 1995 or 1996?

That CORBA succeeded due to superior marketing depends on your definition of
"marketing."  The positioning of CORBA was tightly focused on the technical
problem it solved, and not on the business problem.  As such, people
gravitated toward it because it was the best way to build or integration
applications on a variety of platforms, in a variety of languages.  And, in
the early-mid 90's -- hell up until 1999 when J2EE picked up steam, CORBA
products were common, and they were inexpensive.

The greater application server business, for which CORBA was a fairly
natural foundation, was a boat that CORBA and the OMG's marketing
*completely* missed.  Sun and BEA succeeded in convincing people that the
way to build middleware solutions was to base them all on J2EE.  And that
market is at least an order of magnitude greater than CORBA for large scale
integration solutions.  So that leaves CORBA back in its core competency
area, namely integrating some applications, where the core requirements are
integration (namely legacy code), where C++ is certainly involved, and where
other languages may be involved.

But when people look at the business problem they have, they're forced have
7 epiphanies before they even know CORBA is a solution to the problem, when
in fact it may be the BEST solution to the problem.  And that, in my
opinion, represents failed marketing.

And I should say, for CORBA's core competency, namely integration of
multiple languages on a variety of platforms, is also one at which Ice is
quite good.  It's simpler, and for people who aren't designing a product to
be compliant to a "standard," or who want to get up and running with AMI,
persistence, etc. quickly, it's quite likely the better solution.  It takes
a subset of what CORBA "tries" to be, and it focuses on doing it as
efficiently, as quickly, and as simply as possible.  A point product focused
on a few key tasks is nearly always going to be better at those tasks than a
product (or specification) designed by committee to solve LOTS of tasks
(many which have plain out been trumped by J2EE).

> In other words, it's a business thing, not a technical thing. That's why
> no C++ mapping has succeeded the existing one -- one hasn't had to!
> Much as we might like to think differently, in the whole scheme of
> things we developers and our technical perspective have actually had
> very little to do with CORBA's success.

Yes.  CORBA's marketing is a technical thing, not a business thing.  Wait,
that's backwards ;-)

-B

0
b_lloyd (1)
7/29/2003 4:46:54 AM
Howdy,

>> As many readers might guess, Doug, Michi, and I have known each
>> other for many years. We've thus been communicating about these
>> issues privately through email. We're also old enough to know how
>> the faceless medium of email and news can easily result in
>> pointless flame wars. (Well, Doug and Michi are old, I'm just
>> experienced :-). ) None of us wants a flame war. For the record,
>> therefore, the three of us are all still friends, we still hold
>> each other in high regard, and we're now focusing this thread back
>> to pure technical talk.

But we can't wait to debate the issue in person at JAOO.  As Michi
pointed out, it'll be two against one, which makes it a fair fight ;-)

>> But I have to admit that it was fun to spice up the newsgroups for
>> a little while! :-)

Clearly, not enough people spend time watching TV political talk
shows, e.g., the McLaughlin Group or Crossfire, since our flame war
was tame compared to these sorts of affairs ;-) ;-)

        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.schmidt@vanderbilt.edu
0
7/31/2003 12:00:09 PM
vinoski@ieee.org (Steve Vinoski) wrote in message news:<6c2690b5.0307302009.4442089e@posting.google.com>...
> schmidt@tango.doc.wustl.edu (Douglas C. Schmidt) wrote in message news:<bg4e3d$dom@tango.doc.wustl.edu>...
> >>Michi wrote:
> > >> For what it's worth, I apologize for the long-running and sometimes
> > >> too heated discussion.
> > 
> > Ditto!
> 
> Me three!
> 
> As many readers might guess, Doug, Michi, and I have known each other
> for many years. We've thus been communicating about these issues
> privately through email. We're also old enough to know how the
> faceless medium of email and news can easily result in pointless flame
> wars. (Well, Doug and Michi are old, I'm just experienced :-). ) None
> of us wants a flame war. For the record, therefore, the three of us
> are all still friends, we still hold each other in high regard, and
> we're now focusing this thread back to pure technical talk.
> 
> But I have to admit that it was fun to spice up the newsgroups for a
> little while! :-)
> 
> --steve

As an average user this is good to hear. Please send a picture if
there is a group hug later :-).

Now, what would be even better is if the open source community and
perhaps some commerical vendors took some of the ideas in ICE and ran
with them. (Thank you ZeroC for keeping things open). This would
clearly benefit both ZeroC and the CORBA community at large. If anyone
starts down this road please keep the newsgroup posted.

- Steve
0
7/31/2003 1:30:27 PM
I have followed this thread with great interest. Although sometimes the 
tone of the discussion is rather harsh, very good arguments have 
surfaced which taught me a lot. It seems that for all of you it is 
either CORBA, ICE, perhaps J2EE.

Wouldn't the .NET/SOAP approach (including the Open Source Mono project) 
have much better chances? After all, I think earlier in this thread it 
was agreed that it is usually not the technical quality, or best fit for 
purpose, that determines the end solution.

I work for a large multinational, with an elaborate and heterogeneous IT 
infrastructure, both in hardware, operating systems and application 
software (including CORBA middleware). Interoperability is a key issue. 
There is an extremely strong drive to reduce this heterogeneity. 
Actually, it is the offical strategy and it is actively pursued.

Even though CORBA is an established standard, if you just count the 
number of desktop PCs around in the company, you will understand that 
CORBA will have a rough time to survive in such a hostile environment, 
and that chances for newcomers are even smaller, although they may be 
superior in technical quality.

What holds for large companies, may not hold for smaller ones. I can see 
the opportunities for a new product like ICE in smaller, innovating 
environments. And the ICE business model could be very attractive for 
those componies. Despite the platform independence of ICE, I think its 
success in a business environment will depend on the success of Linux in 
those enterprises. After all, why should you care about platform 
independence if you have a homogeneous IT environment?

Regards,
Bertwim van Beest




Steve Vinoski wrote:
> Marc Laukien <marc@zeroc.com> wrote in message news:<JnSdnRalfNHgOLyiU-KYvw@speakeasy.net>...
> 
>>FUD seems to be your favorite word lately. Whenever there is an opinion 
>>you don't like, it's FUD to you.
> 
> 
> I disagree, Marc. Doug's use of the acronym "FUD" is perfect for the
> unfounded references you and Michi have made regarding the poor
> technical quality and fading market strength of CORBA. Does CORBA have
> technical problems? Sure! Name me a standard that doesn't! As for the
> CORBA market, I've heard various "industry pundits" say it's weak,
> it's strong, or it's dead -- take your pick. If you guys were still
> selling CORBA, you'd both be posting about how great it is and
> defending it, as my "quotes" posting proved. The fact that you guys
> can't seem to admit that is amusing at best, misleading at worst, and
> perhaps even delusional.
> 
> 
>>I read all the stuff about the history, but this doesn't change the fact 
>>that there is still only an arcane C++ mapping for CORBA. You can argue 
>>about history all you want, fact is that no attempt to start a new C++ 
>>mapping to date ever succeeded.
> 
> 
> You just have to love developer hubris.
> 
> One of the things I find amusing about this thread is the implication
> that somehow CORBA lives and dies by its C++ mapping. Technical people
> often make the mistake of thinking that technical details actually
> matter! CORBA did not succeed because it was the best technical thing
> going. Rather, it succeeded due to superior marketing and superior
> mindshare, both on the part of the OMG and the many vendors that
> support CORBA. If the C++ mapping is as bad as Michi's exaggerations
> have claimed it to be, then why didn't CORBA die in 1995 or 1996? In
> other words, it's a business thing, not a technical thing. That's why
> no C++ mapping has succeeded the existing one -- one hasn't had to!
> Much as we might like to think differently, in the whole scheme of
> things we developers and our technical perspective have actually had
> very little to do with CORBA's success.
> 
> Another way to put it is that the C++ mapping could have been 10 times
> worse and it wouldn't have mattered. It could have been 10 times
> better, and that wouldn't have mattered either. Get over it. From a
> business perspective -- and business totally governs how, why, and
> when technologies live and die -- your claims about having developed a
> superior C++ mapping for Ice don't matter at all. Not at all.
> 
> --steve

0
bwvb (7)
8/12/2003 12:18:08 AM
On Tue, 12 Aug 2003, B.W.H. van Beest wrote:

> I have followed this thread with great interest. Although sometimes the
> tone of the discussion is rather harsh, very good arguments have
> surfaced which taught me a lot. It seems that for all of you it is
> either CORBA, ICE, perhaps J2EE.

Gee, this *is* a long-lived thread, isn't it? :-)

> Wouldn't the .NET/SOAP approach (including the Open Source Mono project)
> have much better chances? After all, I think earlier in this thread it
> was agreed that it is usually not the technical quality, or best fit for
> purpose, that determines the end solution.

I agree. IMO, technical merit is a necessary, but insufficient
prerequisite for success. (Long-term success, that is; for short-term
success, technical excellence is, appalingly, not a prerequisite at all...)
Things other than technical excellence, such as fashions, standards
compliance, market trends, cost, and vendor-base all have an influence as well.

As far as .NET/SOAP is concerned, I wouldn't mix the two. .NET is a lot
more than a protocol. As far as I can see, .NET and SOAP are related
only in so far that you can get .NET objects to talk to each other via
SOAP but, otherwise, they are pretty much unrelated. (After all, .NET is
a programming environment and a run-time platform as well.)

SOAP may make inroads to some extent, but I cannot see SOAP being used
in anything that requires high performance or that is constrained in
bandwidth. SOAP throws bandwidth away like it grew on trees: bandwith
increases of a factor of 100 or more over a binary protocol are not uncommon
with SOAP. And despite the fact that bandwidth is cheap, it's still not
so cheap that I'd be happy to 100 times as much for it as I do now...

The CPU cycles that are spent creating and parsing XML are
horrendous too: it takes easily 100 times the number of CPU cycles to
parse and unpack an XML message than it does to unpack a binary message.
These two factors will ensure that SOAP will not find its way into
performance- or bandwidth-critical applications.

..NET only runs on Windows and so is not a choice for heterogeneous
environments. I wish the Mono folks good luck -- it's a worthwhile thing
to make .NET available in some form of open source. But I am not sure
how successful Mono will be. For one, even if Mono allows interoperability
with genuine .NET objects, .NET is a lot more than just that interoperability.
Just think of the large number of APIs that go with it, the CLR, and all the
tools. I doubt that Mono will get you to the point where you could take
a Windows .NET application and just recompile it under Linux. Further,
there appear to be legal obstacles. As far as I know, at least parts of
..NET are protected by patents and, from I have heard, it is not clear
whether Mono might not encounter serious legal obstacles in the future.

> I work for a large multinational, with an elaborate and heterogeneous IT
> infrastructure, both in hardware, operating systems and application
> software (including CORBA middleware). Interoperability is a key issue.

Right, not surprisingly so.

> There is an extremely strong drive to reduce this heterogeneity.
> Actually, it is the offical strategy and it is actively pursued.

Yes. The holy grail of computing. After more than twenty years in the
industry, I think it unlikely that we will achieve this in the near
future (say, the next 10-15 years). Innovation is moving too fast in this
industry for monocultures to last for any length of time. Usually,
some new technology comes along that has such compelling advantages that
it has to be used for a company to remain commercially viable,
regardless of any internal strategy that seeks to avoid heterogeneity.
As soon as that happens, out the window goes the monoculture and we are
back to a heterogenous system...

> Even though CORBA is an established standard, if you just count the
> number of desktop PCs around in the company, you will understand that
> CORBA will have a rough time to survive in such a hostile environment,
> and that chances for newcomers are even smaller, although they may be
> superior in technical quality.

Agreed, with some reservations. Issues such as performance or standards
compliance can carry a lot of weight, depending on the deployment
environment. For example, a company may be forced to use CORBA simply
because some part of an existing system already uses CORBA. Or the
performance requirements may be such that SOAP is not an option. Or it
may be necessary to support Max OS X, Linux, Windows, and a mainframe.
(I'm sure we can invent more reasons along those lines.) As soon as
requirements along those lines are present, CORBA, or Ice, or J2EE (or
whatever) suddenly become the platform of choice, simply because
requirements dictate it.

In addition, no platform, no matter how sophisticated, can be suitable
for all environments and all scenarios. Ergo, there will always be room
for products that are different from whatever the current flavor of the
month is.

> What holds for large companies, may not hold for smaller ones. I can see
> the opportunities for a new product like ICE in smaller, innovating
> environments.

I agree. If you want to do object-oriented RPC and you don't have a
legacy issue with CORBA, I cannot think of an easier way to get that
than to use Ice. That's what we designed it for. On the other hand, if
you have a legacy issue with CORBA, you will likely be better off sticking
with the devil you know. In general, Ice will appeal to what I'd call
the "technical" middleware market: environments where performance and
footprint are important, as well as easy of use.

> And the ICE business model could be very attractive for
> those componies. Despite the platform independence of ICE, I think its
> success in a business environment will depend on the success of Linux in
> those enterprises. After all, why should you care about platform
> independence if you have a homogeneous IT environment?

Right. For a homogeneous environment, platform independence is
irrelevant. Instead, what usually carries more weight are factors such
as cost, performance, ease of use, etc.

Cheers,

Michi.

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

0
michi9457 (29)
8/12/2003 4:11:39 AM
On 12 Aug 2003, Christopher Browne wrote:

> The marshalling scheme for SOAP is _excruciatingly_ verbose and
> inefficient.
>
> Layer on the "XML Security" standards and you get something that is
> stunningly further inefficient, and you're also likely to totally lose
> any semblance of interoperability.
>
> In the "open source" realm, I'd think that XML-RPC would be the FAR
> more realistic alternative to SOAP.  It's easy to implement, and while
> less functional than SOAP, there are actually a lot of FULL
> implementations of it.  It's obviously less functional than CORBA or
> Ice, but feasibility is worth a lot.  I'd much rather _truly_ support
> XML-RPC than pray that I have supported enough of SOAP that message
> _might_ get through...

Interesting comment. What has always surprised me is how much of the
computing community has blindly embraced the idea of using XML as an
on-the-wire format for RPC, despite the very obvious inefficiencies. A
few years ago, before SOAP ever crossed my event horizon, I would have
laughed at the suggestion of doing this. (Just goes to show how smart I
really am... :-)

To this day, I fail to see the point of this approach. The few
advantages it offers, in my opinion, are far outweighed by its
inefficiencies.

Cheers,

Michi.

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

0
michi9457 (29)
8/12/2003 4:16:02 AM
Michi Henning <michi@triodia.com> wrote in message news:<Pine.LNX.4.44.0308121412570.832-100000@diadora.client.uq.net.au>...
> > In the "open source" realm, I'd think that XML-RPC would be the FAR
> > more realistic alternative to SOAP.  It's easy to implement, and 
[snip]
> Interesting comment. What has always surprised me is how much of the
> computing community has blindly embraced the idea of using XML as an
> on-the-wire format for RPC, despite the very obvious inefficiencies.
[snip]
> To this day, I fail to see the point of this approach. The few
> advantages it offers, in my opinion, are far outweighed by its
> inefficiencies.
> 
> Cheers,
> 
> Michi.

Wow, at last someone else who agrees with me that XML should not be
used on-the-wire. Michi and I must be the most unfashionable
developers on the planet!

-Andrew Marlow
0
apm35 (156)
8/12/2003 10:19:42 AM
Hi Michi,

I am not a proponent of SOAP - I'd much rather be programming using CORBA -
but I'd like to give people some new numbers to throw around in their
discussions ;)

"Michi Henning" <michi@triodia.com> wrote in message
news:Pine.LNX.4.44.0308121344460.832-100000@diadora.client.uq.net.au...
> SOAP may make inroads to some extent, but I cannot see SOAP being used
> in anything that requires high performance or that is constrained in
> bandwidth. SOAP throws bandwidth away like it grew on trees: bandwith
> increases of a factor of 100 or more over a binary protocol are not
uncommon
> with SOAP. And despite the fact that bandwidth is cheap, it's still not
> so cheap that I'd be happy to 100 times as much for it as I do now...
>
> The CPU cycles that are spent creating and parsing XML are
> horrendous too: it takes easily 100 times the number of CPU cycles to
> parse and unpack an XML message than it does to unpack a binary message.

The performance ratios you quote (e.g. 100 times slower/bigger) tend to be
highly dependent on the application domain's message layout needs. These
numbers are what you might expect from a "scientific" application that sends
lots of numerical data. For business applications where you might have
large, rich and complex message structures, the ratios can be substantially
lower (although SOAP is still slower). Please see:

http://www2003.org/cdrom/papers/alternate/P872/p872-kohlhoff.html

for some results that came out of my masters research.

> These two factors will ensure that SOAP will not find its way into
> performance- or bandwidth-critical applications.

I still agree with this statement. It's just that the set of applications
for which SOAP may be "good enough" might be larger than we assume.

Cheers,
Chris


0
chris4541 (1)
8/12/2003 11:14:43 PM
In article <3f383247$0$49106$e4fe514c@news.xs4all.nl>, B.W.H. van Beest
<bwvb@xs4all.nl> writes
>I have followed this thread with great interest. Although sometimes the 
>tone of the discussion is rather harsh, very good arguments have 
>surfaced which taught me a lot. It seems that for all of you it is 
>either CORBA, ICE, perhaps J2EE.
>
>Wouldn't the .NET/SOAP approach (including the Open Source Mono project) 
>have much better chances? After all, I think earlier in this thread it 
>was agreed that it is usually not the technical quality, or best fit for 
>purpose, that determines the end solution.
>

<snip>

Bertwim, I don't know if it was your intention, but you have
come up with the suggestion most likely to unite all quarrelling
parties in opposition to it!

SOAP-based Web services may have a lot to recommend them in some
applications (otherwise companies like Cape Clear, Systinet and
The Mind Electric would not be doing such good business). But
their advocates have left raw wounds by their readiness to boost
SOAP by denigrating CORBA (usually quite unfairly).

I think it is fair to say that, where CORBA can do a given job
acceptably, SOAP is quite unlikely to offer any improvement or
added benefit.
-- 
Tom Welsh
0
news892 (8)
8/13/2003 6:26:23 AM
Michi Henning <michi@triodia.com> wrote in message news:<Pine.LNX.4.44.0308121412570.832-100000@diadora.client.uq.net.au>...
> On 12 Aug 2003, Christopher Browne wrote:
> 
> > The marshalling scheme for SOAP is _excruciatingly_ verbose and
> > inefficient.
> >
> > Layer on the "XML Security" standards and you get something that is
> > stunningly further inefficient, and you're also likely to totally lose
> > any semblance of interoperability.
> >
> > In the "open source" realm, I'd think that XML-RPC would be the FAR
> > more realistic alternative to SOAP.  It's easy to implement, and while
> > less functional than SOAP, there are actually a lot of FULL
> > implementations of it.  It's obviously less functional than CORBA or
> > Ice, but feasibility is worth a lot.  I'd much rather _truly_ support
> > XML-RPC than pray that I have supported enough of SOAP that message
> > _might_ get through...
> 
> Interesting comment. What has always surprised me is how much of the
> computing community has blindly embraced the idea of using XML as an
> on-the-wire format for RPC, despite the very obvious inefficiencies. A
> few years ago, before SOAP ever crossed my event horizon, I would have
> laughed at the suggestion of doing this. (Just goes to show how smart I
> really am... :-)
> 
> To this day, I fail to see the point of this approach. The few
> advantages it offers, in my opinion, are far outweighed by its
> inefficiencies.

While I absolutely agree that XML-encodings make RPCs less efficient,
that is not the point of using SOAP for Web Services. 

First, Web Services are about integrating coarse-grained, modular
components, most likely applications that are themselves internally 
distributed. It's not about objects, and as we all know SOAP (and 
WSDL!) is not object-oriented. If components are indeed "modular" 
(anybody remember these old coupling/cohesion metrics? ;-) ) then 
there should not be zillions of high-volume transactions between 
them. The number of SOAP messages per second that we are seeing in 
test scenarios, even with our own SOAP security gateways in the path,
are "good enough" for many useful settings (B2B, EAI).

The whole point is that connecting these things with SOAP appears much
simpler and cheaper than with CORBA. These things have to stand the
test of time, of course, but there are actually technical arguments
why that assumption may be justified.

First, a receiver can unmarshal an XML message with no or only little
knowledge of the data types in that message, which makes it easier to
distribute application across companies - you simply pick that piece
from the message that you need to care about, and never notice changes
in document formats that you are not concerned with. Second, the
available tools simply *are* simpler to use than ORBs, and the
expertise required to set the stuff up is not as demanding as with
CORA. Finally, CORBA was not made to go across domain boundaries (aka
firewalls), and with SOAP at least everybody grasps the security
implications immediately. WS-Security (for SOAP) in my view is a good
and fresh start at something the OMG never managed to get right -
IMHO.

What all that means is that the two technologies (CORBA vs. SOAP) are
not competing but complementary. I personally don't see either as 
superior if you use each tool for what it was made for. 

Cheers, Gerald.
-- 
Dr. Gerald Brose                        mailto:brose@xtradyne.com
Xtradyne Technologies                     http://www.xtradyne.com
Schoenhauser Allee 6-7,                  Phone: +49-30-440 306-27
D-10119 Berlin, Germany                  Fax  : +49-30-440 306-78
0
8/13/2003 8:15:04 AM
"Gerald Brose" <gerald.brose@xtradyne.com> wrote in message
news:d365f6c2.0308130015.34bcfabf@posting.google.com...
> Michi Henning <michi@triodia.com> wrote in message
news:<Pine.LNX.4.44.0308121412570.832-100000@diadora.client.uq.net.au>...
> >
> > To this day, I fail to see the point of this approach. The few
> > advantages it offers, in my opinion, are far outweighed by its
> > inefficiencies.
>
> While I absolutely agree that XML-encodings make RPCs less efficient,
> that is not the point of using SOAP for Web Services.
>
> First, Web Services are about integrating coarse-grained, modular
> components, most likely applications that are themselves internally
> distributed.

OK, I'll buy that. What I don't buy is why SOAP would be better
than a more efficient binary protocol at providing communication
for these applications. If a low-efficiency protocol is good enough
to serve the needs of coarse-grained components, surely, a high-
efficiency protocol must be at least as good?

> It's not about objects, and as we all know SOAP (and
> WSDL!) is not object-oriented. If components are indeed "modular"
> (anybody remember these old coupling/cohesion metrics? ;-) ) then
> there should not be zillions of high-volume transactions between
> them. The number of SOAP messages per second that we are seeing in
> test scenarios, even with our own SOAP security gateways in the path,
> are "good enough" for many useful settings (B2B, EAI).

OK. So the argument is more or less that SOAP is "good enough"
provided that I don't use it for demanding applications that require
high volume. But I still don't see what it is about SOAP that would
make it better than IIOP or the Ice protocol for such a scenario.
And, of course, what am I supposed to do if I am one of those
unfortunates who *do* have high-volume requirements? Build
half my stuff with SOAP because it's good enough and switch
to something else for the high-volume stuff? I might just use the
something else for everything then...

> The whole point is that connecting these things with SOAP appears much
> simpler and cheaper than with CORBA. These things have to stand the
> test of time, of course, but there are actually technical arguments
> why that assumption may be justified.

Hmmm... I am more inclined to buy that argument, at least
conditionally. One of the most important human-machine
interfaces is the API that developers have to use to make things
happen. If that API is simple, or if there are tools that make the
API easy to use, the platform will tend to be perceived as "better",
regardless of the technical merits or demerits of the underlying
platform, architecture, and protocols. On that score, I can imagine
that a good SOAP platform might win over CORBA. On the
other hand, a bad SOAP platform might not. And, of course,
currently, there are as many SOAP platforms as there are vendors
because nothing at the API level is standardized. In other words,
if I choose SOAP, I'm back to the old days of vendor lock-in.
To boot, I get an inefficient protocol and a grab-bag of
half-finished and preliminary pseudo standards that, frankly,
have turned the wheel back by about ten years. (It seems that
the SOAP and web services people are determined to reinvent
every wheel that was put into CORBA at some point and,
moreover, are determined to ignore every lesson we have
learned about similarly-shaped wheels in the past...)
Personally, this doesn't strike me as such an attractive deal.

> First, a receiver can unmarshal an XML message with no or only little
> knowledge of the data types in that message, which makes it easier to
> distribute application across companies - you simply pick that piece
> from the message that you need to care about, and never notice changes
> in document formats that you are not concerned with.

OK, I have to point out a few things here:

First, whether a receiver can unmarshal things without type knowledge
is *not* an artifact of XML. For example, in CORBA, I can unmarshal
things without type knowledge too, provided that I send everything inside
an Any. Of course, that makes things much more expensive (just as XML
does) and I lose all the static type safety. But I can do it.

The fact that you cannot generally unmarshal without type knowledge
in CORBA is due to a design flaw in IIOP and in no way related to
the fact that IIOP is a binary protocol. (The problem is that IIOP
doesn't encapsulate many things that should be encapsulated, that's all.)

In Ice, it is possible for a receiver to unmarshal and remarshal a message
without any type knowledge whatsoever and, moreover, to do it *extremely*
efficiently. (In fact, a receiver can unmarshal and remarshal a message by
simply re-sending what it received as a binary blob. This means that there
is no need to copy *anything*.) In other words, you can have a binary
protocol with this capability just as much as a text-based one: the ability
to unmarshal without type knowledge is completely independent of the
binary vs text argument.

Second, there is the often-touted argument that XML is "self-describing".
That is a complete fallacy (as I have argued in other postings two or three
years ago): there is *nothing* self-describing about XML, other than
syntactic structure. In particular, the argument that XML is better because
the receiver can simply "ignore the bits it doesn't understand" is complete
nonsense: there is no utility to this feature of any kind whatsoever. A partial
message that has arbitrary portions removed from it is useless for all
practical
purposes because the semantics of such a message may be impaired in
unpredictable ways: what I don't know may hurt me as much as what I do
know. (BTW, if XML is "self-describing", then a BER-encoded message
(a common encoding used for ASN.1) is self-describing too: everything
in BER is tagged with its type and the receiver can unmarshal something
without any type knowledge whatsoever. But I have never heard anyone
expousing the argument that BER is "self-describing" whereas, for XML,
that somehow seems to be magically the case...)

I came across a cute quote the other day in someone's signature. I can't
recall the exact wording, but it went something like: "People usually are
scared when they see a naked skeleton walking around. Yet, for some
reason, people aren't scared when they come across naked XML."
While facetious, the analogy has a point, IMO.

> available tools simply *are* simpler to use than ORBs, and the
> expertise required to set the stuff up is not as demanding as with
> CORA.

Right. As I argued previously in this thread, CORBA suffers from
"complexiitis" (sp? ;-)  To me, this is one major reason that SOAP
ever got a foot in the door: it was perceived to be simpler. Personally,
I also think that this is a fallacy -- SOAP and web services are simpler
only for as long as they do only a fraction of the things that CORBA
does. Put all the functionality that's missing into web services, and
they will turn out to be no simpler than CORBA, and they will turn
out to be just as plagued by design-by-committee. (Let's wait another
two or three years before turning on the flame throwers, please --
I'm sticking my neck out here because I'm crystal ball gazing...)

> Finally, CORBA was not made to go across domain boundaries (aka
> firewalls),

Right. That's the other major reason for why SOAP got a foot in the
door. After more than ten years, CORBA *still* does not have a
security solution that is anywhere near practical. Surprise, surprise,
people don't feel like using it over unsecured public networks and
look for something else.

> and with SOAP at least everybody grasps the security
> implications immediately.

That I believe to be another huge fallacy. The security implications
of SOAP are that there is no security, but people somehow refuse to see
that. By tunneling everything over port 80, I end up disabling the
firewall just as effectively as I do by punching a separate whole into
a firewall for every CORBA application behind it. Except that, with SOAP,
I no longer have even an inkling of what it is that is going through
my firewall. With CORBA, and by opening up a separate hole
for each application, I at least know what holes I opened...

As far as architecture is concerned, a number of highly experienced
people have critizised SOAP very severely. In particular, Paul
Prescod has written quite a bit about this (see
http://www.prescod.net/rest/security.html for an example) and Cheswick,
Belluvin, and Rubin in "Firewall and Internet Security" (Addison-Wesley)
have some very uncomplimentary things to say about SOAP too.
The whole approach of tunneling things through HTTP without using
HTTP at the level of abstraction it was designed for has many serious
security implications.

Sure, firewalls can be built to look inside SOAP messages and make
decisions based on their contents. But that is responding to one stupid
design decision with another stupid one: all it leads to is the firewall
vendors creating an even more complex product in order to combat
the bad design decisions made elsewhere. All by itself, that reduces
security because a complex firewall is likely to have more security flaws
than a simple one. But, worse, it leads to an arms race: every time someone
comes up with a stupid idea like SOAP, they subvert the layering architecture
of the protocol stack and so force the firewall vendors to do something
about it, which, in turn, creates a completely new and surprising class of
security exploits. The sad thing is that it is the good guys who are engaged
in this arms race, to the advantage of the bad guys.

> WS-Security (for SOAP) in my view is a good
> and fresh start at something the OMG never managed to get right -
> IMHO.

Hmmm... So, because we have just perverted the networking protocol
hierarchy, we now have to go and invent a hole new security system when,
had we done things right from the start, there would be no need for any
of this. This is ridiculous: security belongs at the low levels of the
hierarchy.
It definitely has no place being bolted on top of something that is at layer 7
(and, courtesy of SOAP, really is now a nine-layer protocol stack). I shudder
to think of security as layer 10... :-(

> What all that means is that the two technologies (CORBA vs. SOAP) are
> not competing but complementary. I personally don't see either as
> superior if you use each tool for what it was made for.

SOAP is off to a bad start. It has architectural problems as well as efficiency
problems. The effort is flawed from its conception and that flaw will never
be made to disappear (just as CORBA still suffers from the flaws in its
protocol).
This does not strike me as the way forward.

Finally, for what it's worth, Ice offers a security solution that is
pragmatic, simple, easy to use and configure, works through
firewalls without perverting them, is as secure as SSL, and works.
You can read about the details in the Ice doc.

Cheers,

Michi.

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

0
michi9457 (29)
8/13/2003 9:43:04 AM
"Christopher Kohlhoff" <chris@kohlhoff.com> wrote in message
news:Dxe_a.31058$bo1.493@news-server.bigpond.net.au...
> Hi Michi,
>
> I am not a proponent of SOAP - I'd much rather be programming using CORBA -
> but I'd like to give people some new numbers to throw around in their
> discussions ;)
>
> [...]
>
> The performance ratios you quote (e.g. 100 times slower/bigger) tend to be
> highly dependent on the application domain's message layout needs.

I agree -- the bandwidth/performance difference can be anything from a little
to something exceeding a factor of 100. The actual number is very sensitive
to the particular data layout. The average case will likely be somewhere in
between,
maybe a factor of 20. But that's not the important number: if I am one of those
poor people who happen to have data that costs a factor of 100, I'm screwed.
It's the worst case that's important, not the average case.

Think of it this way: people almost never say that "on average, this system is
fast
enough." They also almost never say that "this particular part of the system
is blindingly fast". But what I do hear people say a *lot* is: "this particular
gizmo is a pile of crap -- it's unbelievably slow." All the attention always
goes to the slowest part of a system because that is the one that causes
problems and therefore gets noticed.

> These
> numbers are what you might expect from a "scientific" application that sends
> lots of numerical data. For business applications where you might have
> large, rich and complex message structures, the ratios can be substantially
> lower (although SOAP is still slower). Please see:
>
> http://www2003.org/cdrom/papers/alternate/P872/p872-kohlhoff.html
>
> for some results that came out of my masters research.

I disagree with the "scientific" vs "business" distinction because I believe
that it is arbitrary and simply does not apply. There are plenty of scientific
applications that send very complex data sets around, and there are plenty
of business applications that send plenty of non-complex vectors of numbers
around. I agree with your point that "the ratios can be substantially lower".
The emphasis has to be on "can be" though. The same statement cannot
be replaced with "the ratios *are* substantially lower" because that would be
patently false. But, as I said above, it's the worst case that matters, not
the best case or average case.

For a few simple calcuations, see
http://groups.google.com/groups?hl=en&lr=&ie=UTF-8&oe=UTF-8&threadm=Pine.HPX.4.05.10101121730500.2501-100000%40bobo.ooc.com.au&rnum=1&prev=/groups%3Fq%3DSOAP%2Bgroup:comp.object.corba%2Bauthor:Michi%2Bauthor:Henning%26hl%3Den%26lr%3D%26ie%3DUTF-8%26oe%3DUTF-8%26selm%3DPine.HPX.4.05.10101121730500.2501-100000%2540bobo.ooc.com.au%26rnum%3D1

(Or, if some stupid news reader can't handle the long URL, search
for message by me in comp.object.corba with the subject heading
"SOAP, what's the big deal?". The message ID is
<Pine.HPX.4.05.10101121730500.2501-100000@bobo.ooc.com.au>.)

That article shows quite clearly (I think ;-) that the cost of SOAP is
likely to be very high in many application scenarios. And, of course,
bandwidth is only part of the story. The number of CPU cycles that
get blown in an XML parser is truly staggering compared to the cost
of unmarshaling a binary-encoded message.

For an anecdote about the cost of using XML as a marshaling format, we
recently had users complaining about Freeze (the Ice persistence service)
being slower than expected for read operations. Freeze permits you to
switch the encoding between XML and binary by setting an option. In
other words, all parts of an application are identical when I change this
option, except for the encoding. This makes it a nice setup for isolating
the cost of using XML.

What we found was that, with XML encoding, reads from the database
were slower by a factor of 10 (!) than the same reads for the same
data using a binary encoding. That is a staggering performance difference.
It is staggering in particular when you consider that this is *database
access*:
normally, I would expect the cost of doing the physical I/O with the
database to completely dominate the round-trip time for requests.
Yet, using XML, the cost incurred by the parser was sufficiently large to
swamp the cost of the I/O, so the cost of using XML dominates
the overall end-to-end performance. This is, frankly, appalling and
we are going to ditch XML encoding for database I/O for that reason.

(You may blame our parser (Xerces-C in our case) for the bad
performance. And yes, we could probably make things faster buy
finding or building a better parser. But there is *no* way that
XML encoding will ever get anywhere near a binary encoding
in terms of efficiency, no matter how good a parse I use.)

What really irks me is that, when confronted with such findings, many
people say "oh well, it's good enough in many cases" or words to that
effect. I'm blown away by this attitude: if something is good enough
for many cases, by definition, it means that it isn't good enough for
many other cases. What sort of general-purpose platform
is that? Yet, the technology to make it good enough for
just about all cases has been well understood for years and is
readily available.

SOAP and web services are touted as the infrastructure that will
change the way we do commerce, will bring the global economy one
step closer, will become the one true standard of interoperability
on the Internet, etc. They've got to be kidding! Are we really going
to build our future business infrastructure and world economy on
technology that, at best, can aspire to the level of technical
achievement of an IT undergraduate student? I hope not...

> > These two factors will ensure that SOAP will not find its way into
> > performance- or bandwidth-critical applications.
>
> I still agree with this statement. It's just that the set of applications
> for which SOAP may be "good enough" might be larger than we assume.

See what I wrote above. And, no Chris, I don't mean this personally. I
want to point out that "good enough" is rarely good enough in the long
term, especially when the aspirations are "to create the lingua franca
of the Internet." I cannot help say what I said above: it's about
time that some sanity and solid engineering replaced the pipe-dreams
and wishful thinking...

Cheers,

Michi.

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

0
michi9457 (29)
8/13/2003 10:28:22 AM
"Michi Henning" <michi@triodia.com> wrote in message news:<apo_a.32172$bo1.4639@news-server.bigpond.net.au>...
> I agree -- the bandwidth/performance difference can be anything from a little
> to something exceeding a factor of 100. The actual number is very sensitive
> to the particular data layout. The average case will likely be somewhere in
> between,
> maybe a factor of 20. But that's not the important number: if I am one of those
> poor people who happen to have data that costs a factor of 100, I'm screwed.
> It's the worst case that's important, not the average case.

Seriously Michi.  You have started hair-splitting again.  First you
said 100 times slower, then after someone points out you are giving
'exaggeration' a new definition you revert back to 20 times and claim
that is not important since that is the average case.
 
> Think of it this way: people almost never say that "on average, this system is
> fast
> enough." They also almost never say that "this particular part of the system
> is blindingly fast". But what I do hear people say a *lot* is: "this particular
> gizmo is a pile of crap -- it's unbelievably slow." All the attention always
> goes to the slowest part of a system because that is the one that causes
> problems and therefore gets noticed.

I am sorry.  How did you conclude all these things?  I routinely tout
the features of my system by claiming how fast it is in certian areas.
 Didn't you and your colleague do the same thing in another thread
about how the XML encoding was screwing your database reads and how
you are gonna ditch it in favor of much faster binary encoding? 
Problems gets noticed in the slower area because something looked like
a nail to you and you hammered it willy-nilly.
 
> I disagree with the "scientific" vs "business" distinction because I believe
> that it is arbitrary and simply does not apply. There are plenty of scientific
> applications that send very complex data sets around, and there are plenty
> of business applications that send plenty of non-complex vectors of numbers
> around. I agree with your point that "the ratios can be substantially lower".
> The emphasis has to be on "can be" though. The same statement cannot
> be replaced with "the ratios *are* substantially lower" because that would be
> patently false. But, as I said above, it's the worst case that matters, not
> the best case or average case.

there you go.. word games.  "can be", "are".. feels like my high
school English grammar class.
 
> What we found was that, with XML encoding, reads from the database
> were slower by a factor of 10 (!) than the same reads for the same
> data using a binary encoding. That is a staggering performance difference.
> It is staggering in particular when you consider that this is *database
> access*:
> normally, I would expect the cost of doing the physical I/O with the
> database to completely dominate the round-trip time for requests.
> Yet, using XML, the cost incurred by the parser was sufficiently large to
> swamp the cost of the I/O, so the cost of using XML dominates
> the overall end-to-end performance. This is, frankly, appalling and
> we are going to ditch XML encoding for database I/O for that reason.


So what is your point Michi?  Its practically a no-brainer that XML
encoding is going to be orders of magnitude slower than binary
encoding.  To my mind you seem to be throwing a lot of red herrings
around.  You keep pointing out specific use-cases where use of XML is
highly unsuitable and somehow draw the conclusion XML on the wire in
general is a proper waste of time.  Using your logic, from your
extensive list of CORBA's faults, I can pick a feature that according
to you reeks of technical inferiority, build an application around it
and claim that CORBA sucks.  Doesn't applicability matter?  What
happened to the old adage "use the right tool for the job"?

Really Michi, your arguments about tunnelling everything through port
80 atleast make a point.

As your colleague Steve Vinoski wrote (its memorable in my opinion) in
an IEEE article (I can't remember off hand where I read it), "hooking
on performance numbers is like going out to buy a family SUV and
ending up buying a Porsche Turbo.  Its not big enough for the whole
family nor can it carry any cargo but it was simply the fastest
vehicle you could find."

If that doesn't sum up your position, I don't know what does.

--Dilip

P.S: I will try to dig up that article.  It was extensively about how
vendors focus on performance while ignoring other facts that are not
so easily measurable.
0
rdilipk (138)
8/13/2003 2:34:53 PM
"Christopher Kohlhoff" <chris@kohlhoff.com> wrote in message
news:7rr_a.32655$bo1.6730@news-server.bigpond.net.au...
>
> I do agree that this distinction is somewhat artificial, but it arose mainly
> because previous published research in the area was skewed towards (in their
> words) "scientific" applications (e.g. grid computing).

I see. I agree that this is a skewed approach. I've seen scientific
applications
that had horrendously complex data sets. Things like tissue culture analysis,
interferometer spectrum analysis, and similar. Just because something is
scientific and a lot of number crunching is involved doesn't mean that the
data will be simple.

> The intended -
> non-assessing ;) - audience for my research, however, is people considering
> SOAP for developing business systems in a particular domain. Where other
> applications (be they business or scientific) have similar messaging needs,
> my results may be relevant.

Sure, no doubt.

> I think we are agreed that the worst case performance for SOAP is really
> crap. And in applications where you would hit the worst case and it's too
> slow, then of course you'd be using something else, possibly CORBA.

Yes. But doesn't that beg the question? Exactly why should have to switch
to something else? This really seems backward: we start out with a really
bandwidth-hungry protocol for no tangible benefit and then, when the
bandwidth consumption becomes a problem, we have to switch to something
else. It would seem far better to use a protocol that doesn't have those
problems to start with.

> It's funny, because I have seen real world financial markets applications
> that use RPC-style interfaces similar to the SOAP example you included in
> your posting. Unfortunately, their performance tends to be poor, regardless
> of wire format, because the one-size-fits-all application of the RPC model
> is not appropriate to the bulk data transfer requirements. SOAP proponents
> did themselves no favours pushing the RPC model just because it was easier
> to explain.

Hmmm... This is an interesting comment. There are really two opposing forces
at work here: on the one hand, we have the desire to make distributed
computing as transparent as possible. CORBA, Java, .NET, and Ice
do their bit toward that goal. The APIs hide to some degree the fact
that there is a network and a client-server paradigm involved, which
hides all the networking grot from programmers. That's nice. On the
other hand, that has also lead to some people designing their systems
really naively, namely, as if no network existed. That often leads to serious
performance problems because, of course, the performance penalty
associated with RPC cannot be made to go away entirely. So, if I design
my system in ignorance of the reality of networking, I'm likely to suffer the
consequences.

> If you were put in a position where you were forced to use SOAP for a
> similar application, I doubt you would design the interface the same way.

I have a problem at this point. True: I have to design my system to take
the realities of RPC into account. But I would hope that the same system
design would work pretty much equally well regardless of the underlying
distribution platform. That is, the same data sets, when moved over CORBA,
Ice, RMI, DCE, or DCOM should give me the same performance within
a fairly small band (less than an order of magnitude for sure). With SOAP,
that isn't necessarily the case anymore: suddenly, I am sensitive to the data
set layout to a very large degree, to point where the difference may be
two orders of magnitude or more.

This is really irksome: while I'm happy to design my system to the limitations
of RPC, I'm definitely not happy to design it to arbitrarily and unnecessarily
severe limitations. SOAP imposes a limitation that is unacceptably severe, IMO,
especially in light of the fact that we know how to avoid the limitation and
that
I don't get a payback for the limitation somewhere else, as far as I can see.

> I don't know what thought process is driving the industry heavies' pushing
> of SOAP as the solution to the world's integration woes.

Well, as I said elsewhere, SOAP is the result of political and market
maneuvering
much more so than technical considerations.

> Provided I'm not
> being forced to misapply a particular technology, I don't mind very much
> what the heavies are up to. As an application developer my concern is not
> with grand schemes and aspirations for the future of the internet, but with
> providing a solution that suits the customer; and if, in spite of its
> technical deficiencies, SOAP can meet the technical and political
> requirements of a project, then it should at least be under consideration.

I agree with the last bit: *if* SOAP can meet the technical and political
requirements, *then* it should be under consideration. But given the
horrendous waste, I cannot see it meeting the premise all that often,
meaning that the conclusion doesn't apply.

Cheers,

Michi.

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

0
michi9457 (29)
8/14/2003 10:01:39 PM
"Dilip" <rdilipk@lycos.com> wrote in message
news:8bc3089c.0308130634.1a910ed6@posting.google.com...
> "Michi Henning" <michi@triodia.com> wrote in message
news:<apo_a.32172$bo1.4639@news-server.bigpond.net.au>...
> > The actual number is very sensitive
> > to the particular data layout. The average case will likely be somewhere in
> > between,
> > maybe a factor of 20. But that's not the important number: if I am one of
those
> > poor people who happen to have data that costs a factor of 100, I'm
screwed.
> > It's the worst case that's important, not the average case.
>
> Seriously Michi.  You have started hair-splitting again.  First you
> said 100 times slower, then after someone points out you are giving
> 'exaggeration' a new definition you revert back to 20 times and claim
> that is not important since that is the average case.

Hmmm... Let's see. I'm currently paying for a cable modem connection with
my ISP. That connection costs A$ 87.95 per month and comes with a 3GB
bandwidth cap. Every MB over the cap costs A$ 0.139. I manage to just stay
within the 3GB limit most months.

Let's assume that I do all the things I used to do over that link with a binary
protocol and now I switch to SOAP. Also let's assume that things require
only 20 times as much bandwidth instead of 100 times, so we are paying
attention to the average case, not the worst case. That brings the
total per month to 60GB. For that, the cheapest possible plan my ISP offers
is A$ 299.95 per month for the first 10GB, and A$ 0.099 per MB thereafter.
This comes to A$ 5,249.95 per month. That is 60 times (!) the cost of my 3GB
per month plan. Even if we were to assume linear scaling of my basic 3GB plan,
I would still be paying A$ 1,979.00 (instead of A$ 87.95) per month.

It seems that quite a few people (maybe those who don't pay the bill) have
been arguing that SOAP is good enough and that a factor of 20 doesn't matter.
I'm not so sure whether the people who hold the purse strings would agree:
the luxury of a text-based protocol seems to be a rather expensive one.

> > Think of it this way: people almost never say that "on average, this system
is
> > fast
> > enough." They also almost never say that "this particular part of the
system
> > is blindingly fast". But what I do hear people say a *lot* is: "this
particular
> > gizmo is a pile of crap -- it's unbelievably slow." All the attention
always
> > goes to the slowest part of a system because that is the one that causes
> > problems and therefore gets noticed.
>
> I am sorry.  How did you conclude all these things?

Lot's of time spent in the industry. I've never been on a project where
the project had a problem because a part of the system was very fast.
But I have been on plenty of projects where one part of the system
(quite often a small one) was intolerably slow. A disproportionate
amount of time, effort, and money was spent on these projects
on attempts to deal with that performance problem because the project
wouldn't have been viable without rectifying that problem.

> I routinely tout
> the features of my system by claiming how fast it is in certian areas.

Sure, so does most everyone. If we have something that is very fast,
we brag about it. But customers rarely notice it. What they *do* tend
to notice are those bits that are too slow. And they never come to us
with comments along the lines of "you stupid fools, why did you make
part X go so fast? 20 times slower would have been good enough."

>  Didn't you and your colleague do the same thing in another thread
> about how the XML encoding was screwing your database reads and how
> you are gonna ditch it in favor of much faster binary encoding?
> Problems gets noticed in the slower area because something looked like
> a nail to you and you hammered it willy-nilly.

I don't think so. Customers came to us and complained about the poor
read performance. So we had a look and XML turned out to be culprit.
So we remove it in favor of something better.

> > What we found was that, with XML encoding, reads from the database
> > were slower by a factor of 10 (!) than the same reads for the same
> > data using a binary encoding. That is a staggering performance difference.
> > It is staggering in particular when you consider that this is *database
> > access*:
> > normally, I would expect the cost of doing the physical I/O with the
> > database to completely dominate the round-trip time for requests.
> > Yet, using XML, the cost incurred by the parser was sufficiently large to
> > swamp the cost of the I/O, so the cost of using XML dominates
> > the overall end-to-end performance. This is, frankly, appalling and
> > we are going to ditch XML encoding for database I/O for that reason.
>
>
> So what is your point Michi?  Its practically a no-brainer that XML
> encoding is going to be orders of magnitude slower than binary
> encoding.

Right. So why are we using for RPC then?

> To my mind you seem to be throwing a lot of red herrings
> around.  You keep pointing out specific use-cases where use of XML is
> highly unsuitable and somehow draw the conclusion XML on the wire in
> general is a proper waste of time.

Right, it *is* unsuitable on the wire. Surprise, surprise: XML was designed
as a portable document description language. Works fine for that, and offers
all sorts of benefits. So, why not use XML for what it was designed for
and use something that was designed for RPC RPC?

> Using your logic, from your
> extensive list of CORBA's faults, I can pick a feature that according
> to you reeks of technical inferiority, build an application around it
> and claim that CORBA sucks.

> What
> happened to the old adage "use the right tool for the job"?

I wonder about that myself. XML isn't the right tool for RPC, so
why do we insist on using it for RPC?

> As your colleague Steve Vinoski wrote (its memorable in my opinion) in
> an IEEE article (I can't remember off hand where I read it), "hooking
> on performance numbers is like going out to buy a family SUV and
> ending up buying a Porsche Turbo.  Its not big enough for the whole
> family nor can it carry any cargo but it was simply the fastest
> vehicle you could find."
>
> [...]
>
> P.S: I will try to dig up that article.  It was extensively about how
> vendors focus on performance while ignoring other facts that are not
> so easily measurable.

I completely agree with Steve on that point, and Steve and I have had
many discussions around this topic over the years. (I also read the
article you mention.) Performance does not matter to some degree,
and there are many other considerations that have to be taken into
account. In particular, if the cost of using a middleware platform
accounts for only a few percent of the total end-to-end performance,
there is not much to be gained by improving the middleware.
But if the middleware suddenly becomes the dominating
performance limiter, performance does indeed matter very much.

Given otherwise equal capabilities, no-one in their right mind would
choose something that is 20 times slower or more expensive unless
they get some other payback in return that makes up for that loss.
So far, I haven't been able to find anyone who can tell me what it
is that I get for my factor of 20 when I'm using SOAP.

Cheers,

Michi.

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


0
michi9457 (29)
8/14/2003 10:32:03 PM
"Gerald Brose" <gerald.brose@xtradyne.com> wrote in message
news:d365f6c2.0308130436.2d0978b2@posting.google.com...

> (BTW, all this somehow this reminds me of the times when
> object-orientation was considered slow. SOAP (in-)efficiency has
> two main factors: XML parsing performance during marshalling, and
> message size consuming network bandwidth. Both these areas are
> seeing improvements, with XML parsers getting faster, and larger XML
> messages being compressed.  The factor 100 you mentioned in a
> different posting is probably not accurate, so if I have to trade
> efficiency for other goodies, the scale may tip more easily now.

OK, you make two points here:

- A factor of 100 is probably inaccurate.

  As I said previously, that really depends on the situation. I have worked
  on more than one project where complex data sets were exchanged
  in the form of large structures. In such a case, a factor of 100 is entirely
  realistic. Of course, you could argue that, in such a case, I can take
  all the data, marshal it more compactly into a string, and then send
  the string instead. But that really begs the question then of why I'm
  bothering to use the middleware. After all, it's the middleware that
  is supposed to handle such chores for me. As I said elsewhere,
  I don't mind designing my system to the limitations inherent in RPC,
  but I certainly do mind designing my system to completely arbitrary
  and unecessary limitiations, such as using up far more bandwidth
  than is necessary.

- If I have to trade efficiency for other goodies, the scale may tip
  more easily.

  Agreed. My car does has a top speed of well over 200km/h. I
  certainly wouldn't trade it for one with a top speed of only 10km/h.
  But, if I have the problem of getting a 747 plane out of its hangar,
  suddenly, the car with a top speed of 10km/h becomes quite acceptable
  because I can use that to push my plane and, otherwise, the plane
  would be stuck in the hangar.

  So far, I'm still looking for an equivalent reason for using SOAP. (And,
  in case you wondering, no, I *don't*  own a 747 :-)

> General answer: simplicity. I don't know about Ice, but for IIOP
> that is true.

Maybe you saw my ISP cost comparison in a different article --
I completely agree that simplicity is a compelling argument. But
not at *that* high a cost. Ice provides simplicity too, but does it
at less bandwith than IIOP, not ten, or twenty, or a hundred
times more.

> > And, of course, what am I supposed to do if I am one of those
> > unfortunates who *do* have high-volume requirements? Build
> > half my stuff with SOAP because it's good enough and switch
> > to something else for the high-volume stuff? I might just use the
> > something else for everything then...
>
> If you have those high-volume requirements then you'll probably
> try to avoid IPC in the first place, and if you can't, you'll
> try what fares best using some kind of cost/benefit ratio. As
> a clever engineer, you'll always choose the simplest or cheapest
> thing that will do the trick, right?

Right. But that then completely rules out SOAP, doesn't it?

> > currently, there are as many SOAP platforms as there are vendors
> > because nothing at the API level is standardized.
>
> Okay, but surely some are more important than others, and Sun's
> JAX-RPC is a fairly standard API that is also used by, e.g.,
> the Apache toolkits.
>
> > In other words,
> > if I choose SOAP, I'm back to the old days of vendor lock-in.
>
> Not if you believe that JSRs are open standards ;-)

OK, so if I use Java, I get one "fairly standard" API. If I'm using
some other language, tough. I'm afraid that is still not good enough
to make me accept the horrendous blow-out in bandwidth. (And,
of course, standard APIs are in no way related to using XML on
the wire -- I can make standard APIs for any kind of marshaling
format, so standards shouldn't be used to support XML on the
wire, I believe.)

> > (It seems that
> > the SOAP and web services people are determined to reinvent
> > every wheel that was put into CORBA at some point and,
> > moreover, are determined to ignore every lesson we have
> > learned about similarly-shaped wheels in the past...)
>
> Agreed, to some extent. If you look at version 1.2 of WSDL,
> however, you see that some of the lessons have been learned.
> It's starting to look more like IDL.

Oh, good! So, after several years of being told that it's the protocol
that matters (who needs type safety anyway? ;-) we now reinvent
IDL. Fantastic. Yes, for that, I immediately go and accept twenty
times the bandwidth! And the new wheel is so much shinier than
the old one, too! (Sorry, but I couldn't help the sarcasm ;-)

> > First, whether a receiver can unmarshal things without type knowledge
> > is *not* an artifact of XML.  For example, in CORBA, I can unmarshal
> > things without type knowledge too, provided that I send everything inside
> > an Any. Of course, that makes things much more expensive (just as XML
> > does) and I lose all the static type safety. But I can do it.
>
> But that's not how you would normally code with CORBA, it requires extra
> discipline, whereas you always get that advantage with XML.

Agreed -- I wasn't suggesting that everyone should use Anys to transmit
everything. I was making the point mainly to show that being able
to unmarshal without type knowledge is unrelated to whether something
is binary- or text-based.

> (Also, you
> would need to encode every single data value in an any, not just an
> outer envelope. Using the CORBA APIs to do that is way more horrid
> than doing that with XML.)

Agree as well. Using CORBA Anys is complex.

> > Second, there is the often-touted argument that XML is "self-describing".
> > That is a complete fallacy (as I have argued in other postings two or three
> > years ago): there is *nothing* self-describing about XML, other than
> > syntactic structure.
>
> Which is more than IIOP has to offer...

Right. The question is whether it is necessary for RPC though. Ice does
very nicely with a non-tagged wire protocol. In particular, message
forwarding can be achieved without adding tags, and far more efficiently
than with IIOP.

> > In particular, the argument that XML is better because
> > the receiver can simply "ignore the bits it doesn't understand" is complete
> > nonsense: there is no utility to this feature of any kind whatsoever. A
partial
> > message that has arbitrary portions removed from it is useless for all
> > practical
> > purposes because the semantics of such a message may be impaired in
> > unpredictable ways: what I don't know may hurt me as much as what I do
> > know.
>
> No, Michi, you are deliberately ignoring the document-style
> processing which is, IMO, much more important in SOAP than RPCs.
> In a document-based workflow, different parts of a lenghty
> document are relevent to different parties, so the advantages
> I have described actually make a big difference.

Right. But now we are talking documents, not RPC. The structured
document argument is correct, of course. But it belongs at the
application-semantic level: it is the application that needs that
capability, not the transport underneath it. So, why are we putting
the capability into the transport at horrendous cost? To me, this
represents a gross failure to separate semantics and deal with
requirements at the appropriate level of abstraction. That is one
of the reasons why SOAP is architecturally flawed: it concerns
itself with things that don't matter at that level (such as marshaling
format), and it fails to concern itself with things it should be paying
attention to (such as respecting the addressing capabilities of its
transport or doing something about those objects that don't exist
but that the "O" in SOAP originally stood for).

> Think of all those
> committes that build EDI standards with tons of data models and
> consider the number years all that takes, then a more grass-roots
> approach suddenly becomes very attractive.

Huh? All these models still need to be built, SOAP doesn't magically
provide them. And all these models are still application-semantic
models. So what are they doing in the low levels of the transport layer?

> > I came across a cute quote the other day in someone's signature. I can't
> > recall the exact wording, but it went something like: "People usually are
> > scared when they see a naked skeleton walking around. Yet, for some
> > reason, people aren't scared when they come across naked XML."
> > While facetious, the analogy has a point, IMO.
>
> Sure, I would not write XML manually myself, but Microsoft has
> good tools, just name one vendor here ;-).

Actually, that quote isn't about the difficulty of reading
or authoring XML, or about tool quality. What it really is about
is the complete absence of semantics in an XML message. XML
is structure, pure and simple. The semantics of that structure are
understandable only by prior agreement. In particular, the semantics
do *not* live in the tags; instead, they live in the *meaning* that is
attached to those tags. DocBook is a good example: if I hand a
DocBook XML document to someone who doesn't know DocBook,
the document is meaningless. It becomes meaningful only against
the semantics associated with DocBook. And the semantics are
more than the DTD because the DTD only supplies rules about
structure. To really understand the document, I need to know more.
For example, when I see <para>, I know that this means a
logical paragraph only by convention: if the tag said <absatz> instead,
I wouldn't know what it meant, unless I happen to speak German.
And even if I *do* know German, the knowledge of what a paragraph
*is* is embedded in my head and in the code I write or the tools I use,
not in the XML.

This really illustrates that people get confused about the difference
between syntax and semantics all too easily: XML has no more
semantics than any other encoding, namely, zero semantics. XML is
*all* syntax -- the semantics live entirely elsewhere. (That is what
the "naked" in the quote referred to.)

> I designed a policy
> language a while back with nice syntax, but for a compiler it
> was easier to map it to XML and do parsing and code generation
> on top of a standard XML parser. There are lots of convenient
> XML tools and APIs available.

Right. XML is excellent for document mangling jobs of various kinds.
We generate HTML, Frame source, and PDF from DocBook for
the Ice documentation. This works (mostly) quite well and probably
would not be feasible without XML. But again, that is something
that is relevant to the *application* (document exchange and generation),
not an RPC transport.

> > Right. As I argued previously in this thread, CORBA suffers from
> > "complexiitis" (sp? ;-)  To me, this is one major reason that SOAP
> > ever got a foot in the door: it was perceived to be simpler. Personally,
> > I also think that this is a fallacy -- SOAP and web services are simpler
> > only for as long as they do only a fraction of the things that CORBA
> > does.
>
> Exactly, and actually that is the fraction where it has distinct
> advantages in terms of simplicity and looser coupling.

You said "loose coupling"... Sorry, but that phrase has a
tendency to set me off :-)

I had a long discussion about this on the Distributed Coalition mailing
list maybe two or three years ago. Sadly, it appears that the web site
no longer exists and that the archives are lost :-(  Back then, I argued
that "loose coupling" is a very slippery term. What exactly is it that is
"loosely coupled" in RPC just because I use XML as the marshaling
format? The only thing that I can see that is "loosely coupled" is that
the receiver can throw parts of a message away because the encoding
contains enough syntactic structure to skip over parts of a message.

And that is "loose coupling?" Hmm... So what exactly does this buy me?
Let's see: I can throw bits of a message away that I don't understand.
That's really great -- I'm sure we all would have no problem signing
a contract in which we cannot see some number of clauses that have
been thrown away, right? The fallacy here is that I *cannot* safely
throw something away *that I do not understand*. The only things
I can throw away safely are those that I *do understand* and then,
having understood them and decided that they are irrelevant, decide
to throw away.

The whole notion of "loose coupling" seems to come from some
vague wish to make type systems less draconian, so it becomes
easier for us to change our minds and, say, add a new data field
to something after the fact without having to create a completely
new type. But I have yet to come across a single definition of
"loose coupling" that would be more than this vague notion and
be based on a rigid mathematical type model.

As far as I can see, there is nothing that is loosely coupled here at
all. Either I have a type system, and transmitter and receiver have
a common understanding of the semantics of a message, or I do not.
For RPC, such common understanding is an essential and fundamental
requirement. No amount of fiddling with the marshaling format can
change that.

> > Right. That's the other major reason for why SOAP got a foot in the
> > door. After more than ten years, CORBA *still* does not have a
> > security solution that is anywhere near practical. Surprise, surprise,
> > people don't feel like using it over unsecured public networks and
> > look for something else.
>
> Okay, you gave me the chance, here's the plug: Xtradyne builds
> IIOP proxies that let you do that without even relinking/rebuilding
> your applications. Also, Xtradyne builds SOAP proxies that do
> the same for Web Services.

Okay, plug acknowledged :-)

But can I interoperate with ORBs from different vendors that way?
Is there a standards base? Is the solution ubiquitous? In other words,
that's not CORBA, is it? CORBA failed to come up with a working
solution to the security problem and, therefore, SOAP could leverage
that weakness. But, as far as I know, we are a long way from having
security that would be interoperable, portable, widely accepted, and
widely deployed too. So, the customers are no better off with SOAP
security than with CORBA security, are they?

> >>and with SOAP at least everybody grasps the security
> >>implications immediately.
> >
> > That I believe to be another huge fallacy. The security implications
> > of SOAP are that there is no security, but people somehow refuse to see
> > that.
>
> No, that is not true. The people I talk to, even managers, see
> that immediately.

Huh? Sending everything through port 80 and tunneling straight
into the heart of my intranet to rely on the security of each individual
application is security? Please!

> > By tunneling everything over port 80, I end up disabling the
> > firewall just as effectively as I do by punching a separate whole into
> > a firewall for every CORBA application behind it. Except that, with SOAP,
> > I no longer have even an inkling of what it is that is going through
> > my firewall. With CORBA, and by opening up a separate hole
> > for each application, I at least know what holes I opened...
>
> Except that that never works, when you think of callbacks, the dynamic
> ports you would need to open for processes spawned by an Implementation
> Repository, and the additional level of complexity caused by
> Network Address Translation (NAT). Opening individual ports only
> works for the simplest applications.

Right. That's why CORBA doesn't have a working security solution.
(BTW, for Ice, we worked out good answers to these problems.
See the doc if you are interested.) But the cure is worse than the disease:
instead of designing things such that we can deal with callbacks and NAT
and dynamic port allocation securely, we go and shrug our shoulders and
say "let's send it all through port 80, no more problems that way."
That is naive in the extreme, and upsetting to security experts for good
reason. People like Cheswick don't trash something like SOAP for the
fun of it.

> > As far as architecture is concerned, a number of highly experienced
> > people have critizised SOAP very severely.
>
> Oh, I am not at all defending SOAP as an engineering product.

OK, I accept that. Makes we wonder though why so many people seem
to be willing to go out of their way to defend SOAP.

> > In particular, Paul
> > Prescod has written quite a bit about this (see
> > http://www.prescod.net/rest/security.html for an example)
>
> I would consider that somewhat outdated.

Does that make it any less true?

> > and Cheswick,
> > Belluvin, and Rubin in "Firewall and Internet Security" (Addison-Wesley)
> > have some very uncomplimentary things to say about SOAP too.
>
> Sure, those firewall gurus would ;-). In earnest, I know their book,
> and from a "layer 4 only" perspective I would say the same.

So, we can just dismiss what these experts say and ignore it?

> > The whole approach of tunneling things through HTTP without using
> > HTTP at the level of abstraction it was designed for has many serious
> > security implications.
>
> Sure.

I'm stunned by that answer. What is going on here? Is everyone in
favor of SOAP running around with a blindfold? How can people
ignore something as fundamental as that and, in all seriousness, suggest
that SOAP will be the next-generation world-dominating infrastructure
for e-commerce?

> > Sure, firewalls can be built to look inside SOAP messages and make
> > decisions based on their contents. But that is responding to one stupid
> > design decision with another stupid one: all it leads to is the firewall
> > vendors creating an even more complex product in order to combat
> > the bad design decisions made elsewhere.
>
> I don't agree with you here. IMHO application-level firewalls are
> the way to go because lower-level firewalls will never be able
> to thwart attacks like SQL injection, which take place on the
> application level. Or, if I can get to your name server, I could
> simply replace all your name bindings with ones for my dynamic
> bridges, which would allow me to stage man-in-the-middle attacks
> on the CORBA application layer! A layer 4 firewall will only give you
> a feeling of security, nothing more. Application-level firewalls
> are attractive because you need no access to the application code
> to bring security in.

What is missing is a ubiquitous secure infrastructure that is built into
the transport substrate. IPv6 made a very good stab at that. All the
fundamental prerequisites for platform-based and ubiquitous security
are there. With strong encryption, man-in-the-middle or replay attacks
are impossible. There is still a need for application-level security. But,
as is, the lack of a ubiquitous security infrastructure forces applications
to deal with platform-level security as well as application-level security.
Again, this mixes concerns inappropriately and leads to less secure
systems overall.

> Many experts agree on that, most vendors build them, even Gartner
> says that in a recent report. Gee, it must be true then... ;-)

I'm afraid that I still have to disagree. I think I can safely predict that
the ability of application developers to create new application-level
security concerns will always outpace the ability of firewall vendors
to keep up. As I said, it's an arms race between the good
guys. The sad thing is that, with security built into lower levels, much
of this effort and waste would not be necessary.

> Agreed, heaping tunnels on (or into?) tunnels is a bad idea,
> no doubt.

So why would SOAP be an exception?

> > Hmmm... So, because we have just perverted the networking protocol
> > hierarchy, we now have to go and invent a hole new security system when,
> > had we done things right from the start, there would be no need for any
> > of this.
>
> No, there would always be a need for a proper security model,
> just that in CORBA it got in too late.

Agreed. But SOAP is getting it in too late too, and at the wrong level.
The approach that is being taken is to invent a completely new security
model every time we do a new form of RPC. DCE had a security model,
CORBA has one,  SOAP has one. All of them are completely different,
don't interoperate even at a conceptual level, and all of them must be
independently verified and separately build up a trust base. This
would not be necessary if security were something below the RPC level:
in that case, RPC could concern itself only with RPC-related security
and ignore transport-related security issues.

> > This is ridiculous: security belongs at the low levels of the
> > hierarchy.
>
> No, see above.

There are bits that definitely belong at the low levels, such as
encryption, key distribution, authentication, etc.

> > SOAP is off to a bad start. It has architectural problems as well as
> > efficiency problems.
>
> What are these architectural problems? SOAP actually does not
> require much of an architecture.

Well, see Prescod's arguments. The protocol layering inversion
is problematic, the tunneling issue is problematic, the fact that everything
is thrown into a big hairball is problematic. (Think about it: what is it
that HTTP actually does for SOAP? Very little -- SOAP goes and
invents its own addressing, encoding, message formats, marshaling,
you name it. In fact, SOAP uses HTTP for so little, you might almost
use raw sockets and TCP/IP instead of HTTP.

> > The effort is flawed from its conception and that flaw will never
> > be made to disappear (just as CORBA still suffers from the flaws in its
> > protocol).
>
> You may be right, or you may not be. There is certainly a lot more
> industry pushing in the XML standardization bodies than what I
> have seen in the OMG, but perhaps I missed the strongest tides.

Right. A lot of industry push does not equate to successful outcomes
though.

> > Finally, for what it's worth, Ice offers a security solution that is
> > pragmatic, simple, easy to use and configure, works through
> > firewalls without perverting them, is as secure as SSL, and works.
>
> As secure as SSL? That means: no end-to-end security? Only all-or-
> nothing encryption or signing? The XML security standards are
> actually quite a step forward in this respect.

I meant cryptographically as secure as SSL. Glacier (the Ice
security service) adds functionality on top of that.

> > You can read about the details in the Ice doc.
>
> Hope I will get a chance.

Please do -- better than me regurgitating it all here.

Cheers,

Michi.

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

0
michi9457 (29)
8/15/2003 12:09:07 AM
> Right. XML is excellent for document mangling jobs of various kinds.
>
>We generate HTML, Frame source, and PDF from DocBook for
>the Ice documentation. This works (mostly) quite well and probably
>would not be feasible without XML. But again, that is something
>that is relevant to the *application* (document exchange and generation),
>not an RPC transport.
>  
>
Wow, XML/DocBook has almost achieved what LaTeX/TeX accomplished in the 
80's and early 90's! :-)
(And it's still a major subset of LaTeX's capability today.) Man, we're 
making real progress quickly.
It seems like the software industry just loves to churn old concepts to 
death.

Now, back to the program in progress....

0
rrr6399 (33)
8/15/2003 1:50:18 AM
Rob Ratcliff <rrr6399@futuretek.com> wrote:
>
>  Man, we're making real progress quickly.
>  It seems like the software industry just loves to churn old concepts to 
>  death.
>
>  Now, back to the program in progress....
>

 Ssshhh, Rob! Don't tell our managers that we've been delivering warmed-up
ideas all along. If software engineers ever started doing code reuse for
real, half of us would be out of a job.

 Also, if code reuse ever worked, another half of the workforce that does
nothing but legacy systems integration and administration could file for
social security.

 Object orientation is only good for proving that "code reuse" is a
theoretical possibility. Now that most have that figured out, we start
delivering component-based systems instead. As if there were a diffe-
rence.

 Another thing that SOAP delivers: we can now prove that whatever we've
been doing with sockets, RPC and CORBA is _still_ feasible ;)

 Have fun,
	Frank


-- 
Frank Pilhofer  ...........................................  fp@fpx.de
Live every day as if it were your last, because one of these days you
will be right! - Alfred E. Neuman
0
fp (16)
8/15/2003 4:26:22 AM
Marcel Ruff <mr@marcelruff.info> wrote in message news:<bfpht1$p3p$00$1@news.t-online.com>...
> Michi Henning wrote:
> > Hi,
> > 
> > we've just released a new version of the Ice documentation:
> > 
> > - A new chapter on the server-side run time explains useful
> >   things such as oneway invocations, datagram invocations,
> >   and batched invocations (the last two of which CORBA can't do ;-)
> > 
> >   There is also quite a bit of material on how to make servers
> >   scalable using various techniques, such as default servants
> >   and evictors. (CORBA users should have a look and weep at
> >   how simple things can be with properly designed APIs...)
> > 
> > - A new chapter on asynchronous method invocation (AMI) and
> >   asynchronous method dispatch (AMD). AMI works along similar
> >   lines as the CORBA version; AMD has no equivalent in CORBA:
> >   it allows you to suspend processing of a method invocation
> >   in the server to free up a processing thread and to then
> >   later resume processing of that invocation again. This is
> >   very nice if you want to build scalable blocking interfaces
> >   (such as providing a pull model to event consumers) without
> >   tying up thousands of threads. (The pull model for event consumers
> >   can't be made to scale with CORBA, unfortunately.)
> > 
> > You can find the documentation at http://www.zeroc.com/download.html.
> > 
> > Enjoy!
> > 
> > Cheers,
> > 
> > Michi.
> > 
> > --
> > Michi Henning                Ph: +61 4 1118-2700
> > ZeroC, Inc.                  http://www.zeroc.com
> > 
> Nice approach, but i think on massive distributed
> systems the 'not generic RPC approach' is not scaling over time
> and versions.
> 
> I think it is time for more loosly coupled MoM like solutions like
> JMS or our xmlBlaster (http://www.xmlBlaster.org).
> Thinking asynchronous in such environments is often
> a smarter way to go :-)
> 
> regards,
> 
> Marcel
I love ice.I have used ice in an exchange system. performance is fine!
Corba is to complexed and we cannot use.
0
qiuzhengqing
8/15/2003 8:12:33 AM
In article <D5U_a.34386$bo1.32857@news-server.bigpond.net.au>, Michi
Henning <michi@triodia.com> writes
>
<snip>
>Sure, so does most everyone. If we have something that is very fast,
>we brag about it. But customers rarely notice it. What they *do* tend
>to notice are those bits that are too slow. And they never come to us
>with comments along the lines of "you stupid fools, why did you make
>part X go so fast? 20 times slower would have been good enough."
>
Simply put, the slowest component usually dominates performance.
It's on the critical path. Good performance optimisation strategy,
as I recall, is to write a well-designed program, use profiling
to find any bottlenecks, and then optimise them - but only if
performance requirements are not already being met. (Btw, that
would also eliminate the criticism "why did you make part X go so
fast?" If it was carefully optimised to reach that performance,
the effort was probably wasted).

All rules of thumb, of course, involve assumptions. This one
assumes that any standard software being used is already as
efficient as it can reasonably be.

<snip>
>
>> What
>> happened to the old adage "use the right tool for the job"?
>
>I wonder about that myself. XML isn't the right tool for RPC, so
>why do we insist on using it for RPC?
>
As I see it, this isn't a technical problem at all - which may
be why it seems so baffling. May I suggest this is due to some
extremely primitive (but no doubt familiar) thinking: the
widespread preference to oversimplify matters we don't understand.

Non-technical people (managers, journalists, most analysts, etc)
have a strong tendency to seek sweeping single solutions to
computer problems. (These are aka "silver bullets"). Hence the
sudden discovery that "relational is all you need", "Windows
is all you need", and now... "XML is all you need". My all-time
favourite comment (made by a senior Wall Street VP to a journalist)
is "We are going with XML because it is the fastest Internet
protocol".  8-)
-- 
Tom Welsh
0
news892 (8)
8/15/2003 8:54:37 AM
"Tom Welsh" <news@tom-welsh.co.uk> wrote in message
news:MvoAyLAN$JP$EwOu@nildram.co.uk...
> In article <D5U_a.34386$bo1.32857@news-server.bigpond.net.au>, Michi
> Henning <michi@triodia.com> writes
> >
> <snip>
> >Sure, so does most everyone. If we have something that is very fast,
> >we brag about it. But customers rarely notice it. What they *do* tend
> >to notice are those bits that are too slow. And they never come to us
> >with comments along the lines of "you stupid fools, why did you make
> >part X go so fast? 20 times slower would have been good enough."
> >
> Simply put, the slowest component usually dominates performance.
> It's on the critical path. Good performance optimisation strategy,
> as I recall, is to write a well-designed program, use profiling
> to find any bottlenecks, and then optimise them - but only if
> performance requirements are not already being met.

I couldn't agree more. In fact, I distinctly remember a third-semester
subject I took during my degree that said exactly that :-)

> (Btw, that
> would also eliminate the criticism "why did you make part X go so
> fast?" If it was carefully optimised to reach that performance,
> the effort was probably wasted).

Right. I've never heard someone point out that something is very
fast, except if it was very fast compared to some other, similar
product that was slower. But I've heard plenty of times from
people when things were too slow :-)

> As I see it, this isn't a technical problem at all - which may
> be why it seems so baffling. May I suggest this is due to some
> extremely primitive (but no doubt familiar) thinking: the
> widespread preference to oversimplify matters we don't understand.

Yes, I'm sure that has a lot to do with it.

> Non-technical people (managers, journalists, most analysts, etc)
> have a strong tendency to seek sweeping single solutions to
> computer problems. (These are aka "silver bullets"). Hence the
> sudden discovery that "relational is all you need", "Windows
> is all you need", and now... "XML is all you need". My all-time
> favourite comment (made by a senior Wall Street VP to a journalist)
> is "We are going with XML because it is the fastest Internet
> protocol".  8-)

Beeauutiful! :-)

I think you have a real insight here: all this new-fangled computing
stuff is just so dang complicated that anything is seen to remove
the complexity is a sure-fire bet. Sad, isn't it? I think it also says
a lot about the state of maturity of this industry: we are still at the
stage where we won't admit that there is no such thing as the
Philosopher's Stone.

Cheers,

Michi.

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

0
michi9457 (29)
8/15/2003 9:21:43 AM
"Michi Henning" <michi@triodia.com> wrote in
news:D5U_a.34386$bo1.32857@news-server.bigpond.net.au: 

> "Dilip" <rdilipk@lycos.com> wrote in message
> news:8bc3089c.0308130634.1a910ed6@posting.google.com...
[...]
>> What
>> happened to the old adage "use the right tool for the job"?
> 
> I wonder about that myself. XML isn't the right tool for RPC, so
> why do we insist on using it for RPC?
> 

A commonly used argument is that Web Services with their XML internals have 
a strong possibility to become a "unification" platform for all existing 
("legacy") platforms like DCOM, CORBA, EJB, etc. If you think about it it's 
like finding a common language that permits different component and 
communication technologies to communicate with each other. Of course Web 
Services may succeed in that not thanks to any technical superiority -- I 
agree with what Michi and others said about the use of XML as a wire 
format, the firewall traversal nonsense, etc. -- but to a seemingly 
unanimous support and acceptance by the "big players" like Microsoft and 
IBM. It is a bit unfortunate that the same thing could be the case for 
CORBA some years ago if Microsoft really embrassed (without "extending" :-) 
it instead of pushing its own middleware solution in terms of COM, DCOM, 
etc.

Note that this view holds as long as there is this universal support of WS 
and the standards remain open, no patents are enforced, the implementations 
interoperate, and no "forks" are attempted. Otherwise we need to find/(re)
invent/.. another technology in a higher level to integrate WS variants and 
so on ad nauseam.. In any case I strongly believe that the success and the 
future of WS is based on political rather than technical issues.

As long as the performace issue raised by Michi is concerned, what I was 
once told is that normally the network is the bottleneck so the 
optimization of encoding/decoding of XML won't give much when WS used over 
the Internet as this is the most common use case. Of course the XML 
messages are big but also HTTP/HTML are verbose and this did not preclude 
their wide deployment and use. Also compression of messages is always an 
option although I don't know how "standardised" it is at the time being.

>> P.S: I will try to dig up that article.  It was extensively about how
>> vendors focus on performance while ignoring other facts that are not
>> so easily measurable.
> 
It should be this: <http://www.iona.com/hyplan/vinoski/pdfs/IEEE-
The_Performance_Presumption.pdf>

Regards
Stelios

-- 
Stelios G. Sfakianakis | Center of Medical Informatics
Voice: +30-2810-391650 | Institute of Computer Science
PGP Key ID: 0x5F30AAC2 | FORTH, http://www.forth.gr
   http://www.biglumber.com/x/web?qs=0x5F30AAC2
0
ssfak1 (5)
8/26/2003 8:02:59 AM
In article <Xns93E3706878C63ssfakicsforthgr@194.177.210.210>, Stelios
Sfakianakis <ssfak@REMOVE_THISics.forth.gr> writes
>
>A commonly used argument is that Web Services with their XML internals have 
>a strong possibility to become a "unification" platform for all existing 
>("legacy") platforms like DCOM, CORBA, EJB, etc. If you think about it it's 
>like finding a common language that permits different component and 
>communication technologies to communicate with each other.

This argument has always mystified me.

If one person speaks, say, Brazilian Portuguese only, and another speaks
Japanese only, they have a problem communicating.

One solution is to hire an interpreter. This probably costs some money,
and introduces delays and a degree of inaccuracy in translation.

Another solution is for one of the speakers to learn the other one's
language.

A third solution - which seems inferior to me - is for both parties to
agree to learn Esperanto, and converse using that. Both have to learn a
new language - and one which, moreover, is far less expressive than
either of their native tongues.

If they could really "find" a common language, that would work better.
But what are the odds that the Brazilian and the Japanese will both
suddenly remember "Oh yes, I speak Norwegian too!"

-- 
Tom Welsh
0
news892 (8)
8/28/2003 6:42:30 AM
Tom Welsh <news@tom-welsh.co.uk> wrote in
news:iMC7aJAWRaT$EwYd@nildram.co.uk: 

> In article <Xns93E3706878C63ssfakicsforthgr@194.177.210.210>, Stelios
> Sfakianakis <ssfak@REMOVE_THISics.forth.gr> writes
>>
>>A commonly used argument is that Web Services with their XML internals
>>have a strong possibility to become a "unification" platform for all
>>existing ("legacy") platforms like DCOM, CORBA, EJB, etc. If you think
>>about it it's like finding a common language that permits different
>>component and communication technologies to communicate with each
>>other. 
> 
> This argument has always mystified me.
> 
> If one person speaks, say, Brazilian Portuguese only, and another
> speaks Japanese only, they have a problem communicating.
> 
> One solution is to hire an interpreter. This probably costs some
> money, and introduces delays and a degree of inaccuracy in
> translation. 

Correct!

> 
> Another solution is for one of the speakers to learn the other one's
> language.
> 

...which also costs some money, takes time, etc.

> A third solution - which seems inferior to me - is for both parties to
> agree to learn Esperanto, and converse using that. Both have to learn
> a new language - and one which, moreover, is far less expressive than
> either of their native tongues.

That's true. But, I think, the whole point is that everyone sooner or 
later will learn Esperanto (i.e. Web Services, SOAP etc.) so next time 
that one of these two guys meets another person which speaks Greek _and_ 
Esperanto they 'll have a "nice" chat.

> 
> If they could really "find" a common language, that would work better.
> But what are the odds that the Brazilian and the Japanese will both
> suddenly remember "Oh yes, I speak Norwegian too!"
> 

...or they could *instantly* remember "Oh yes, I speak Esperanto too!", 
possibly forced by the wide spread of this "weird" language :-D


Regards
Stelios


-- 
Stelios G. Sfakianakis | Center of Medical Informatics
Voice: +30-2810-391650 | Institute of Computer Science
PGP Key ID: 0x5F30AAC2 | FORTH, http://www.forth.gr
   http://www.biglumber.com/x/web?qs=0x5F30AAC2
0
ssfak1 (5)
8/28/2003 12:34:27 PM
In article <Xns93E59E6E45CE1ssfakicsforthgr@194.177.210.210>, Stelios
Sfakianakis <ssfak@REMOVE_THISics.forth.gr> writes
>
>That's true. But, I think, the whole point is that everyone sooner or 
>later will learn Esperanto (i.e. Web Services, SOAP etc.) so next time 
>that one of these two guys meets another person which speaks Greek _and_ 
>Esperanto they 'll have a "nice" chat.
>
How many people do you know who speak Esperanto? Virtually no one of my
acquaintance does. It was a nine days' wonder - everyone gave up when
they realised how hard it was to say anything interesting or useful in
it.

When you say "everyone sooner or later will learn Esperanto" - that is
exactly what did NOT happen in the real world.

>> 
>> If they could really "find" a common language, that would work better.
>> But what are the odds that the Brazilian and the Japanese will both
>> suddenly remember "Oh yes, I speak Norwegian too!"
>> 
>
>..or they could *instantly* remember "Oh yes, I speak Esperanto too!", 
>possibly forced by the wide spread of this "weird" language :-D
>
Not in this universe!  8-)

-- 
Tom Welsh
0
news892 (8)
8/28/2003 2:17:54 PM
Tom Welsh <news@tom-welsh.co.uk> wrote in
news:I2jREVAS8gT$EwfB@nildram.co.uk: 

> In article <Xns93E59E6E45CE1ssfakicsforthgr@194.177.210.210>, Stelios
> Sfakianakis <ssfak@REMOVE_THISics.forth.gr> writes
>>
>>That's true. But, I think, the whole point is that everyone sooner or 
>>later will learn Esperanto (i.e. Web Services, SOAP etc.) so next time
>>that one of these two guys meets another person which speaks Greek
>>_and_ Esperanto they 'll have a "nice" chat.
>>
> How many people do you know who speak Esperanto?

None! I just continued your very nice metaphor.

>                                                  Virtually no one of
> my acquaintance does. It was a nine days' wonder - everyone gave up
> when they realised how hard it was to say anything interesting or
> useful in it.
> 
> When you say "everyone sooner or later will learn Esperanto" - that is
> exactly what did NOT happen in the real world.

Okay, so it appears that now the metaphor does not serve us well -- maybe 
I pushed it too much :-). All I wanted to say is that provided that there 
is indeed this "universal support" for the Web Services (from companies, 
organizations, market, etc.)  more and more people will ultimately be 
"forced" to climb the WS bandwagon, which definitely did not happened 
with Esperanto. Of course it is possible that this will not happen for 
the WS either! Only time can tell...
 
Regards
Stelios



-- 
Stelios G. Sfakianakis | Center of Medical Informatics
Voice: +30-2810-391650 | Institute of Computer Science
PGP Key ID: 0x5F30AAC2 | FORTH, http://www.forth.gr
   http://www.biglumber.com/x/web?qs=0x5F30AAC2
0
ssfak1 (5)
8/28/2003 3:07:19 PM
B.W.H. van Beest wrote:
> Wouldn't the .NET/SOAP approach (including the Open Source Mono project) 
> have much better chances? After all, I think earlier in this thread it 
> was agreed that it is usually not the technical quality, or best fit for 
> purpose, that determines the end solution.

Have a look at the latest announcement at http://www.go-mono.com:

"Ice: Vladimir has checked into CVS (Module ginzu) an implementation of 
ZeroC's ICE protocol. It is implemented using Remoting. If you were 
looking for an efficient binary protocol to use with Remoting, this is it."

Looks as if Ice also got some attention in the .NET/Mono world. I think 
that's great! We will do everything to help the Mono people to integrate 
with Ice. This could also be a way out of a potential patent dilemma. 
The Ice protocol is free, and cannot be threatened by Microsoft.

-- Marc

0
marc4371 (25)
9/2/2003 12:41:18 PM
In article <871xv4nljl.fsf@doohan.bang.priv.no>, Steinar Bang
<sb@dod.no> writes
>>>>>> Tom Welsh <news@tom-welsh.co.uk>:
>
>> If they could really "find" a common language, that would work
>> better.  But what are the odds that the Brazilian and the Japanese
>> will both suddenly remember "Oh yes, I speak Norwegian too!"
>
>Actually, as a native Norwegian speaker, my initial choice for
>attempting to speak with the Brazilian and the Japanese, would be
>English and not Esperanto.
>
>I'm not sure if that supports or opposes your analogy.  Or if it's
>even releated.

Well, as much as anything, it exposes the limitations of the analogy.

But it's worth noticing that English would be a logical choice because

1. It is an extremely rich and diverse language, with far more words
than most languages, and hundreds or thousands of dialects and
specialised vocabularies.

2. Partly for that reason, and partly for historical reasons, English is
the world's most widely spoken language. (Not necessarily that spoken by
the most people, though).

English, unlike Esperanto, is rich and - above all - is already the
de-facto global language. 

So, which is more similar to Web services today: English or Esperanto? I
would definitely suggest Esperanto.

-- 
Tom Welsh
0
Tom
9/8/2003 9:08:08 AM
Reply:

Similar Artilces:

SOAP vs RPC (CORBA, Ice...), was: Re: New Ice documentation available
Michi Henning wrote: > "Gerald Brose" <gerald.brose@xtradyne.com> wrote: > So far, I'm still looking for an equivalent reason for using SOAP. (And, > in case you wondering, no, I *don't* own a 747 :-) Okay, this has been a lengthy exchange of arguments - which I enjoy - but before delving back into the details let me say this much: - I am not saying SOAP is here to replace CORBA or Ice or any other RPC technology, I am saying it is here to complement those in areas where that makes sense because of certain advantages in XML-based mes...

[ace-users] New repackaged x.5.3 documentation available
Hi, We found that the x.5.3 html documentation wasn't packaged correctly. The zip package contained also the tar.gz and tar.bz2 packages. We have repackaged all the html files, you can download them from http://download.dre.vanderbilt.edu. Regards, Johnny Willemsen Remedy IT Postbus 101 2650 AC Berkel en Rodenrijs The Netherlands www.theaceorb.nl / www.remedy.nl ...

[ace-announce] New set of ACE/TAO/CIAO metrics available
Hi all, We have moved all ACE/TAO/CIAO metrics to emulab at ISIS. As part of this move we have added a few new metrics builds. All results are available online at http://www.dre.vanderbilt.edu/Stats/ The results include: - performance benchmarks - footprint results - code coverage results (work in progress, build doesn't gather all data correctly yet) - compilation metrics Regards, Johnny Willemsen Remedy IT http://www.theaceorb.nl ...

[ace-users] Set of new ACE/TAO/CIAO related presentations available
Hi all, We have delivered this week several presentations related to ACE/TAO/CIAO at the OMG Meeting this week in Berlin. Public copies of these presentations can be found online at http://www.slideshare.net/RemedyIT Best regards, Johnny Willemsen Remedy IT Support and services for ACE/TAO/CIAO/DAnCE/OpenDDS http://www.remedy.nl ...

[ace-users] New ACE/TAO/CIAO/DAnCE x.2.0 minor release available for download
Hi all, Once again, thanks to the efforts of many developers, testers, and users, we are pleased to announce the minor release of ACE 6.2.0, TAO 2.2.0, CIAO 1.2.0, and DAnCE 1.2.0, which is available from the usual download location at: http://download.dre.vanderbilt.edu/ under the heading "Latest Release". The doxygen documentation for this release is also available. In addition to the packages combined of sources and generate makefiles, this release provides source-only packages for developers who use MPC to generate their own makefiles. We encourage you to download the new release, use it with your applications, and let us know if you encounter any problems. Please use the: $ACE_ROOT/PROBLEM-REPORT-FORM $MPC_ROOT/PROBLEM-REPORT-FORM $TAO_ROOT/PROBLEM-REPORT-FORM $CIAO_ROOT/PROBLEM-REPORT-FORM $DANCE_ROOT/PROBLEM-REPORT-FORM so that we have the proper version/platform/compiler/options you're using to report problems. We also request that you take a look at: $TAO_ROOT/docs/releasenotes/ for the status of various ongoing projects at the DOC group of Vanderbilt to move ACE+TAO+CIAO+DAnCE forward. Overviews of our recent progress and upcoming plans are available at: $ACE_ROOT/NEWS $TAO_ROOT/NEWS $CIAO_ROOT/NEWS $DANCE_ROOT/NEWS The overall success rates for the test results gathered from all our daily builds is 97% for the ACE tests and 96% for the TAO, CIAO, and DAnCE tests. Please see: http://www....

[ace-announce] New ACE/TAO/CIAO/DAnCE x.2.0 minor release available for download
Hi all, Once again, thanks to the efforts of many developers, testers, and users, we are pleased to announce the minor release of ACE 6.2.0, TAO 2.2.0, CIAO 1.2.0, and DAnCE 1.2.0, which is available from the usual download location at: http://download.dre.vanderbilt.edu/ under the heading "Latest Release". The doxygen documentation for this release is also available. In addition to the packages combined of sources and generate makefiles, this release provides source-only packages for developers who use MPC to generate their own makefiles. We encourage you to download the new release, use it with your applications, and let us know if you encounter any problems. Please use the: $ACE_ROOT/PROBLEM-REPORT-FORM $MPC_ROOT/PROBLEM-REPORT-FORM $TAO_ROOT/PROBLEM-REPORT-FORM $CIAO_ROOT/PROBLEM-REPORT-FORM $DANCE_ROOT/PROBLEM-REPORT-FORM so that we have the proper version/platform/compiler/options you're using to report problems. We also request that you take a look at: $TAO_ROOT/docs/releasenotes/ for the status of various ongoing projects at the DOC group of Vanderbilt to move ACE+TAO+CIAO+DAnCE forward. Overviews of our recent progress and upcoming plans are available at: $ACE_ROOT/NEWS $TAO_ROOT/NEWS $CIAO_ROOT/NEWS $DANCE_ROOT/NEWS The overall success rates for the test results gathered from all our daily builds is 97% for the ACE tests and 96% for the TAO, CIAO, and DAnCE tests. Please see: http://www....

ODs new document available
Hello odser's it seems that you have a new document forwarding help to ptoc report and tabulate style http://support.sas.com/resources/papers/stylesinprocs.pdf i remark also some new tip sheet at http://support.sas.com/rnd/base/index.html ods rtf and ods tagsets rtf (9.2) (even if we have to wait until mid(?) of next year to receive access to it(9.2) here in France) HTH Andre -- Andr� WIELKI INED (Institut National d'Etudes D�mographiques) Service Informatique 133 Boulevard Davout 75980 Paris Cedex 20 m�l : wielki@ined.fr t�l : 33 (0) 1 56 06 21 54 ...

New documentation on transputer.net available
For all T9000 interested people: The T9000 Transputer Hardware Reference Manual http://www.transputer.net/ibooks/72-trn-238-01/book.asp The T9000 Transputer Instruction Set Manual http://www.transputer.net/iset/72-trn-240-01/book.asp The T9000 Development Tools http://www.transputer.net/ibooks/72-trn-249-00/book.asp For the few remaining TDS programmer in the field: Transputer Development System http://www.transputer.net/prog/72-trn-011-00/book.asp Overall ~1500 additional pages and many many many pdf-bookmarks! Thx to a generous Belgian supporter of transputer.net for...

New "base document" available
For those of you (if any <G>) who care about the progress of the COBOL Standard revision work, a new "base document" (WD 1.7) is available (in zipped format) online at: http://www.cobolstandard.info/j4/files/std.zip -- Bill Klein wmklein <at> ix.netcom.com I care. Thanks! Is there anything that shows the differences between this version and the prior version? Just wondering. Frank n 3/29/2007 at 3:55 PM, in message <lBWOh.137091$dB6.130725@fe08.news.easynews.com>, William M. Klein<wmklein@nospam.netcom.com> wrote: > For those of you (if an...

[ace-users] New TAO Programmers Guide available
Hi all, We have made a new version of the TAO Programmers Guide available online at www.theaceorb.nl. This new version has been updated for the x.6.7 release Regards, Johnny Willemsen Remedy IT ...

[ace-users] New set of TAO benchmarks results available!
Hi, We are pleased to announce a new set of TAO benchmark results. These results will be gathered on a regular base and then published online. This effort has been funded through Vanderbilt University via a project with GE Research. The goal was to get more insight in the runtime performance difference between CORBA and CORBA/e. The test suite we use has been created by Distributed Systems Research Group from the Charles University in Prague (see http://dsrg.mff.cuni.cz). The suite (http://dsrg.mff.cuni.cz/~ceres/prj/CCPsuite/) consists out of several types of performance tests. The tests include marshal, dispatch, and invocation measurements. We have updated the regression suite to work with TAO 1.6.x and using the updated suite we compared the following 3 TAO configurations: * Regular build using shared libraries * CORBA/e micro build using shared libraries * CORBA/e micro build using static libraries The test suite generates a large number of graphs comparing these configurations. The graphs show a significant difference between CORBA and CORBA/e. In particular, CORBA/e has higher performance and lower resource utilization, especially when compiled/linked as static libraries. The results are available online at http://www.dre.vanderbilt.edu/Stats/ under Xampler Performance benchmarks. Please let us know if you have any questions or comments. If you are interested in some specific type of test which isn't part of the test suite pleas...

[tao-users] (New) Debian packages available for ACE+TAO
Hi, The ACE+TAO packages for Debian have now new maintainers. The task has been undertaken by Brian Nelson <pyro@debian.org> and myself. Thanks must go to Ossama Othman <ossama@debian.org> for carrying out this difficult task until now! The main changes that one will notice is the inclusion of TAO in the package list. ACEXML has also been included as a separate package since some TAO components depend on ACEXML. All examples have been included in the respective -doc packages. The orb services of TAO have been included in two separate packages as well. Right now we are already in the -4 revision (soon to be uploaded), fixing some minor bugs and lintian warnings. The only remaining lintian warning is man pages for the ORB services executables. We would appreciate any feedback from Debian+ACE/TAO users. So far, every ACE program that worked with the previous versions continues to work, I've done some extensive testing, since I use ACE for my own projects. So, no (obvious) problem there. But as there was not any previous TAO package available for a long time, we would appreciate any input with regards to these packages' behaviour. The following packages are/should be available from your Debian mirror (at first in unstable, but hopefully soon in testing as well): gperf-ace libace5.3.1 libace-dev libace-doc libace-rmcast5.3.1 libace-rmcast-dev libacexml5.3.1 libacexml-dev libtao1.3.1 libtao-dev libtao-doc libtao-orbsvcs1.3.1 libtao-orbs...

[ciao-users] New repackaged x.5.3 documentation available
Hi, We found that the x.5.3 html documentation wasn't packaged correctly. The zip package contained also the tar.gz and tar.bz2 packages. We have repackaged all the html files, you can download them from http://download.dre.vanderbilt.edu. Regards, Johnny Willemsen Remedy IT Postbus 101 2650 AC Berkel en Rodenrijs The Netherlands www.theaceorb.nl / www.remedy.nl ...

[ciao-users] Set of new ACE/TAO/CIAO related presentations available
Hi all, We have delivered this week several presentations related to ACE/TAO/CIAO at the OMG Meeting this week in Berlin. Public copies of these presentations can be found online at http://www.slideshare.net/RemedyIT Best regards, Johnny Willemsen Remedy IT Support and services for ACE/TAO/CIAO/DAnCE/OpenDDS http://www.remedy.nl ...

[ciao-users] New ACE/TAO/CIAO/DAnCE x.2.0 minor release available for download
Hi all, Once again, thanks to the efforts of many developers, testers, and users, we are pleased to announce the minor release of ACE 6.2.0, TAO 2.2.0, CIAO 1.2.0, and DAnCE 1.2.0, which is available from the usual download location at: http://download.dre.vanderbilt.edu/ under the heading "Latest Release". The doxygen documentation for this release is also available. In addition to the packages combined of sources and generate makefiles, this release provides source-only packages for developers who use MPC to generate their own makefiles. We encourage you to download the new release, use it with your applications, and let us know if you encounter any problems. Please use the: $ACE_ROOT/PROBLEM-REPORT-FORM $MPC_ROOT/PROBLEM-REPORT-FORM $TAO_ROOT/PROBLEM-REPORT-FORM $CIAO_ROOT/PROBLEM-REPORT-FORM $DANCE_ROOT/PROBLEM-REPORT-FORM so that we have the proper version/platform/compiler/options you're using to report problems. We also request that you take a look at: $TAO_ROOT/docs/releasenotes/ for the status of various ongoing projects at the DOC group of Vanderbilt to move ACE+TAO+CIAO+DAnCE forward. Overviews of our recent progress and upcoming plans are available at: $ACE_ROOT/NEWS $TAO_ROOT/NEWS $CIAO_ROOT/NEWS $DANCE_ROOT/NEWS The overall success rates for the test results gathered from all our daily builds is 97% for the ACE tests and 96% for the TAO, CIAO, and DAnCE tests. Please see: http://www....

[ciao-announce] New ACE/TAO/CIAO/DAnCE x.2.0 minor release available for download
Hi all, Once again, thanks to the efforts of many developers, testers, and users, we are pleased to announce the minor release of ACE 6.2.0, TAO 2.2.0, CIAO 1.2.0, and DAnCE 1.2.0, which is available from the usual download location at: http://download.dre.vanderbilt.edu/ under the heading "Latest Release". The doxygen documentation for this release is also available. In addition to the packages combined of sources and generate makefiles, this release provides source-only packages for developers who use MPC to generate their own makefiles. We encourage you to download the new release, use it with your applications, and let us know if you encounter any problems. Please use the: $ACE_ROOT/PROBLEM-REPORT-FORM $MPC_ROOT/PROBLEM-REPORT-FORM $TAO_ROOT/PROBLEM-REPORT-FORM $CIAO_ROOT/PROBLEM-REPORT-FORM $DANCE_ROOT/PROBLEM-REPORT-FORM so that we have the proper version/platform/compiler/options you're using to report problems. We also request that you take a look at: $TAO_ROOT/docs/releasenotes/ for the status of various ongoing projects at the DOC group of Vanderbilt to move ACE+TAO+CIAO+DAnCE forward. Overviews of our recent progress and upcoming plans are available at: $ACE_ROOT/NEWS $TAO_ROOT/NEWS $CIAO_ROOT/NEWS $DANCE_ROOT/NEWS The overall success rates for the test results gathered from all our daily builds is 97% for the ACE tests and 96% for the TAO, CIAO, and DAnCE tests. Please see: http://www....

[ace-users] ACE real time documentation
------=_Part_16235_26034830.1178544944988 Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi, I look for documentation about real time in ACE thank you in advance, -Hassane ------=_Part_16235_26034830.1178544944988 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Content-Disposition: inline Hi,<br> I look for documentation about real time in ACE<br> thank you in advance,<br> -Hassane<br> ------=_Part_16235_26034830.1178544944988-- ...

[ace-users] linking with ACE Doxygen documentation
We have recently begun using ACE for our project. Our project is also being written so that it is documented with Doxygen markup. We'd like to link our documentation with the ACE documentation online. Are there any guidelines or procedures for how this can be done? Specifically, I'm looking to do something along the lines of what's described at: http://www.stack.nl/~dimitri/doxygen/external.html thanks, Garret __________________________________ Do you Yahoo!? Yahoo! Mail Address AutoComplete - You start. We finish. http://promotions.yahoo.com/new_mail ...

Javascript new-new-new-new-newbee
Hello, The last two days I have done some Javascripting, but without succes. My goal is the following: I have 4 <form>-input fields; 2 <select> and 2 <input type=text>. The <select> fields are 'number (1 until 10)' and a description-list. When the number or description changes, the function calculate must be called. So far, so good. My problem is that I don't know how to handle the vars in Javascript. I read the internet for two days, but I do not know what to do. My problem is that I get an [object] output. So, I think that is an array, but I do not know why. I have placed the source hereunder. Please advise me what to do and... Maybe the above text is written well English, my English is not that good :-s Thank you in advance! PS. The Javascript is part of an PHP-script. +++++ START SOURCE +++++ <form name=listform id=listform action=index.phtml method=post> <script language='Javascript'> function calculate(rij) { var sort = new Array() var code = new Array() var description = new Array() var size = new Array() var occurs = new Array() sort[0]='1' code[0]='install' description[0]='Installation costs, including first internet page' size[0]='420.00' occurs[0]='' sort[1]='2' code[1]='inet' description[1]='Internet page without contentmanagement' size[1]='110.00' occurs[1]='' sort[2]='3' code[2]='inetc' description[2]='...

RE: [ace-users] linking with ACE Doxygen documentation
Hi, > We have recently begun using ACE for our project. Our > project is also being written so that it is documented > with Doxygen markup. > > We'd like to link our documentation with the ACE > documentation online. Are there any guidelines or > procedures for how this can be done? Specifically, > I'm looking to do something along > the lines of what's described at: > > http://www.stack.nl/~dimitri/doxygen/external.html I would recommend you to download the ACE documentation zip from http://deuce.doc.wustl.edu/Download.html and put it on your own server. Inside the zip you will find to tag files doxygen uses. You can reference them from your own doxygen config files without problems. Having everything on your own server will save you (and Vanderbilt) a lot of internet bandwith. Regards, Johnny Willemsen Remedy IT Leeghwaterstraat 25 2811 DT Reeuwijk The Netherlands www.theaceorb.nl / www.remedy.nl ...

[ace-users] ACE/TAO RPMs available at OBS
Hi, We have made the RPMs for ACE/TAO x.0.6 available at OpenSUSE Build Service. The exact list of supported platforms and their download links are available at ORBZone (see http://www.orbzone.org/node/220) Best regards, Johnny Willemsen http://www.theaceorb.nl ...

[ace-users] ACE/TAO RPMs available for SLE_11_SP4
Hi, We are pleased to announce that the OpenSuSE build service now also provides RPMs for SLE11 SP4. See the links below for the various RPMs. Best regards, Johnny Willemsen Remedy IT http://www.theaceorb.nl Support and services for ACE/TAO Latest micro release http://download.opensuse.org/repositories/devel:/libraries:/ACE:/micro/ Latest micro release with versioned namespaces http://download.opensuse.org/repositories/devel:/libraries:/ACE:/micro:/versioned/ Latest bug fix only release http://download.opensuse.org/repositories/devel:/libraries:/ACE:/bugfixonly/ Latest bu...

how to convert XML document to several XML documents in a new format
I'm migrating data into a content management system and in order to use the import tool provided I need to change the format of a large xml file and convert each entry to a seperate xml file. This is what I have now: <?xml version="1.0" encoding="UTF-8" ?> <dataroot xmlns:od="urn:schemas-microsoft-com:officedata" generated="2005-04-18T12:05:51"> <Checklist> <ID>1</ID> <Category>stuff</Category> <Type>stuff</Type> <Item>stuff</Item> <Steps>stuff</Steps> </Checklist> <Checklist> <ID>2</ID> <Category>stuff</Category> <Type>stuff</Type> <Item>stuff</Item> <Steps>stuff</Steps> </Checklist> <Checklist> <ID>3</ID> <Category>stuff</Category> <Type>stuff</Type> <Item>stuff</Item> <Steps>stuff</Steps> </Checklist> <Checklist> <ID>4</ID> <Category>stuff</Category> <Type>stuff</Type> <Item>stuff</Item> <Steps>stuff</Steps> </Checklist> </dataroot> This is what I need each entry to be as a single file: <?xml version="1.0" ?> <file DocType="TypeName" DocTitle="TITLE:testing 123" DocDesc="TITLE:testing 123"> <section name=...

[ace-announce] ACE/TAO CentOS 6 RPMs available
Hi all, We are pleased to announce that the ACE/TAO CentOS 6 RPMs are available on the OpenSuSE Build service. You can find it online at http://software.opensuse.org/search. Regards, Johnny Willemsen Remedy IT * Checkout the new IDL to C++0x language mapping at http://www.orbzone.org ...

Web resources about - New Ice documentation available - comp.soft-sys.ace

GNU Free Documentation License - Wikipedia, the free encyclopedia
The GNU Free Documentation License ( GNU FDL or simply GFDL ) is a copyleft license for free documentation, designed by the Free Software Foundation ...

Facebook Tweaks Documentation For Developers
Facebook continued its focus on developers with its release Thursday of improved documentation for FQL and the software-development kits for ...

Making Our Documentation Better
Over the past several months, our engineering team has been working on improving the quality of our documentation. Today, we are excited to announce ...

Facebook shares new documentation for local currency pricing, sets migration for Q3
Facebook today provided updates regarding its transition from Credits to local currency pricing. The company offered new documentation for game ...

Emergent Documentation: One way that Agile is very different from Waterfall.
(from a 2012 email) One of the questions I always get around the use of Agile is, how do you do the documentation? Many people are very uncomfortable ...

BIMx Pro - Building Information Model eXplorer for complete project documentations on the App Store on ...
Get BIMx Pro - Building Information Model eXplorer for complete project documentations on the App Store. See screenshots and ratings, and read ...

Documentation in Software Development
There is currently a trend to produce “just enough” documentation in software development. We should however not forgot that what we might estimate ...

The Documentation Dilemma
Back when 37signals was consulting, we gradually weaned ourselves off of documentation. It’s normal practice in the design world to produce lots ...

Apple publishes OS X Mavericks and iOS 7 Core Technologies Overview documentation
A new developer document posted to Apple’s website today details the technologies that power OS X Mavericks. The 36-page document includes information ...

Facebook Releases ThreatExchange API Documentation
... information about malware and other security threats, and the social network announced Friday that the application-programming-interface documentation ...

Resources last updated: 3/23/2016 12:21:59 AM