RE: Peer to peer goal

Frank,
 
It would help me better understand where you are aiming at with these P2P
requirements if you could elaborate on how much of this you think is already
supported in SOAP and WSDL, and what is still missing.
 
Thank you,
Ugo

-----Original Message-----
From: Francis McCabe [mailto:fgm@fla.fujitsu.com]
Sent: Friday, July 12, 2002 2:10 PM
To: www-ws-arch@w3.org
Subject: Peer to peer goal



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 critical. 


D-AG007 Peer to Peer interoperability 

The Web services architecture must support interoperability between peers as
well as client-server architecture. 


Rationale: 

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. 


Comment: 

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 


D-AC023 

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 interaction. 


D-AR023.1 

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. 


D-AR023.2 

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. 

D-AR023.3 

It must be possible for the architecture to model extended conversations
between peer web services. 

D-AR023.3 

It must be possible for peers to volunteer information as well as invoke
methods. 


D-AC024 

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


D-AC024.1 

It must be possible to quote, verbatim and modified, messages within
top-level messages, to an arbitrary depth. 

D-AC024.2 

It must be possible to `anonymize' (sic) messages to elide the intended
recipient 

D-AC024.3 

It must be possible to express multiple receivers and to express `wait'
points in service orchestration