W3C home > Mailing lists > Public > www-ws-arch@w3.org > February 2003

Comments regarding WSA glossary

From: Assaf Arkin <arkin@intalio.com>
Date: Sun, 23 Feb 2003 17:22:15 -0800
To: <www-ws-arch@w3.org>


The definition is two narrow since it defines the relationship between
messages but not the relationship between a message and a conversation or a
message and an activity (e.g. as used in WSCI and BPEL4WS).

I would suggest a more generic definition, something like:

"A causal, parallel or reciprocal relationship between a message and another
entity, e.g. a causal relationship between one message and another, a
parallel relationship between a message and a conversation, or a reciprocal
relationship between two activities performed as part of the same


Could we define interaction as more generic and then define atomic
interactions (the act of doing an operation) and long-running interactions?
The definition of long-running interaction precludes interactions between
peer services. Is this intentional?

How about: "The process of two entities acting on each other as captured by
the exchange of messages, e.g. a service requestor and service provider
interacting by performing an operation, or multiple services interacting as
part of a long-running choreography."


How about: "An atomic interaction between a service requestor and a service
provider. More complex interactions are built by composing multiple

Reliable messaging:

"The sender can decide whether or not a message has been received by its
intended receiver."

It is impossible to determine that it has not been received (aka
improbability of reaching concensus), but a decision is possible using

Formally, the sender and receiver(s) both reach a concensus decision about
delivery (=processing). If a decision cannot be reached (e.g. no ack
received) then the sender can conclude that a particular receiver is
inoperative (=faulty process) and reach its own decision (not received). The
formal definition is more interesting since it supports group communication,
e.g. multicast.

"The receiver processes a given message from the sender only if sent by that

This is typically fulfilled using digital signatures (see non-repudiation)
but is part of the formal definition of RM.

I am a strong believer that the WSA should look beyond the specific patterns
of communication involving two end-points and RPC style of communication,
even if those are most applicable use cases and well supported by the
current reference architecture.

Instead it describe the architecture in more generic terms, borrowing as
much as possible from formal models of distributed systems. It could propose
WSDL, SOAP, ebXML, REST etc as applicable solutions (observing the 80/20
rule), but not preclude future extensions that would allow for more
interesting service definitions (e.g. multicast, multi-party, replication).

For RM I would suggest a definition based on group communication with
point-to-point (such as HTTP or WS-RM) being a special case that satisfies
the requirements of RM. A formal definition is given by Chandra-Toueg in
Unreliable Failure Detectors for Reliable Distributed Systems (Proceedings
of the Tenth ACM Symposium on Principles of Distributed Computing, pages

For interactions, I would suggest looking at formal models for distributed
concurrent systems based on communication, in particular various forms of
process algebra (most influential material listed here:


Assaf Arkin                                          arkin@intalio.com
Intalio Inc.                                           www.intalio.com
The Business Process Management Company                 (650) 577 4700

This message is  intended  only for the  use of  the Addressee and may
contain information  that is PRIVILEGED  and CONFIDENTIAL.  If you are
not the  intended recipient,  dissemination of  this  communication is
prohibited.  If you have received this communication  in error, please
erase all copies  of the  message and  its  attachments  and notify us
Received on Sunday, 23 February 2003 20:23:36 UTC

This archive was generated by hypermail 2.3.1 : Tuesday, 6 January 2015 21:41:03 UTC