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

I like Joseph's definition, although I think I agree with Steve and Mark
that we're extending the scope of what we need to say in a definition. A
definition should define the essential traits that make a web service a web
service.

I'm a bit averse to using the terms MUST NOT, SHOULD, and MAY. I'm not sure
that we should impose the constraint defined by WSP04. I think it's useful
to include WSP05, although I don't think it's an essential aspect of what
makes a web service a web service. I'm ambiguous about WSP06. I think WSP07
goes into too much detail. I think WSP08 gets too much into architecture,
and isn't an essential aspect of what makes a web service a web service.

Just to add my two cents to the discussion:

I generally like to describe a web service by relating its name to it's
constituent parts:

> A "web resource" is a resource (an electronic construct, such as a file,
network, processor, application, or service) that is identifed by a URI and
accessed through web protocols.

> A "service" is a resource that exposes its functionality through a
programmatic interface (understood by software rather than by humans). The
method of invocation and the possible results of that invocation are
described by a contract.

> A 'web service" is a service that is identified by a URI and is accessed
through web protocols in accordance with the contract that describes its
interface. The specification of the contract is a web resource.

One recommendation that I would make to Joseph's definition is that we not
call out any specific technologies (WSDL, UDDI, etc.) in the core
definition. Our architecture should provide recommendations on which
technologies to use, not the definition.

I'd also prefer to use the more generic term "contract" rather than "well
defined input/output parameters".

Anne Thomas Manes
CTO, Systinet

Received on Wednesday, 27 February 2002 18:28:18 UTC