Re: Peer to peer goal

Ugo:
   Setting P2P as a goal merely has the effect of identifying it as 
something that is important to us; without commenting on the current 
state of technology.

  Having said that, I haven't had the time yet to go through SOAP 1.2 or 
WSDL 1.2 to determine if its handled. I suspect that much of what we 
will need will be covered, reliable messaging notwithstanding ;-)

There are multiple levels here: low-level technology needed to deliver 
messages (for example) and higher-level architectural abstractions 
(concepts of identity, management of permanence, relationships etc)

I would say that one-way messaging (to take an example) might be a key 
enabling technology but is not itself enough to capture P2P. You need 
also the concept of a conversation, as a generalization of method 
invocation, and this eventually leads us to security related concepts 
such as principal, non-repudiation, etc.

Hope this shed a little light. Sorry to be so general.

Frank

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