Re: Peer to peer goal

Just to follow from my previous post, I do not wish to imply that you 
need to support non-repudiation in order to achieve P2P nirvana. 
Eventually you probably do need to look at these kinds of issues. 
However, for an architecture mandate, the watchword here is enablement 
and abstraction. We need to identify the key abstractions and 
architectural elements that make up a 21st century web service; boiling 
oceans is not a pre-requisite.

Frank McCabe

On Friday, July 12, 2002, at 02:53  PM, Ugo Corda wrote:

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