 |
AppletTalk.com
Java discussions newsgroups
|
| View previous topic :: View next topic |
| Author |
Message |
Gerald Brose
Guest
|
 Posted: Fri Aug 15, 2003 8:30 am Post subject: SOAP vs RPC (CORBA, Ice...), was: Re: New Ice documentation |
 |
|
Michi Henning wrote:
| Quote: | "Gerald Brose" <gerald.brose (AT) xtradyne (DOT) 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 messaging over binary RPCs. I will
say again where I believe these are apparent, prominently
in document-style message exchanges.
- I am not saying that SOAP and its genesis represent the holy
grail of protocol engineering. If technical excellence was
always required for success, we would not even have HTTP.
(This would be a good place to start language wars, BTW.)
But even you are using HTTP, aren't you  . Thus, there is no
moral obligation to dismiss SOAP just because we don't like
how it came about and not use it where it has advantages.
| Quote: | 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?
|
No, as much as that does not rule out HTTP for browsing or SMTP
for sending emails. You know very well that the world is not
just RPCs :-)
| Quote: | 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.
|
Agreed.
| Quote: | I'm afraid that is still not good enough to make me accept
the horrendous blow-out in bandwidth.
|
If bandwidth is the main concern, you can always zip your XML
messages. There are tools that provide very good XML compression
rates. Again, the point is that you make different trade-offs for
different situations.
| Quote: | 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.
|
Not exactly, there are a few things here and there that differ
considerably, such as the ability to specific separate service endpoints
for different services. WSDL = IDL + IOR . No, seriously, WSDL has
interesting features, and it now uses prior art as well. No need for sarcasm.
| Quote: | 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.
|
Now we are coming closer to loose coupling...
| Quote: | 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.
|
Right, it seems this is the point where we have been missing
each other.
| Quote: | 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).
|
It is often overlooked that SOAP is actually independent of the
transport and the encoding used to transmit messages. SOAP is not
layer four. There is nothing that stops you from using CDR encoding
and GIOP messages instead of the HTTP POSTs that we are seing today.
(With all the firewall problems that gets you in, etc.) To me, this
just shows that people wanted something out the door quickly.
| Quote: | 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?
|
As I just said, they are not at the transport layer. These models
have to built, sure, but you can set individual business models up
more quickly between two companies than with a central committee,
that's all.
| Quote: | 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.
|
Absolutely. But a) there is more structure in an XML instance document
than in an IIOP message, and b) it is much simpler to attach "meaning" by
way of agreeing on XML schemas and vocabularies for those tags. The
Semantic Web, altough using terminology that evokes some unpleasant
resemblances with AI speak, is providing languages that support you in
doing just that - defining meaning.
Perhaps this is carrying us a little too far, but note that the
closest we ever got there with CORBA was the service types in
the ODP (later CORBA) trader - which is to say it never actually
happened! The main difference with the newer XML approaches is not
magic, but simply decentralization from the beginning. Rather than
assuming a global type system.
| Quote: | 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.)
|
Absolutely.
| Quote: | 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 almost suspected that much when typing the term, but I could
not help it :-)
| Quote: | Back then, I argued that "loose coupling" is a very slippery term.
|
Right, with tons of meanings heaped up by different people in
different circumstances. Then add some marketing hype...
| Quote: | 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.
|
That is the part that is due to XML. In the Web Services context people
usually also imply decoupling through asynchronous messages, which of
course is not a new concept itself. Noone claims that. (I can only invite
you to look at WSDL 1.2 for the different message interaction patterns,
quite interesting.)
| Quote: | 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.
|
Right, a better example is a form processing application that does
not need to change just because you added a new entry somewhere up
there and a footnote somplace else. Sure, if the semantics of the
whole thing changes, all parties involved in the application must
make sure they still agree that what they still makes sense. I
fail to see that I (or someone else) claimed differently.
| Quote: | 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.
|
Such as the ones used to define the semantics of RPCs in the first
place? Those of us who spent long enough in academia know they
exist, but all of us in industry know they don't matter in practice.
Who has bothered to read through the formal models defined for OO
languages? Which programming language actually comes with these?
Unfortunately, those models are always created after the fact, and
they help to detect flaws, but I dare few people care for a mathematical
definition of "loose coupling". (To begin with, that would presuppose
a precise taxonomy of "coupling". I can propose a few rough aspects
here as a start in case anybody is interested (e.g., spatial, temporal,
syntactic, semantic), but that should perhaps go to a new thread.)
| Quote: | 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.
|
No argument here. Just that this makes RPC sub-optimal for some
applications.
| Quote: | 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?
|
Oh yes, 100%. The gateway simply "proxifies" IORs on the
fly so that any IOR that passes will later point to the gateway.
That works with all ORBs we have tested, including all major
commercial and Open Source ones.
| Quote: | 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?
|
I dare say that the "Web Services Security" (WS-S) specification under
development now at OASIS will provide a practically useful message
security model that goes way beyond anything we had in terms of
interoperability. And there is consensus about it, so you will see
wide acceptance and deployment.
| Quote: | 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!
|
Michi, *everybody* sees that, people are not that dumb. That's why
there is such a strong consensus on WS-S. To me, this is a good
thing: people are finally worried enough to move!! And they do.
| Quote: | 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."
|
Sadly, few vendors at the OMG were bothered enough to see to it
that security found its way, so while we could have done it, it
simply never happened. With SOAP, the urge is so strong that finally
there is engineering time spent on security.
| Quote: | That is naive in the extreme, and upsetting to security experts for good
reason.
|
Well, it should be upsetting them. I was worried when SOAP
came out, too.
| Quote: | People like Cheswick don't trash something like SOAP for the
fun of it.
|
Come on, if your old firewall does not get it, that means you need
a better one. Cheswick said these things about SOAP when it first
appeared, and there was broad agreement that this will require
new security technology. Does that make a technology bad? (Please
also consider that there more security experts than just your
favorite two, and a good number of reknowned experts (both in
academia and industry) are contributing to the new XML
security standards.)
Finally, it is not as if the same problems with application level
security did not exist before SOAP. The belief that "security
equals (packet filter) firewalls" is childish, to say the least.
| Quote: | 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?
|
Yes, because security additions have come out in the meantime.
| Quote: | 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?
|
Because problems can be solved as soon as you acknowledge and
understand them. That is what is happening.
| Quote: | What is missing is a ubiquitous secure infrastructure that is built into
the transport substrate. IPv6 made a very good stab at that.
|
As you know, all that we have widely deployed at the transport level
is SSL, und fortunately that works somehow.
| Quote: | All the fundamental prerequisites for platform-based and ubiquitous security
are there. With strong encryption, man-in-the-middle or replay attacks
are impossible.
|
That is a widely-held belief. Unfortunately, there are so many
assumptions in it that one should perhaps better not believe
that at all. It requires:
a) _perfect_ cryptography (not only strong)
b) physically secure devices
c) secure key distribution and credentials management
d) strong passwords (on key files) or secure key storage
e) educated users and developers = proper use of encryption
f) conscientious users = cooperation
g) good policy management
f) ....
In practice, security is always a compromise between cost and
assurance.
| Quote: | 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.
|
100% agreement here, this is actually Xtradyne's mission and the
reason why we build security gateways rather than libraries and
APIs.
| Quote: | 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.
|
Right.
| Quote: | 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.
|
I agree that SOAP over HTTP is not brilliant, but as I said above,
you can use other transports (in theory).
| Quote: | 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.
|
No, but it makes it more likely :-)
Cheers, Gerald.
--
Dr. Gerald Brose mailto:brose (AT) xtradyne (DOT) 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
|
|
| Back to top |
|
 |
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
FAQ
Search
Memberlist
Usergroups
Register
Profile
Log in to check your private messages
Log in
