- From: Mark Baker <distobj@acm.org>
- Date: Sat, 2 Mar 2002 22:48:06 -0500 (EST)
- To: Dietmar.Gaertner@softwareag.com (Gaertner, Dietmar)
- Cc: jasnell@us.ibm.com ('jasnell@us.ibm.com'), www-ws-arch@w3.org ('www-ws-arch@w3.org')
Hi Dietmar, > Take for example the stockquote "service", which we all know and love > returning, a plain > HTML page. It can be implemented as an application or component, identified > by an URI > (e.g. http://www.stockquote.org/quotes?symbol=xzy), can be described (the > URI is enough > of a description, if you wish), can be accessed by software via > internet-based protocols, and > the interaction does not necessarily require human interaction (the client > could scrape the HTML). > I could describe a similar scenario with an FTP site providing some files > with stock quotes. > > I guess this is *not* what we would like to capture with a definition for > web services! Why not? The service you describe gets you the stock quote, does it with URIs and standard protocols, and with some information (scraping info) which permits the automated extraction of the quote. Certainly Web services go beyond this model, but I see no reason to exclude existing services, such as those (like your example) available over HTTP GET, from our Web services definition. > I suggest to narrow down the scope and define an architecture for the type > of services which > we (informally) have in mind and then it will be possible to define what a > service is relative > to this architecture. What do you believe we have in mind? Perhaps we can extract something from that to incorporate into the definition. MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@planetfred.com http://www.markbaker.ca http://www.planetfred.com
Received on Saturday, 2 March 2002 22:44:20 UTC