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<bold> will</bold> 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