RE: Peer to peer goal

I think that generally these all come under the goal of long running
transactions support. However, it does not stop there. I think we also need
to include:
1. Support for maintaining state within web services. Instead of a web
service blocking on a response from another, it saves state, which can then
be recovered by providing a "state" identifier or handle - the ebXML
Messaging Conversation ID is designed to support this
2. Support for chroeographies. Where I am defining that a choreography is a
specification of the sequence in which messages (often, but not necessarily)
one-way messages are exchanged between one or more SOAP nodes.
3. The one-or-more in the last item is important - i.e. we need to be able
to support the preservation of state when there are more than two SOAP nodes
involved - multi-party B2B interactions are quite common.
4. Handling all the errors and exceptions that can occur, for example, if
you get a message out of sequence then a) how do you know, and b) what do
you do about it when you find out and c) does this result in architectural
requirements.
 
My $0.02c
 
David

-----Original Message-----
From: Ugo Corda [mailto:UCorda@SeeBeyond.com]
Sent: Friday, July 12, 2002 3:55 PM
To: 'Francis McCabe'; Ugo Corda
Cc: www-ws-arch@w3.org
Subject: RE: Peer to peer goal


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