W3C home > Mailing lists > Public > www-ws-arch@w3.org > June 2002

Re: S600: Comments on the Web Services Architecture Usage Scenari o s document (was Re: New draft of the Web Services Architecture Usage S cen arios document)

From: Mark Baker <distobj@acm.org>
Date: Fri, 21 Jun 2002 13:27:47 -0400
To: "Damodaran, Suresh" <Suresh_Damodaran@stercomm.com>
Cc: www-ws-arch@w3.org
Message-ID: <20020621132747.G31108@www.markbaker.ca>

On Fri, Jun 21, 2002 at 10:19:50AM -0500, Damodaran, Suresh wrote:
> Hi Mark,
> You really got me here, I thought I put a smiley at the end:-)
> I am not quite ready to talk about it in detail.
> Well, here are some uncooked general thoughts on "address based" discovery 
> (along the lines of "Zero protocol"):
> 	1. Given a URL, make it possible to discover other URLs, i.e.,
> 		Support URL1 -> URL2, URL3, ..., where
> 		 -> is a mapping defined and implemented for the purpose of
> reliability, or for identifying the right URL for the accessor, etc. You
> might say, apart from HTTP none of the other protocols define any such
> mapping. Well, just give some time, then.
> 	2. The URL is an access point, and now go over to the higher layer:
> Service layer.
> 	(I know you have some philosophical differences here, but let us not
> get lost in weeds)
> 	Given a service description, provide a mapping from a service
> description to one or more service implementations 	
> 	- here is where SOAP based discovery comes in picture for
> reliability, finding the right 	actions are available, etc. Essentially a
> "service reflection mechanism" and ways to 	describe and communicate it.

Well, you've got me here, because I don't know what you're talking
about! 8-O  I guess you meant it when you said "uncooked"! 8-)

FWIW, what I was getting at was that HTTP is special amoungst
application protocols, because it is the only one that has any notion of
a URI, and therefore any notion of discoverability in all contexts.  FTP
existed long before URIs, and before URIs became common place there was
no way to identify a FTP resource; you had to write it down like
"FTP site; garbo.uwasa.fi, /pub/software".

So URIs are great, because they make previously universally
undiscoverable resources, universally discoverable.  And HTTP GET is
just as great, because it can be used to resolve all of these things.
So "restricting" yourself to GET isn't actually a restriction (though
I'd agree that we could separate the semantic from the protocol, so
that other Web architecture friendly application protocols, whenever
anybody builds one, are supported).

Mark Baker, CTO, Idokorro Mobile (formerly Planetfred)
Ottawa, Ontario, CANADA.               distobj@acm.org
http://www.markbaker.ca        http://www.idokorro.com
Received on Friday, 21 June 2002 13:17:33 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:05:34 UTC