[XML-DEV Mailing List Archive Home] [By Thread] [By Date] [Recent Entries] [Reply To This Message]

RE: Categories of Web Service messages: data-oriented v

• To: "'Paul Prescod'" <paul@p...>, Michael Brennan <Michael_Brennan@A...>
• Subject: RE: Categories of Web Service messages: data-oriented v
• From: Michael Brennan <Michael_Brennan@A...>
• Date: Thu, 7 Feb 2002 13:41:45 -0800
• Cc: "'Mark Baker'" <distobj@a...>, xml-dev@l...

> From: Paul Prescod [mailto:paul@p...]

<snip/>

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

Sorry. I disagree. The protocol layers are not intrinsically capped. You are
just imposing the perspective of one protocol layer and declaring it as
absolute. HTTP is not the center of the computing universe. I could just as
well argue that TCP is the top level protocol and HTTP is just tunnelling.
Indeed, terms evolve and change their definition over time. Thinking that
you can freeze vocabularies and cast them in stone forever is terribly
naive. Web services have opened up the possibilities of layering new
protocols upon HTTP in rich ways -- and in ways such that these higher level
protocols are not dependent upon whether they are operating over HTTP, or
SMTP, or some other transport (and from the perspective of these layers,
HTTP is transport, not the application layer). The protocols are based on
the correlation of message structures between requests and responses. So
where is the metaphysical law that declares that such a formulation cannot
be considered a protocol? The view you put forth is very narrow and biased,
and it simply denies innovation and the evolution of technologies. I would
argue that your definition of "protocol" is just too narrow to be useful to
web services.
 
> That is not true. SOAP authentication will be an extension of 
> SOAP. 

Oh really? So when I send a PDF document over HTTP, does that mean PDF is
just an extension of HTTP? Some of the arguments that get advanced, here,
really baffle me. Just look at SAML[1], or DSML[2]. These provide SOAP
bindings of their structures, but also allow bindings to other "protocols"
(and, yes, dammit! I am using the word "protocol", here). How would you
argue, then, that SAML or DSML are just SOAP extensions?

It is interesting that on the one hand folks would argue that actions and
data should not be coupled, but on the other hand any modular vocabulary
ever employed within a SOAP envelope must be viewed as just an extension of
SOAP.

<snip/>

> It is provably the case that POST is sufficient for the operation
> because you are doing it.

Bullshit. POST is simply sufficient to get the body of the message to the
application that will process it. Do folks, here, honestly think the its the
web server processing that order? This is really so silly I don't know why
I'm responding to this.
 
> 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"?

Yup. If you hack an HTML form and change it to send up parameters of your
choosing, do you seriously expect that the receiving application can make
use of them? The application serves up a form with specific parameters to
the client, and it expects those paramters -- and no others -- to come back
to it. You want to attach another name to this? Fine. I call it a protocol.
But certainly it is ridiculous to maintain that that data is meaningless and
has no relevance to the interpretation of the message.

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

Are you seriously contending that we now have all of the protocols we will
ever need to do whatever we want in the computing world? We are all done and
can all go home now?

And all those J2EE servers being deployed could be replaced with servers
that simply understand HTTP GET and POST?

<snip/>

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

Please don't start throwing titles at me. Titles don't impress me. I know
too many people who were "visionary CTOs" of high-flying companies that were
going to change the world a short time ago, and are now penniless
ex-employees of companies that went the way of the Dodo bird. I have nothing
against Mark, though, and nothing I am saying should be interpreted as any
personal judgements against anyone in this debate. I am just viewing this as
a rather spirited debate, though I'll confess to some frustration trying to
converse with folks who seem to think that rich distributed systems can be
constructed using purely the semantics of GET and POST. The simple fact is,
that is too constraining.

• Follow-Ups:
  • Re: Categories of Web Service messages: data-oriented v
    • From: Paul Prescod <paul@p...>
  • Re: Categories of Web Service messages: data-oriented v
    • From: Paul Prescod <paul@p...>

• Prev by Date: RE: WSIO and Good is Better
• Next by Date: RE: Categories of Web Service messages: data-oriented vs action-oriented
• Previous by thread: RE: Categories of Web Service messages: data-oriented v
• Next by thread: Re: Categories of Web Service messages: data-oriented v
• Index(es):
  • Date
  • Thread