W3C home > Mailing lists > Public > www-ws-arch@w3.org > July 2002

RE: Peer to peer goal

From: Ugo Corda <UCorda@SeeBeyond.com>
Date: Fri, 12 Jul 2002 15:55:23 -0700
Message-ID: <C513FB68F8200244B570543EF3FC653708AE3566@MAIL1.stc.com>
To: "'Francis McCabe'" <fgm@fla.fujitsu.com>, Ugo Corda <UCorda@SeeBeyond.com>
Cc: www-ws-arch@w3.org
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.

-----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


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

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. 


On Friday, July 12, 2002, at 02:53 PM, Ugo Corda wrote: 


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, 


-----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. 


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. 


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 


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. 


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. 


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. 


It must be possible for the architecture to model extended conversations
between peer web services. 


It must be possible for peers to volunteer information as well as invoke


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


It must be possible to quote, verbatim and modified, messages within
top-level messages, to an arbitrary depth. 


It must be possible to `anonymize' (sic) messages to elide the intended


It must be possible to express multiple receivers and to express `wait'
points in service orchestration 
Received on Friday, 12 July 2002 18:55:55 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:40:57 UTC