[
Lists Home |
Date Index |
Thread Index
]
Michael Brennan wrote:
>
>...
>
> This is completely meaningless. You are insisting there are no such things
> are a protocol except that at the transport layer.
Mark's argument is that there is a priviledged layer in the stack of
protocols called the "application protocol." The application protocol
is, by definition, the top layer. If you use a protocol designed to be
an application protocol as a "transport" then you are tunnelling (as
XML-RPC does). If you add new "ideas" to an application protocol (as
WebDAV and Delta-V do) then you are extending the protocol.
The fundamental difference is whether you are using the protocol's
elements according to the semantics defined in the specification or
trying your best to ignore them. As an analogy, I could encode purchase
orders in HTML:
<html class="purchase-order">
<p class="purchase-item">
<emph class="xsd:integer">
...
</html>
Tunnelling over HTTP is very similar. For instance XML-RPC (and
traditional uses of SOAP-RPC) use POST to do an information GET. At that
point you have to ask yourself a couple of questions:
1. What benefit am I really getting from stacking multiple layers of
protocols on top of each other?
2. What cost in infrastructure and performance am I paying? Is it
really a good thing, for example, that I've essentially disabled caching
and method-based firewalling?
> ... That is patently
> ridiculous. The whole SOAP model is based on protocol layers. When there is
> a standard way of representing authentication and authorization info in a
> SOAP header, that will be part of a protocol.
That is not true. SOAP authentication will be an extension of SOAP. SOAP
routing is an extension of SOAP. SOAP attachments are extensions of
SOAP. You can know that they are not "layers" because you can mix and
match them in a single message. None of them are on top of the others.
And even if they were layers, they would be layers of extensions, not
layers of new protocols because they would merely build upon whatever
semantics are built into SOAP itself.
> ... There is no reason why you
> cannot layer protocol upon protocol and let the higher level protocols
> remain blissfully ignorant of the lower level protocols. Insisting that
> these higher level protocols cannot be true protocols is really a rather
> narrow and needlessly constraining notion.
If they integrate and extend the semantics of SOAP, then they are
extensions to it. If they are "blissfully ignorant" of SOAP then they
are tunnelling over it. Once again, if they are tunnelling then what
benefit would they get from SOAP?
> > You can buy CDs with an HTML form using HTTP POST without the word
> > "purchase" or "buy" needing to be part of the message. In other
> > words, POST suffices as an intent for that operation. Why do you
> > think that is?
>
> Again, meaningless. POST does *not* suffice for that operation. If I use
> such a form, I am not interested in POSTing data to a server. I am
> interested in buying something.
It is provably the case that POST is sufficient for the operation
because you are doing it.
Mark is being somewhat cryptic but at the same time being mathematically
clear. All over the Web people do e-commerce without embedding method
names in their HTTP bodies because you can always, not sometimes, but
*always* figure out "what to do" based on the combination of the HTTP
method and the URI. A web service modelled around URIs will have the
same virtue that you never need to put the method name in the message
body.
> ... And there better be something on that form
> that tells me what it is going to do.
HTTP method + URI.
> ... Whether it is the word "purchase" or
> "buy" is secondary, as long as there is something there I can understand.
> And by the way, that form probably does not just have one action verb
> associated with it. It will have one or more "buy this item" actions, a "use
> this credit card" action, and a "ship to this address" action, among others.
> Just because the HTTP server thinks that all that is going on is a POST
> action, doesn't mean that there aren't very relevant actions happening,
> here, at a higher layer.
Yes, at a higher layer. But are you really going to claim that every
e-commerce site that uses POST is inventing its own "protocol"? Surely
not. And yet we can do incredibly sophisticated things with the
combination of HTTP method + URI.
If you would like to see an example of this process, I refer you to my
recently published article on xml.com:
* http://www.xml.com/pub/a/2002/02/06/rest.html
> ... Surely, this is not a difficult concept to
> understand. I don't believe in a glass ceiling for protocol layers. You can
> keep piling them on until you get to a rich enough model to solve the
> problem at hand.
You can keep piling them on but what is the benefit and what is the
cost? If you can do everything you want with a fixed number of protocols
+ extensions, why would you want to build N layers? Among other
problems, these layers strip efficiency without adding expressivity.
Lose/lose.
>...
> We've been doing this for a few years, now. And I have to say, that although
> most of our implementations are not using the latest and greatest (typically
> just XML 1.0, no namespaces, no SOAP), they are doing things far more
> sophisticated than many of the visions for web services I hear expressed can
> support. The model you propose could not possibly support the sorts of use
> cases that we are routinely supporting for our customers.
That's provably not the case. It's like saying that some programming
language could not factor numbers.
>...
> It is not up to the problems to adapt to some idealized theoretical notion
> of the right solution.
Mark asked you how your problem is solved on the Web. He didn't say that
your problems were not important. His point is that we already know how
to do things and we just have to UNDERSTAND that we already know it,
rather than inventing new things that we do NOT understand as well.
> ... It is for the solution to prove that it can solve the
> real world problems. If it cannot, it is not the problems that are wrong.
You should know that Mark is Chief Scientist of a company that works (as
far as I can tell) almost exclusively with protocols. I believe that his
last company did, also, before it was sold to sun.
Paul Prescod
|
