Re: Representing HTTP in arch diagrams

On Thu, Sep 19, 2002 at 03:30:22PM -0600, Champion, Mike wrote:
> The "conventional wisdom" would go something like this:  In the
> human-readable Web, interaction is done by typing in URLs or clicking on
> hyperlinks, discovery is done by reading the text associated with hyperlinks
> or using a search engine, and publication is done "by hand" with HTTP
> PUT/POST, FTP, or whatever.

Ok.

>    For the machine-processable Web, discovery
> and description are more problematic -- one needs to either hard-code the
> actual URLs, or code up the rules for building specific requests into a URI
> and some way of determining the server to send HTTP request to.

Hmm, I don't see it that way at all.

For humans, you click on a link because you're told what type the URI is.
So I click on "Sports" on Yahoo.com because Yahoo asserts;

<a href="http://www.yahoo.com/r/ys">Sports</a>

and I know what "Sports" means.

A machine can work similarly.  Take the little-known anchor AII "rel",
which is used to declare the type of link between the current resource,
and the resource identified by the href value.  If Yahoo had written;

<a rel="http://terms.example.org/activities/athletic/sports/"
   href="http://www.yahoo.com/r/ys">Sports</a>

then a machine that recognized that URI as identifying the notion of
"sports" could follow the link, if that's what it was looking for.  Of
course, any app can follow any link, but it's a waste to get stuff you
don't need over a network; hence the value in declaring the type
alongside the link.

>  Thus, SOAP
> was devised as a standardized and programmer-friendly way to do the
> interaction, WSDL was devised as a way to rigorously describe the format of
> SOAP requests and responses, and various discovery mechanisms are being
> devised to make it possible to find WSDL descriptions.  Furthermore, SOAP
> has become protocol independent, so HTTP is not necessarily a part of the
> interaction.
>
> So, how do you suggest we "draw" HTTP into the picture?  (Especially
> considering that it is not strictly speaking necessary in the SOAP/WSDL
> world?)

Well, that's part of the problem.  HTTP *is* necessary for most apps.
Being protocol independant is fine, and I agree it's a useful part of
SOAP (though *way* over-rated), but for different reasons than Web
services folks think.

Anyhow, like I said, I'm happy not to dwell on this; HTTP can stay out,
for now.  <grits-teeth/> Let's just focus on documenting the
architecture of SOAP+WSDL.

> I like the idea of explaining how  SOAP/WSDL evolved to address the
> challenges that people had trying to automate Web-style interactions without
> a human in the loop.  One can do things with HTTP alone, of course  --a
> point you might have made once or twice :-) -- but then how does description
> and discovery work?

Description and discovery works the same way with or without humans in
the loop, as I attempted to describe above.

>  I'm just asserting that this is generally done with
> application-level code rather than declarative languages such as WSDL in a
> RESTful application.  Do you disagree?  

"generally done", for Web services apps, yes, I agree.

> Anyway, that's what I meant by "hard coded": URIs are generated by
> application code rather than SOAP messages generated from a declarative
> description.  Maybe that's not helpful, since of course one could infer the
> URIs from RDF metadata or whatever, and the declarative/procedural issue is
> orthogonal to all this.  But as a practical matter in today's technology, I
> do think that WSDL evolved to help people avoid the hassles of "hard coding"
> URI generation logic.

Perhaps, but likely because they didn't consider how to use forms
in a machine processable environment.

MB
-- 
Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com

Received on Thursday, 19 September 2002 21:19:05 UTC