Mark Baker wrote:
>
> > What the Soapy guys are trying to get across is that HTTP 1.1 doesn't provide
> > any specific guidelines or standards at the API level of a typical
> > application.
>
> If that's true, then they're wrong. HTTP defines a very useful API.
> They can argue that for their particular application, that those APIs
> are insufficient. But they can't argue that HTTP doesn't give them
> any application semantics to work with, because that's all it does; it's
> an *APPLICATION* protocol ferchristsakes.
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?
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? 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.)
> > SOAP does. One disconnect is that SOAP would typically use HTTP
> > 1.1, which you are advocating, so it's unclear what you are trying to say in
> > that regard. Another disconnect is that HTTP 1.1 is a raw transport with
> > certain negotiation and commands but no standard determinant way to build
> > specific APIs.
>
> Wrong.
>
> - HTTP is not a transport protocol
It's not? 8-( ) What transport protocol does it use then? Why is it
called "Hyper Text Transfer Protocol"?
> - 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.
> Let's try to explain this a different way;
>
> HTTP says that all components on the Web must implement the RPC
> interface
BTW, many many features are 'may', not 'must'.
> interface HttpWebComponent {
> Stream GET (Headers h);
> Stream POST (Headers h, Stream body);
> etc..
> }
>
> and that the semantics on those methods must behave per HTTP 1.1
> Whereas SOAP-RPC/XML-RPC users promote their own RPC interfaces such as;
>
> interface StockQuote {
> float getDelayedStockQuote( String ticker );
> float getRealtimeStockQuote( String ticker );
> }
>
> interface WeatherReport {
> String getWeather( String city );
> }
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.
>
> 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. 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.
> of APIs; you just use one. Linda was another system that used this
> principle; all spaces implemented the same interface (not unlike HTTP's,
> in fact). Though it didn't get deployed widely (though perhaps more
> widely than many systems of it's time), it was popular. More recently,
> JavaSpaces did the same thing (it was based on Linda).
>
> 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.
> > You do have both kinds of form submission standards (GET and
> > POST) but no complex data type encoding or organization of results.
>
> GET and POST are *not* "form submission standards". They are hypertext
> transfer methods, of which form submission is one example of one markup
> language, HTML. HTTP does not depend on HTML.
Indeed they are, as I used it. 'Form submission' is simply a dictionary; a
name/value list with standard encoding rules. This is baked into both URL's
and the POST body and is completely independant of HTML (excepting possibly
naming restrictions).
> HTTP has its own encoding. As for body encodings, it punts that issue
> except to describe the encoding of the body. "Organization of results"
> is also punted to whatever organization the body wants, which could be
> a MIME container containing multiple parts, or XML, or whatever. I
> think
> that's sufficient.
'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>)
> > On the other hand, SOAP doesn't seem to have a mechanism to reuse the MIME
> > negotiation machinery at the API and sub API level. That's the only point of
> > view where what you are saying makes sense to me.
>
> Curious, because that doesn't make sense to me. 8-O
>
> > > SOAP has (arguable) utility beyond its use for RPC, so I may keep it.
> > > But I'd tell programmers to use the API that HTTP defines, and not
> > > define their own.
> >
> > Unless all you have a API's with a few simple text arguments that return
> > unformatted blobs of text/html, you need something more.
>
> 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. Now we are trying to
move to HTTP+XML smoothly. 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.
> > You can return XML
> > or whatever and interpret it any way you want or return a SOAP style response
> > and have a standard way to find fields, data types, arrays, etc.
> >
> > As I see it, SOAP is just the barest standardized usage of XML but that's good
> > enough to avoid a fair amount of wasted time reinventing that veneer each
> > time.
>
> IMHO, the attempt to proliferate RPC services on the Internet is the
> biggest waste of time here, when the same value can be provided via
> a much more useful, successful, suitable, and already massively deployed
> means.
Detailed expositions of your view would be helpful. All uses of EDI, remote
messaging, remote database, etc.
> MB
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.
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:45 PDT