W3C home > Mailing lists > Public > www-ws-arch@w3.org > July 2003

Re: The UR Trout: Web Services, REST, SOAP

From: Christopher B Ferris <chrisfer@us.ibm.com>
Date: Thu, 3 Jul 2003 10:01:15 -0400
To: Dave Hollander <dmh@contivo.com>
Cc: www-ws-arch@w3.org
Message-ID: <OF441DE85D.AB4B555F-ON85256D58.0048E0C6-85256D58.004D0495@us.ibm.com>

Dave Hollander wrote on 07/02/2003 07:23:13 PM:

> The WSA seems to be getting close to being able to decide this issue. 
> To test the waters, I am making the following proposal. 
> The point, for now, is to see if some text similar to this could go into
> the conceptual background section-2.x. +1, -1 and questions would be
> appreciated.
> The point is NOT start another long debate. If there is general 
> then
> the text an be worked on. If not, then we will continue with other 
> and
> try to make this definition again later.
> DaveH
> -----------------------------------------------------
> The UR trout in the WSA trout pond is the definition of what is a web
> service and if soap, WSDL or Uniform Interface is required to be a web
> service. This proposal is less focused on a formal definition as would
> appear in the actual architectural document and more in the intent of 
> text that would appear. It is my personal proposal, but thanks to 
> for helping to define the problem and educating me about possible 
> Goal
> Web services are about machine to machine (M2M) communication. 
> whose complexity can range from simple access to data to complex
> conversations whose outcome must be predictable, reliable and persisted.

Web services is focused on machine to machine (m2m) interactions whose
complexity can range from simple information retrieval to complex 
whose semantics, interfaces, and state transitions must be predictable.

[I think that the latter two qualities apply, but they also hold true for
non m2m situations. The important quality that must be called out is 
since machines need to be programmed in advance... there is no 
just automation.]

> The diverse range of needs in M2M communication has fosters a variety of
> design solutions and architectural approaches. The challenge to the WSA 
> to select between them and/or synthesize new architectural style. The
> proposed solution strives to seek the following balance between the 

The diverse range of application of M2M interaction has fostered a variety
of design solutions and architectural styles. The challenge of the WSA is 
select one of these solutions and/or architectural styles and/or to 
a new architectural style that captures the best and most suitable set of 
The WSA should achieve an effective balance from amongst the following 

> * Make common needs simple to implement. 

* Simple tasks should be simple to implement

> * Make it possible to achieve complex needs. 

* Must not constrain ability to effect complex requirements
such as security and relability

> * Make the interface as uniform as possible. 

* Strive for a uniform interface

> * Assure information about the interface is readily visible and
> identifiable. 
> * Conform to REST when possible and practical. 

[Why? certainly, REST and WSA should share a number of common properties,
and to achieve those desired propoerties, the will likely share in some
of the same constraints, but conformance with REST?]

> * Assure all functionality currently implemented M2M communications
> technologies can be implemented    using conforming interfaces. 


> Proposal
> Web services are machine to machine communications using interfaces 
> standards associated with the World Wide Web. For simple communications, 
> HTTP and XML standards are sufficient for interface definition. For more

[Are they really?]

> complex communications, the interface must use well establish standards 
> identify the schema for the payload and methods within the binary 
> data. The method of providing viability and access to this data must be 
> defined by standards such that all applications that implement the 
> are able to locate that data within any conforming a message.

[I think that there's much more that has been left unsaid.]


Christopher Ferris
STSM, Emerging e-business Industry Architecture
email: chrisfer@us.ibm.com
phone: +1 508 234 3624
Received on Thursday, 3 July 2003 10:01:31 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:08 UTC