Mark Baker wrote:
>
> "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.
That simply amounts to 'I'll lob a blob of data over the wall'. Everyone who
implements with this spec will do something very different unless you develop
standardized semantics.
If you have specific problems with SOAP RPC rather than a particular XML
Schema style, that would be a legitimate argument.
> > 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.
Ok, now you have really lost me. This is the example in the SOAP reference I
have, given:
From: http://static.userland.com/xmlRpcCom/soap/SOAPv11.htm
Example 5 Similar to Example 1 but with a Mandatory Header
POST /StockQuote HTTP/1.1
Host: www.stockquoteserver.com
Content-Type: text/xml; charset="utf-8"
Content-Length: nnnn
SOAPAction: "Some-URI"
<SOAP-ENV:Envelope
xmlns:SOAP-ENV="http://schemas.xmlsoap.org/soap/envelope/"
SOAP-ENV:encodingStyle="http://schemas.xmlsoap.org/soap/encoding/"/>
<SOAP-ENV:Header>
<t:Transaction
xmlns:t="some-URI"
SOAP-ENV:mustUnderstand="1">
5
</t:Transaction>
</SOAP-ENV:Header>
<SOAP-ENV:Body>
<m:GetLastTradePrice xmlns:m="Some-URI">
<symbol>DEF</symbol>
</m:GetLastTradePrice>
</SOAP-ENV:Body>
</SOAP-ENV:Envelope>
We could argue about the SOAPAction:, but it certainly looks like it's using
POST to me. I note that the intent of SOAPAction can be indicated by the
request-URI but that the header tag has to be present to allow filtering of
SOAP altogether.
The only real addition that I see is that the SOAPAction: header and it's
equivalents allow a destination 'object' to be represented without munging the
request-URI. In the example above, the receiving side can just use the
embedded 'xmlns:m="Some-URI"' anyway. At that point, it's just for ease of
logging and filtering.
There are numerous reasons that headers are used now when doing a client
request.
>
> > 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.
Except for available duplex and streaming mode differences, message based
API's are the same as and RPC. Whether you have (messagetype=order, item=bla,
...) or order(item=bla, ...) makes no difference, just syntatic/semantic
sugar.
> > > - 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"
I was being imprecise. In this case, HTTP specifies transport (TCP, it's
normal 'binding') so 'HTTP' denotes '(application) transfer + transport'.
Similarly, SOAP's default 'binding' is HTTP+TCP.
> > > - 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
True, more imprecision; meaning was obvious.
> say that this is a richer API than RPC, though perhaps you were
> comparing
> it with a typical use of RPC.
Only when defining a communication stack pedantically is 'HTTP' an API.
Outside of that view, it's infrastructure for real API's (or other
infrastructure).
> HTTP is growing too. WebDAV adds some methods to the interface to
> provide some additional semantics used for authoring (locking, property
> manipulation,
> collections).
While there may be some elegance to using this as an API through side effects
to updating a value, etc., it's not a direct mapping to the way most
programming is organized. WebDAV seems very focused on authoring situations
rather than a generic meta-API.
> > > 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.
I am totally a meta-data/data driven/small languages nut. I always like to
build tools and infrastructure and as little application-specific code as
possible. Always solve the meta-problem. Still, at some point, application
code has to deal with specific variables, operations, algorithms, etc. You
can't be generic all the way down.
> > > 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.
An xml schema, well documented and associated with other schemas, is the same
thing as a SOAP api definition.
> > > 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.
If there is an argument with the semantics that SOAP expects not always being
appropriate, that could be an interesting argument. I don't like
COM/DCOM/COM+ that much.
> > > 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.
Defining the XML payload is still a big job right now when it's wide open.
> > 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.
But defines almost none of the details.
> > 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
A good requirements starting point. Some good ideas, several bad ones.
If you are proposing an alternative to SOAP using existing technology, it
should be simple to illustrate a strawman example we can beat on.
I certainly question some parts of SOAP, but the general direction looks
reasonable at this point. The idea of standard schemas WITH standard
encodings makes sense and SOAP seems to add to this.
> > 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
I've looked at WBXML which this is a derivative of. Nice, but weak even on
the compression front that it concentrates on. It doesn't have several
characteristics that I want even for compression. It doesn't address the main
speed problem which is the central focus of what I'm doing. I'll also have
both a SAX and DOM interface, although A) DOM is more appropriate and B) DOM
has mistakes which I'll have to fix while allowing old interfaces. (The main
mistake was requiring new elements to be created and then linked into the
tree.)
> MB
sdw
-- sdw@lig.net sdw@insta.com swilliams@Jabber.com Stephen D. Williams Insta, Inc./Jabber.Com, Inc./CCI http://sdw.st 43392 Wayside Cir,Ashburn,VA 20147-4622 703-724-0118W 703-995-0407Fax Dec2000
This archive was generated by hypermail 2b29 : Fri Apr 27 2001 - 23:17:49 PDT