From: Mark Baker (distobj@acm.org)
Date: Tue Jan 02 2001 - 14:48:28 PST
"Stephen D. Williams" wrote:
> Ok, could you explain to me where the standards are for submission of a
> purchase request (a typical application) for pizza or a book, for example?
RFC 2616, section 9.5 (POST), combined with some sort of purchase-order
schema.
> Say I want to write a program to submit RFQs and orders to the book company of
> your choice, Fatbrain, Amazon, and BarnesandNoble, from a standard list (from
> our recommended books for example). I want to use a published standard. With
> XMLRPC/SOAP/Whatever, I could use a published DTD/Schema for ordering
> books/pizzas.
>
> What would I use with HTTP?
The same, except you'd submit it with POST rather than with
nameYourOwnMethod.
> Without writing an application that tries to
> emulate the webpage form processing, which is expected to change without
> notice and may prevent automation purposefully, how exactly would I start this
> programming project?
>
> I don't necessarily think that SOAP is the be all, end all solution, the idea
> of using XML for RPC/EDI (in the general sense, not just the brain-damaged
> 80's DCE/Corba style), makes a lot of sense for actually making 'automation',
> i.e. extranet processing, work.
>
> One argument might be that you shouldn't make RPC calls, you should send
> messages. That in fact is how I look at things. SOAP 'calls' are pretty much
> the same thing as they are just an XML document. (If anyone sees a major
> disconnect here, let me know.)
Messaging interfaces are typically generic. They typically include some
sort of input & output semantics. Applications receive messages through
this interface, not through any application-specific interface.
> > - HTTP is not a transport protocol
>
> It's not? 8-( ) What transport protocol does it use then?
TCP
> Why is it
> called "Hyper Text Transfer Protocol"?
Is that a trick question? 8-) "transfer" != "transport"
> > - HTTP already defines an API; GET/POST/PUT/HEAD/etc..
>
> It defines a more minimal API than does SOAP/XMLRPC. Something will come
> along that is more sophisticated than SOAP, and/or SOAP will grow.
RPC defines no API. It defines a convention for defining APIs. I would
say that this is a richer API than RPC, though perhaps you were
comparing
it with a typical use of RPC.
HTTP is growing too. WebDAV adds some methods to the interface to
provide some additional semantics used for authoring (locking, property
manipulation,
collections).
> > HTTP says that all components on the Web must implement the RPC
> > interface
>
> BTW, many many features are 'may', not 'must'.
Right. Luckily OPTIONS, status code 405, and the Allow response header
handles that situation.
> The SOAP level of detail is needed on top of your examples above. While some
> kind of middleware could be blissfully unaware of the details, actually
> programs need to know that in 'Headers h' is "first=Mark&Last=Baker", etc.
Yes they do. But this doesn't have to be part of the interface.
Requiring it to be sacrifices genericity.
> > The difference is an architectural principle sometimes referred to as
> > interface genericity. Yes, you lose some control this way, e.g.
> > interactions are relatively coarse grained. But you gain too. For
> > example, composition becomes a lot easier as later forms of binding can
> > occur between components, and components can be substituted for one
> > another. You also don't have to worry about standardizing on gazillions
>
> At one level, this is the idea behind using XML.
Exactly right.
> At some level you need to
> get specific work done. XML (and SOAP, etc. above that) standardize on design
> choices and allow you to publish application details more succinctly by
> allowing more and more of the processing to be generic.
Not sure I follow.
> > In case it isn't clear, the interfaces listed above are *not*
> > complementary; they are competitive. "HttpWebComponent" is a sufficient
> > expressively interface (when combined with the method semantics defined
> > in HTTP 1.1) to implement many *many* different types of applications.
>
> But only with the semantically equivalent encoding that's indicated in the
> SOAP example.
Not sure what you mean, but my statement stands unconditionally. The
interfaces compete. With HttpWebComponent, I can do everything that can
be done with those other interfaces.
> 'or XML'.... This is exactly what SOAP is trying to solve: generisizing the
> result with the modern equivalent of the 'form submission' dictionary
> encoding. Sure there are other ways. We could, for instance, just use the
> dictionary method with hierarchical names:
> "employees.emp1.first=Mark&employees.emp1.last=Baker"... Most of us like the
> XML equivalent better. (I mentioned this equivalency on a project once and
> others started implementing it... <sigh>)
Yes, I know some people want to go further. I personally don't think
it's necessary, but it's a small enough thing that I can deal with it.
Certainly with the envelope structure SOAP requires in order to realize
its raison d'etre (namely, actor and mustUnderstand), an encoding is
required.
> > There's another reference to HTML. HTTP does not depend on HTML.
>
> It does from the point of view of generic, standardized interfaces. The most
> standard data payload now is HTML hence they are linked.
Well, ok, but that meaning of "linked" is irrelevant to this discussion.
My point is that HTTP has no dependance on any HTML feature and is
therefore suitable (and moreover, was designed) for transfering more
content types than just HTML.
> Now we are trying to
> move to HTTP+XML smoothly.
This isn't the first time I've heard this statement. HTTP can handle
XML just fine, thank you very much. I agree that we should look for
ways to better integrate the larger XML picture with HTTP, such as the
work done on draft-murata-xml, but XML-as-HTTP-payload is pretty darned
powerful as-is without any further agreement required.
> XML obviously makes sense as a return stream; one
> question is whether 'form submission' should be replaced by a request stream.
> SOAP wisely generisizes this further: there is no per se return stream
> (although there is in practice), all streams are 'sent' possibly
> asynchronously. Once this decision was made, pipelining and asynchrony were
> possible (big improvement on 80's style RPC) but dictionary interface requests
> were not.
SOAP did nothing special here. HTTP does all the work.
> Detailed expositions of your view would be helpful. All uses of EDI, remote
> messaging, remote database, etc.
The best I can do in a pinch is Roy's paper;
http://www.ics.uci.edu/~cblake/Hyperware/Fielding1.pdf
> PS: I didn't get to participate in SOAP (being swallowed by IMPP efforts),
> however it's reasonable in most ways. It's missing some features I hold dear,
> but I'll suggest those when my binary structured XML standard is ready to
> unleash (i.e. when I get time to get my code working). BTW, among other
> advantages, my bsXML will make XML blindingly fast, probably faster than most
> other message handling methods. Speed is the complaint I've read repeatedly
> when describing XML efforts.
Have you seen Millau? http://www9.org/w9cdrom/154/154.html
MB
This archive was generated by hypermail 2b29 : Tue Jan 02 2001 - 14:47:00 PST