W3C home > Mailing lists > Public > www-ws-arch@w3.org > March 2002

Back to Requirements (was RE: Web Service Definition [Was "Some T houghts ..."])

From: Champion, Mike <Mike.Champion@SoftwareAG-USA.com>
Date: Tue, 5 Mar 2002 10:39:00 -0700
Message-ID: <9A4FC925410C024792B85198DF1E97E4029DFD7A@usmsg03.sagus.com>
To: www-ws-arch@w3.org

> -----Original Message-----
> From: Krishna Sankar [mailto:ksankar@cisco.com]
> Sent: Monday, March 04, 2002 3:00 PM
> To: www-ws-arch@w3.org
> Subject: RE: Web Service Definition [Was "Some Thoughts ..."]

> 	"A web service is defined as software which has the following
> characteristics:
> 	1.	Interfaces and bindings defined in a standard way
> 	2.	Interacts using standard Internet protocols
> 	3.	The result 1s XML with the vocabulary clearly documented
> 	4.	The result is XML that matched a specific schema
> 	5.	The result is SOAP with the payload documented 
> in human-readable form
> 	6.	The result is SOAP and the payload documented with WSDL
> 	7.	URI encoded a SOAP invocation message and the 
> result was SOAP with the
> payload documented with WSDL.
> 	8.	Does not *require* human interaction
> 	9.	Does not *mandate* an object model
> 	A.	Is programming language and VM independent
> 	B.	Is distributed
> 	C.	Is secure
> 	D.	..."
> 	Does this make more sense ?

I think we've learned enough in the "what is a web service" discussion to
get back to the requirements; lots of things have come up in the discussion
that are not IMHO good constraints on the *definition* of "web service" in
the abstract, but are very good constraints on what this group should

Looking back at the strawman requirements list, I see (abbreviating

D-AG0001-a provides a complete reference framework that encourages
D-AG0002 provides modularity of web services components
D-AG0003 is sufficiently extensible to allow for future evolution of
D-AG0004 ensures platform independence of web services components
D-AG0005 provides simplicity and ease-of-use 
D-AG0006 addresses the security of web services 
D-AG0007 is reliable, and stable, and whose evolution is predictable 
D-AG0008 is coherent and consistent in its definition
D-AG0009 is aligned with the semantic web initiative 
D-AG0010 uses W3C XML technologies 
D-AG0011 is consistent with the existing web 

"Refactoring" this list, and Krishna's list, in the light of the recent
discussions, I'd like to see something like this:

The overall requirement is to produce a reference architecture [perhaps
citing the CORBA reference architecture as an exemplar] which ensures the
interoperability of web services software products from different
implementors based on well-defined standards.  Specifically, this reference
architecture must:

1 - Define how a web service is identified, starting with, but not
necessarily limited to, a URI.

2 - Describe how the actual invocation of a web service can be defined in
enough detail so that programmers can invoke it in a consistent and
interoperable manner.

3 - Describe how the result of the web service can be defined in enough
detail so that the data obtained from the service can be reliably mapped
onto programming language data structures and type systems.

4 - Describe how authentication, access control, and encryption can be used
to provide secure web services.

5 - Allow for different message exchange patterns between the consumer and
provider of a service (explicitly including RPC, publish-subscribe,
asynchronous messaging ....?)

6 - Allow for graceful evolution of service definitions as technology and
requirements change.

Some additional constraints on all definitions/descriptions in the reference
architecture are that they:

- Describe components that are modular and loosely coupled 
- Are platform-neutral, language-neutral, and vendor-neutral
- Are simple and as easy to use/understand by ordinary software developers
as possible
- Use XML technologies to the greatest extent possible
- Be consistent with the extisting web architecture to the greatest extent
- Leverage the technologies of the Semantic Web initiative as they prove

Anyway, I didn't mean to gratuitously re-define the existing requirements
list, just to suggest a way re-arrange items in a way that seems to "flow"
better in light of the web service definition discussions.  
Received on Tuesday, 5 March 2002 12:39:33 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:40:54 UTC