RE: FW: LC Comments: Web Method Feature (really: REST & SOAP)

Paul,

> Partial understanding is a core component of all 
> interoperable software development. Very seldom do components know
> the full scope of their environments. Rather they know just 
> enough to get their jobs done.

Of course... I don't need a lesson in the basic principles
of building interoperable systems. But you're missing my point --
this is not a case of "partial understanding", this is a case
of a totally different set of uses and purposes. P2S "person-to-
server" vs. S2S "server-to-server" interactions. 

The following section gets to the benefits of reusing the HTTP
network infrastructure for web services. The hopes for reusing
the *network* part of the infrastructure are greatly exaggerated,
although it is true that you can reuse a lot of *software*
infrastructure (i.e. existing HTTP stack implementations, 
trained developers, possibly web server software that can serve
as foundation for writing web services apps).

> If you do not tunnel, you allow HTTP-knowledgable software 
> components to do their job:
> 
>  * Squid can cache based on URIs, method names and cache headers

Ahm, how does caching work for invoices? I have *never* been able
to understand how content-caching helps accelerate dynamic content
such as XML messages which represent transactions traveling across
the network. It is a nice theory, but I contend no one has ever 
used this in production.

>  * Spiders can walk through the resource graph looking for information
> relevant to them

Yes, although it doesn't turn Google into UDDI, you can reuse some
software there.

>  * Service containers can implement recursive deletes of resource
> hierarchies (with WebDAV)

Maybe... would those resources be the purchase orders or the endpoints
that operate on purchase orders? Not sure. Do non-developers do
this or want to do this? 

>  * Load balancers can do balancing based on URIs

No way. Where is the session state? Which streams should be given
higher priority? The load balancer needs to be able to look into 
the XML messages (be they raw messages, or BXXP, or
SOAP or XML-RPC), you've got to be able to process the XML. 

That's why load balancing first became popular, HTTP-parsing 
capability was almost immediately added to them. (Back then it was
considered heresy to create a Layer 2 switch that looked inside 
"layer 7" application data, but in retrospect it makes perfect 
sense).

>  * Resources can be retrieved for basic processing with "wget" and
> replaced with "curl"

Maybe. I can't see customers wanting to do this, but it's probably
more possible.

>  * Internet Explorer can graphically display resource representations
> (probably using <?xml-stylesheet ...?>)

I would expect most interactions to be finer-grained than any
non-developer would want to observe.  

>  * Windows Explorer can graphically allow the browsing, moving,
> deleting, etc. of resources

This is a plus? ;-)

>  * Any resource may refer to any resource, anywhere in the universe
> using only URIs

Yes, URI's are good. 

>  * You can use Apache to help dispatch messages to the appropriate
> resources

Until you need to be able to look at the XML data (e.g. PO's that
have vendorID="x" should go to server Y).

>  * Apache can do "redirects" when resources are moved or merged

You can do that with SOAP, right?

>  * Any resource may incorporate information from any other resource by
> reference using XPointer, XLink, etc.

Most of these don't seem to be getting much traction in the 
field. 

>  * Any resource may be annotated with metadata either through 
> WebDAV or RDF or both.

So can SOAP endpoints, right? Do I need to have method names 
described by RDF? 

> Okay, Squid does not know that the GET means "GET purchase 
> order" but it knows how to cache gets. 

Back to my original point -- may be it can, but I really don't 
want it caching purchase orders!


> annotations mean. Your XSLT engine doesn't know that following a link
> fetches a user's address. 

Mine does, but in all seriousness -- I don't fail to grasp your 
point. Clearly the benefit of layering is that UDP packets don't
have to know about SAP purchase orders.

> Apache knows the semantics of the HTTP specification. Your application
> layer semantics can be expressed *in the data*, not the 
> operation names.

I can talk about Data Oriented Programming (DOP) for hours, I 
bet you won't find a bigger fan of expressing semantics as 
"data" on this list. 

> We are in a big hurry to give up the high level of practical, workable
> interoperability possible with tools that exist today in favour of the
> shibboleth of protocol independence.




\\ Eugene Kuznetsov
\\ eugene@datapower.com
\\ DataPower Technology, Inc.
\\ http://www.datapower.com

Received on Monday, 8 July 2002 17:47:56 UTC