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

Peer to peer goal

From: Francis McCabe <fgm@fla.fujitsu.com>
Date: Fri, 12 Jul 2002 14:10:25 -0700
To: www-ws-arch@w3.org
Message-Id: <C949A242-95DB-11D6-9A73-000393A3327C@fla.fujitsu.com>
This goal aims to capture a major opportunity for web services: enabling 
the interworking of systems where a sustained bi-directional 
relationship is required. If this is not WEB services then another core 
paradigm will be co-opted to support this kind of business as it is 

D-AG007 Peer to Peer interoperability
    The Web services architecture must support interoperability between 
peers as well as client-server architecture.

Many business processes are not easily modeled as straightforward 
client/server architectures. While the customer/supplier relationship is 
still dominant, this does not imply that all (or even most) interactions 
between them can be accurately captured using client/server architecture.

I.e., it is not the case that the hierarchical relationships in business 
can always be modeled using a client server architecture. On the other 
hand enabling a peer to peer architecture is actually neutral to the 
business relationship of the parties.

The last time this was posted there was very little comment on the list. 
However enabling, peer-to-peer will have a profound effect on many of 
the assumptions and requirements of web services.

Critical Success Factors

   Web services and clients must support modes of interaction where both 
have a permanent presence.

   The idea here is that if a web service can be said to have an 
identity, and that operationally a web service can interact with another 
web service then you can begin to achieve peer-to-peer modes of 

   Web services must be identifiable -- separately from their locations. 
The sole purpose of an identifier is to permit other entities to 
`reason' across multiple interactions.

   Clients and servers must support bi-directional messaging, such as 
event notification.    For example, a supplier must be able to notify a 
customer of an event.
   It must be possible for the architecture to model extended 
conversations between peer web services.
   It must be possible for peers to volunteer information as well as 
invoke methods.

   Web services such be able to support N party interactions, such as 
auctions, escrow services, proxy services, broker services.

   It must be possible to quote, verbatim and modified, messages within 
top-level messages, to an arbitrary depth.
   It must be possible to `anonymize' (sic) messages to elide the 
intended recipient
   It must be possible to express multiple receivers and to express 
`wait' points in service orchestration
Received on Friday, 12 July 2002 17:40:26 UTC

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