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

Hi Joseph,


	This is starting to look like a list of requirements...good. Instead
of focusing on some mythical definition of Web Services over which we can
all disagree in perpetuity, I'd like to suggest that we start to talk about
goals, critical success factors, and requirements for Web Services
Architecture. We need to concentrate on this discussion so as to meet the
deadlines in our charter. Let's take Joseph's list as a start and continue
to discuss these things in concrete terms.

	With your permission Joseph, I'll add these to the current
requirements list, with some suitable editing.

	We could probably discuss "What is a Web Service?" until the
electrons come home, but we have real work to do. :) 

Regards,

D-


> -----Original Message-----
> From: Joseph Hui [mailto:jhui@digisle.net]
> Sent: Monday, February 25, 2002 1:43 PM
> To: Champion, Mike; Cutler, Roger (RogerCutler); Mark Baker;
> steve.vinoski@iona.com
> Cc: www-ws-arch@w3.org
> Subject: RE: Web Service Definition [Was "Some Thoughts ..."]
> 
> 
> If only I had a dime, for every "Web Service" definition I came
> across, ...  Well, how well off could I be?;-)
> 
> So, instead of trying to compile a list which shall soon
> become amiss no matter how exhaustive we can make it now with
> existing definitions, I'd propose we take a different tack,
> to define web services by properties, which are more likely
> to remain invariant with time.  
> 
> Here's a stab, incorporating much of the WG discussion so far,
> plus some external infusion. 
> 
>   A web service is a computing entity with the following properties
>   (which incidentally sound like requirements also).
> 
>   WSP01: A web service MUST be web-addressable, by a URI.
> 
>   WSP02: A web service MUST provide standards-based programmatic
>   interface with well defined input/output parameters.
>   (For the sake of simplicity, RPC returns may be deemed output 
>   parameters in web services.)
>   
>   WSP03: A web service MUST be sufficiently well formulated such
>   such it can be unambiguously described using WSDL.  
>   
>   WSP04: A web service MUST NOT allow the service requester to
>   take over its control of execution on its host system.
>   
>   WSP05: A web service SHOULD be amenable to be a part of the
>   aggregation, composition, or orchestration of multiple web
>   services, where it assumes the leading or a subordinate role.
>   [Is WSP4 as-is adequate in conveying Inter-operability?
>   If not, then we need a separate WSPx for Inter-op.]
>   
>   WSP06: A web service SHOULD make little or no assumption of the
>   service requester's hardware platform, programming language,
>   and operations before, during, or after the service rendered.
>      
>   WSP07: A web service MAY make certain assumptions of the policy
>   and/or mechanism of the security and/or transport of its host
>   system and/or network, mainly for the purpose of optimization.
>   (However, it MUST only execute on verified assumptions; and
>   SHOULD adapt upon failed assumptions to strive for high
>   availability of service.)
>   
>   WSP08: A web service MAY advertise itself in as many public
>   directories as appropriate, such as those operated by the
>   UDDI consortium.  
> 
>   WSP0x: ?
>     
> My $.02.
> 
> Joe Hui
> Exodus, a Cable & Wireless service
> 
>  
> 
>

Received on Monday, 25 February 2002 15:05:09 UTC