RE: Web Service Definition [Was "Some Thoughts ..."]

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