- From: Eric Newcomer <eric.newcomer@iona.com>
- Date: Sat, 23 Feb 2002 10:29:56 -0800
- To: "Tom Bradford" <tom@xqrl.com>, "Champion, Mike" <Mike.Champion@softwareag-usa.com>
- Cc: <www-ws-arch@w3.org>
One of the things I've struggled with over the past 6-12 months is the definition of a Web service. I can see that this group also supports multiple definitions. Some say that a Web service uses SOAP, WSDL, and UDDI. But clearly UDDI is not required, and WSDL is not always used. So it would seem use of SOAP is a minimum criterion. This group's first goal might well be to settle on a definition of Web service, since the industry hasn't really settled on one. In any case, that would be a good, immediate contribution -- assuming, of course, we can get agreement on it ;-). Some of the difficulty is historical. SOAP was created before WSDL, as was UDDI. Early UDDI definitions of Web service were broad enough to include any XML protocol, such as RosettaNet, xCBL, cXML, fpML, UCCnet, etc. Another good question is whether ebXML is a Web service -- some definitions do include it. The development of ebXML paralleled Web services, and there's considerable overlap, as well as considerable difference. Fundamentally, we need to be forward-looking about this and come up with a definition that fits the goals of the architecture more than applies to history or the current state of affairs. I think we can all agree that a Web services architecture includes more than the core technologies, even if we can't all agree precisely on the definition of those core technologies. But it would seem inevitable that SOAP, WSDL, and UDDI -- perhaps more correctly the services and functionality they represent -- have a place in the scheme of things. Also I would go out on a limb to say that everyone agrees security is fundamental to the architecture, and probably management services. And some kind of orchestration or choreography service for establishing relationships among Web services (whatever they are ;-). On the subject of transactions, I'm not convinced (despite BTP) that anyone has really solved this problem yet. I think this may have to wait for some other things to settle down, especially orchestration. So -- can we define a Web service as an instance of a Web-based message conforming to SOAP, supported by: -- a service description (typically WSDL) -- an optional discovery service (UDDI perhaps) -- additional qualities of service as required by the message recipient? Then we could start working up an architecture for processing a Web service as an extention to SOAP (given the SOAP spec is already written this way, anyway), defined by message recipient requirements (i.e. the Web service publisher defines the requirements for interacting with the given endpoint). This would give us an approach to the problem by identifying what a "publisher" can support in terms of a Web service interaction. At least it would seem a good starting point to work up from what we could reasonably expect any given endpoint to support. As a final point, I haven't seen any discussion of transformation technologies as a required part of the Web service architecture. I would argue for it since Web service messages are likely to arrive at a given endpoint in more than one format. I agree we don't want to create any restrictions in the architecture that would prevent the technologies from being used in conjunction with protocols other than HTTP, and other data types and formats than XML Schemas. I guess this reinforces the transformation point. A block diagram putting the fundamental technologies into relationship with the additional technologies might be a good way to get some agreement. I'll try to take a stab at this over the next few days. Eric -----Original Message----- From: www-ws-arch-request@w3.org [mailto:www-ws-arch-request@w3.org]On Behalf Of Tom Bradford Sent: Friday, February 22, 2002 3:20 PM To: Champion, Mike Cc: www-ws-arch@w3.org Subject: Re: Web Service Definition [Was "Some Thoughts ..."] On Friday, February 22, 2002, at 02:46 PM, Champion, Mike wrote: > OK, but if we *define* a "web service" as something that uses WSDL to > define > the contract, a lot of people are going to be unhappy! Also, there's > the > matter that WSDL is merely an industry consortium proposal and the W3C > working group is just getting underway. I've formulated my own slightly skewed definition of a web service: A Web Service is a CGI program that exposes some type of an interface contract. How that CGI program operates, the protocol that it uses, the interface language that it exposes, or who it hangs out with after school, are not the concern of a web services architecture. Any existing CGI could potentially qualify as a web service, including those programs that return content other than XML (like images, HTML pages, streaming media, or other binary content). As such, we should also not assume that the invoking context is going to be XML content... Typically, a query string will suffice. If you make a parameterized request, and are greeted with data that has been dynamically tailored to your request, you are, in effect, using a web service. -- Tom Bradford - http://www.tbradford.org Architect - XQRL (XQuery Engine) - http://www.xqrl.com Apache Xindice (Native XML Database) - http://xml.apache.org Project Labrador (Web Services Framework) - http://notdotnet.org
Received on Saturday, 23 February 2002 13:34:45 UTC