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