- From: Andrew Layman <andrewl@microsoft.com>
- Date: Mon, 8 Apr 2002 16:40:48 -0700
- To: <www-ws@w3.org>
Agreed. We should think about the concept, and think about it in terms of what is new and different about the kinds of services that we are building. Rather than looking at the name and trying to _deduce_ what a Web service might be, we should look at the actual Web services that we are building and _induce_ the definition that distinguishes them from other nearby technologies such as RPC/RMI and Web sites. -----Original Message----- From: Toufic Boubez [mailto:boubez@saffrontech.com] Sent: Monday, April 08, 2002 1:06 PM To: www-ws@w3.org Subject: RE: potential users of web services I'm sorry I didn't catch this thread from the beginning, having been away from my office last week and just catching up on my email! Having sort-of "been there at the creation", let me first say that, in my mind, the term "Web Services" is a very unfortunate misnomer, since a definition of a "Web" service doesn't really require the Web. It was just a marketing buzzword that some people who shall remain nameless came up with at the time. In my group at IBM, when we were hammering out the details of UDDI and other Web Services components, it was called Service Oriented Architecture, and I'm sure Andrew Layman can tell us that it was probably also called something else at Microsoft. Having said that, my view of web services is that it's any platform- and implementation-independent software (or even functionality, although you can always wrap functionality such as pizza baking in a software interface!) that can be: * described using an agreed upon or well known description language (for example WSDL is nice but not required) * published to an agreed upon or well known registry (for example UDDI is nice but not required) * discovered through an agreed upon or well known mechanism * invoked over the network through its declared API I usually add "composed with other services" but that's somewhat circular! Now, you'll see that there's no mention of XML, SOAP, etc. These are wonderful and extremely useful standards (the "agreed-upon or well known" part) but nothing prevents an internal (within the firewall) implementation consisting of C programs listening on sockets and sending binary data whose format is well-known and described in the organization to be labeled "Web Services". I realise that this view might differ a bit from the "accepted" view, considering that the "Web Services Architecture Stack" consists of XML and Schema at the bottom of every layered cake, so I might make an exception for XML. But nowhere is it suggested that the other components such as SOAP or UDDI are required. Thoughts?? -- Toufic Toufic I. Boubez, Ph.D. Chief Technology Officer Saffron Technology 1600 Perimeter Park Drive, Suite 300 Morrisville, NC 27560 boubez@saffrontech.com 919-468-8201 Voice (x109) 919-468-8202 Fax "In theory, there is no difference between theory and practice. In practice, there is" -----Original Message----- From: Andrew Layman [mailto:andrewl@microsoft.com] Sent: Monday, April 08, 2002 3:40 PM To: www-ws@w3.org Subject: RE: potential users of web services Private mail to me suggests, and I agree, that the definition could be slightly improved as: A Web service is a computational service, accessible via messages of definite, programming-language-neutral and platform-neutral format, and which has no special presumption that the results of the computation are used primarily for display by a user-agent. -----Original Message----- From: Andrew Layman [mailto:andrewl@microsoft.com] Sent: Monday, April 08, 2002 12:29 PM To: Mark Baker Cc: www-ws@w3.org Subject: RE: potential users of web services I believe that the services you cite fit my definition of Web service quoted below. I could perhaps be more concise: A Web service is a computational service, accessible via messages of definite, language-neutral and platform-neutral format, and which has no special presumption that the results of the computation are used primarily for display on a user-agent. Hope this works for you. -----Original Message----- From: Mark Baker [mailto:distobj@acm.org] Sent: Friday, April 05, 2002 12:03 PM To: Andrew Layman Cc: www-ws@w3.org Subject: Re: potential users of web services On Fri, Apr 05, 2002 at 09:10:46AM -0800, Andrew Layman wrote: > The term Web service was created to contrast with two earlier > technologies. On the one hand, it identifies a distinction from "Web > site" in that a Web site serves pages, typically in HTML, for display in > a browser to a human, while a "Web service" offers a computation > directly to anther computer, with no special expectation that the > computation will be used in a browser or for display to a human. Web > services are not computer-to-human but computer-to-computer. Well, if it's the HTML that you're concerned about, why not return some XML or RDF via HTTP GET? That's machine processable. And any piece of software can invoke HTTP GET on a URI, no human required. What about this? http://www.xmlhack.com/rss10.php It's an RSS feed for xmlhack.com. No "getXmlhackRss()", just "GET /rss10.php". It's also not easily human parseable. I don't know why that's any less a Web service than getStockQuote(). MB -- Mark Baker, Chief Science Officer, Planetfred, Inc. Ottawa, Ontario, CANADA. mbaker@planetfred.com http://www.markbaker.ca http://www.planetfred.com
Received on Monday, 8 April 2002 20:11:15 UTC