RE: Peer to peer goal

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