Re: Peer to peer goal

Ugo:
  P2P as a goal reflects an important class of interoperability 
situations that cannot be captured with a client server model.

  I have no doubt that some of the CSFs for P2P also belong under goals. 
However, the CSFs that I introduced seem to be specific to the P2P goal, 
other things that I discussed are more general and I assumed would be 
covered.

  Let me restate the goal and CSFs:

D-AG007 Peer to Peer interoperability

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

D-AC023


Web services and clients must support modes of interaction where both 
have a permanent presence.

D-AC024


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

--------

These do not mention security, or extended conversations.

BTW there appears to be a `hard line' amongst some  web services folk: 
that there is no need for the concept of an extended conversation of any 
kind. My response to them, is that they are throwing away an important 
opportunity to satisfy the needs of our customers (our in the collective 
sense, not merely Fujitsu's).

The real motivation for the P2P goal is to directly address that 
point -- at the level of abstraction appropriate for an architectural 
specification. Other supporting concepts, in particular the management 
of relationships between participants, is pretty critical IMO but not 
appropriate at this level of abstraction.

I agree completely that security should be handled independently of a 
P2P goal, although security CSFs would impinge on the safety of P2P 
interactions.

I happen to believe that though there might be overlap between 
client-server extended conversations and peer extended conversations, 
doing the latter will solve the former but not vice-versa.

Frank McCabe

On Friday, July 12, 2002, at 03:55  PM, Ugo Corda wrote:

> Frank,
>  
> Your clarification made me think whether it's necessary to create a P2P 
> specific goal, or whether the requirements you mention would better fit 
> under other categories.
>  
> For example, the security aspects you mention would certainly be 
> addressed by the security requirement.
>  
> Other concepts like extended conversations do not seem to be just 
> specific to P2P. For example, extended conversations can also apply to 
> the case of client-server configurations engaged in long lasting 
> transactions.
>  
> I think my basic concern is that a proliferation of Goals might make 
> the Requirements document hard to digest.
>  
> Ugo
>
> -----Original Message-----
> From: Francis McCabe [mailto:fgm@fla.fujitsu.com]
> Sent: Friday, July 12, 2002 3:32 PM
> To: Ugo Corda
> Cc: www-ws-arch@w3.org
> Subject: 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
>
>
>