Re: [Highly OT] Webservices are NOT distributed objects

Thanks Steve for your thoughtful response.

XML parsers and SOAP stacks are readily available in all popular
compiled and scripting languages, and it's typically dead easy to
combine them into existing applications. Generally, for most
developers, it's easier, both conceptually and code-wise, to use a web
service than it is to use a CORBA object.

Of course CORBA is also available by default in some of the more popular programming toolkits
like Sun's JDK 1.4 and in scripting languages like Tcl (Frank's Combat) and Python (Omniorb and others).
It's nearly trivial to write a CORBA client or server with an approach like Frank implemented in Tcl.
(He does all the interface definition lookup dynamically and caches the results for higher efficiency. There
are no stubs or skeletons.) It's also fairly easy to write one in Java as well, although I'd like to create a Dynamic
Proxy layer some day that didn't require stubs or skeletons.

If you're doing simple stateless, RPC type operations with mostly text data
the current SOAP/HTTP Web Services approach isn't too bad although I feel
it is still a little messy.  If you want to do anything fancier using callbacks,
binary objects, wizard-like interfaces (application choreographies)
or type safe method calls then I think CORBA is much cleaner.

BTW, I do not equate Web Services with SOAP.
  

Are you defining Web Services then as just XML documents with interfaces and types
defined by WSDL Schemas?

I guess I've never been convinced by the "that solution offers more
capability than I need, so I'm going to write a simpler one myself
or use this other simpler less-capable solution" argument. Why not
start off with something that offers more capability than one needs
and grow into it? (I'm talking about core capability not all the other
CORBA services features.)
    

This makes no sense from an engineering perspective. Why deal with
complexity that you're not sure you need?
  

Every solution starts off simple and grows in complexity; that's the nature of software
.
I don't know how many times I've seen  developers invent a new simple language because the existing
languages offered more capability than they needed at that point of time. Eventually the developer finds
that they actually need some of those silly features like switches, while loops,
objects and methods, .... shared memory :-) and their simple language eventually grows into
something far from simple and hard to maintain..

I've seen the same thing happen with communication protocols. The developer says I don't want
to learn that beast of a protocol so I'll just invent a new comma or "|" delimited or name=value protocol 
using raw sockets. Well, you can see what eventually happens; they find that they need to reference services, send binary data,
embed data with "," or "|",  manage socket connections, handle callbacks and all the things that were already built into
carefully thought out, more-general systems like CORBA or RMI.  (There are also the longer term issues
of scalability and end-user response time under high server loads.)

I see the same type of evolution happening with Web Services and I just find it kind of
frustrating that's all, especially when it's actually a subset of other more mature approaches.

For example, even though ICE isn't CORBA interoperable, 
at least it demonstrates a terrific improvement in capability, 
performance, and ease of use based on lessons learned from CORBA. 
    

Yes, but for what purpose? It might be nice technology, but
market-wise, and with no offense or insult whatsoever intended to my
ICE friends, ICE has no legs.

Well they've made actual progress, rather than a regressing in many ways like the current
incarnation of Web Services has.

I believe you're talking about SOAP, not Web Services.

There was an interesting paper presented in my Web Services track at
the WWW2003 conference back in May. Chris Kohlhoff and Robert Steele
measured payloads for real-world document-oriented systems and found
that the disparity between SOAP and IIOP under those conditions was
not as great as people think.

<http://www2003.org/cdrom/papers/alternate/P872/p872-kohlhoff.html>

But they're using raw sockets when sending the SOAP messages, not HTTP are they?
It doesn't seem like a fair comparison. IIOP doesn't have the continuous reconnection costs that a
stateless protocol like HTTP has. The current incarnation of Web Services is SOAP over
HTTP so wouldn't benchmarks using the correct protocols be more meaningful?

Also, they do admit that for engineering data that SOAP is very poor while
for mostly-text business-type messages it's not bad when compared to CDR.
(As expected since a character is a byte in binary or ASCII unless you're talking unicode.).
Why not just use a protocol that will handle all situations without being hamstrung
by a poor decision up front when your  requirements change?
As you know, with a protocol like IIOP/CDR you can send XML documents if you'd like
as strings  or sequences of structs but you can also send any other type-safe
complex binary message type. I only have to learn one approach then rather than
two diverging ones. (I do think that XML is a great format for defining  configuration files,
complex text documents or GUI layouts and such, but it doesn't handle all data types in general,
at least very efficiently.)

One thing I detest is self-appointed experts sitting around in
newsgroups or mailing lists arguing about performance issues based
entirely on hypothetical situations that never arise in the real
world, as so often happens right here in comp.object.corba. That's one
reason I found this paper to be a breath of fresh air.
  

I  don't think that just because somebody makes an observation based on their background
and experiences necessarily implies that they think of themself as an "uberexpert". (I surely don't.)
I think it's good thing  that we're not all sheep driven by popular trends.
I think the data is there to justify the concerns, but I have yet to really see a comprehensive
end-to-end performance comparison of a complete SOAP/HTTP based system compared
to a CDR/IIOP one.  I've done simple tests and found about a 10 to 1 difference just for a simple ping.
(The time to connect dominates in this case.)

Some do. I know architects at a large telecommunications company, for

example, that do exactly this. But generally, it's not so simple.
Using XML implies documents, and CORBA is generally overkill for
document-oriented systems. See the Kohlhoff/Steele paper cited above,
for example. I know of a large Boston financial firm, for example,
that has thrown out almost all of its middleware and replaced it all
with XML-based messaging. They did this three years ago, and they've
never been happier.

What are the reasons that they are so happy? How are the XML messages being transferred?

Perhaps the ICE bindings could be used as a
starting
point? Maybe there needs to be a lighter weight, more inclusive
process
for future CORBA improvements like Sun's JSR mechanism for instance?
    

JSR == lightweight? That's a joke, right?

I actually didn't mean it as a joke really. Although it is a formal process, it appears that many improvements led
by a given third-party advocate and a small team actually do make their way into the toolkits after awhile.
Progress seems to be made continuously.  Some features like parameterized types have taken much too long get
integrated, but others sped along pretty quickly. I think it's a nice compromise between the Bazaar and Cathedral
models....at least from the outside looking in.

I agree that getting changes into CORBA is difficult. Few people try
anymore. But I don't think that's unusual for a mature standard.
  

CORBA might not need many new features (a practical firewall solution would be nice),
but maybe just some refactoring of old ones? Is it really necessary to dump the whole thing?

JMHO,

Rob