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:


<color><param>0000,0000,0000</param>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.

</color>

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:


<excerpt><fontfamily><param>Arial</param><smaller>Frank,</smaller></fontfamily>

 

<fontfamily><param>Arial</param><smaller>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.</smaller></fontfamily>

 

<fontfamily><param>Arial</param><smaller>For example, the security
aspects you mention would certainly be addressed by the security
requirement.</smaller></fontfamily>

 

<fontfamily><param>Arial</param><smaller>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.</smaller></fontfamily>

 

<fontfamily><param>Arial</param><smaller>I think my basic concern is
that a proliferation of Goals might make the Requirements document
hard to digest.</smaller></fontfamily>

 

<fontfamily><param>Arial</param><smaller>Ugo</smaller></fontfamily>


<fontfamily><param>Tahoma</param><smaller>-----Original Message-----

<bold>From:</bold> Francis McCabe [mailto:fgm@fla.fujitsu.com]

<bold>Sent:</bold> Friday, July 12, 2002 3:32 PM

<bold>To:</bold> Ugo Corda

<bold>Cc:</bold> www-ws-arch@w3.org

<bold>Subject:</bold> Re: Peer to peer goal


</smaller></fontfamily>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:



<fontfamily><param>Arial</param><smaller>Frank,</smaller></fontfamily>




<fontfamily><param>Arial</param><smaller>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.</smaller></fontfamily>




<fontfamily><param>Arial</param><smaller>Thank you,</smaller></fontfamily>


<fontfamily><param>Arial</param><smaller>Ugo</smaller></fontfamily>



<fontfamily><param>Tahoma</param><smaller>-----Original Message-----</smaller></fontfamily>


<bold><fontfamily><param>Tahoma</param><smaller>From:</smaller></fontfamily></bold><fontfamily><param>Tahoma</param><smaller>
Francis McCabe [mailto:fgm@fla.fujitsu.com]</smaller></fontfamily>


<bold><fontfamily><param>Tahoma</param><smaller>Sent:</smaller></fontfamily></bold><fontfamily><param>Tahoma</param><smaller>
Friday, July 12, 2002 2:10 PM</smaller></fontfamily>


<bold><fontfamily><param>Tahoma</param><smaller>To:</smaller></fontfamily></bold><fontfamily><param>Tahoma</param><smaller>
www-ws-arch@w3.org</smaller></fontfamily>


<bold><fontfamily><param>Tahoma</param><smaller>Subject:</smaller></fontfamily></bold><fontfamily><param>Tahoma</param><smaller>
Peer to peer goal</smaller></fontfamily>



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




</excerpt>