Re: Peer to peer goal

Joel:
   Yes, you are right, connections come and go. However, how is it that 
when you re-establish a connection you `know' its with the same entity; 
especially in an environment that includes server farms, load-sharing, 
etc.
   The requirement is that you have to be able to `connect'  -- in 
software -- one connection with another; in order to support 
long-running transactions.
   I.e., in a conversation, one entity sends a message to another, and a 
few days (and a new server) later send another, or gets a reply and so 
on. Permanent presence involves at least two abilities -- the ability to 
send a message at an arbitrary time and the ability to know that a given 
message does come from a particular entity.

Frank

On Monday, July 15, 2002, at 12:06  PM, Munter, Joel D wrote:

> re: AC023,the comment below about "...permanent presence..." needs some 
> clarification.  Don't connections come and go?  With respect to long 
> running transactions, don't servers come up and down between the start 
> and end and multi-month txns?
> joel
>  
> -----Original Message-----
> From: Burdett, David [mailto:david.burdett@commerceone.com]
> Sent: Monday, July 15, 2002 10:09 AM
> To: 'Francis McCabe'; Ugo Corda
> Cc: www-ws-arch@w3.org
> Subject: RE: Peer to peer goal
>
> I'm totally agree ... see below for a few extra comments.
>  
> David
>
> -----Original Message-----
> From: Francis McCabe [mailto:fgm@fla.fujitsu.com]
> Sent: Monday, July 15, 2002 9:01 AM
> To: Ugo Corda
> Cc: www-ws-arch@w3.org
> Subject: 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.
>
> [DBu] +1 
>
> 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.
>
> [DBu] +1 
>
> D-AC023
>
> Web services and clients must support modes of interaction where both 
> have a permanent presence.
>
> [DBu] +1 
>
> D-AC024
>
> Web services such be able to support N party interactions, such as 
> auctions, escrow services, proxy services, broker services.
>
> [DBu] +1 
>
> --------
>
> These do not mention security, or extended conversations.
>
> [DBu] Security MAY be need for P2P and CS ... but we should only define 
> it once. But use of security should alwayss be optional in the instance.
>
> 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).
>
> [DBu] +10 !!
> Extended conversations is the way a lot of business works where data is 
> exchanged between very loosely coupled activities. However there is 
> alwas a common context (e.g. an order no) that enables the recipient of 
> a message to recreate the context together. Enabling the architecture 
> to do this is a big plus as it removes (some) of the need for the 
> application to do it.
> ... but on the other hand sometimes context is not needed at all, for 
> example doing a query on the price of a product.
>
> 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.
>
> [DBu] +1. Management of relationships is orthogonal to long running 
> transactions, but very useful. 
>
> 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.
>
> [DBu] +1 
>
> 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
>
>
>
>