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

RE: MEP proposal

From: Assaf Arkin <arkin@intalio.com>
Date: Fri, 21 Feb 2003 12:40:10 -0800
To: "Amelia A. Lewis" <alewis@tibco.com>
Cc: <jacek@systinet.com>, <mgudgin@microsoft.com>, <jeffsch@windows.microsoft.com>, <www-ws-desc@w3.org>

> -----Original Message-----
> From: Amelia A. Lewis [mailto:alewis@tibco.com]
> Sent: Friday, February 21, 2003 10:43 AM
> To: Assaf Arkin
> Cc: jacek@systinet.com; mgudgin@microsoft.com;
> jeffsch@windows.microsoft.com; www-ws-desc@w3.org
> Subject: Re: MEP proposal

> Probably we need to state, somewhere, that a MEP is something
> that doesn't have any control flow constructs (and this is why
> there are choreography languages; *they* have constructs, we just
> have sequences ... grumble, grumble, mother *always* loved
> choreography best ...).  In fact, it's very likely that we need a
> much better (more constraining?  more precise?) definition of MEP
> and of operation.  Likewise, choreo languages need this, because
> they use MEP/operation as atoms.  If the point of this para is
> that we have some rather underdefined concepts, I'll go along with that.

I think we need to define these common communication idioms first, justify
them, and then define MEPs to support them. Otherwise, if MEPs are
open-ended we can consider extending them to the point where they cover the
same space as choreography. After all, a choreography is a pattern of
messages exchanged between the roles, and a store-and-forware mechanism may
also involve some complex MEP.

I'll give it a try:

We constaint WSDL MEPs to define atomic operations from the perspective of
the service.

The term atomic implies that the operation is indivisible, in other words,
contains the minimum number of messages required to perform the operation.
Any composition that can be further divided is not a WSDL MEP and is
achieved using choreography (or other coordination mechanisms). Atomic
operations can be combined to form interaction patterns of arbitrary
complexity (see WSCI).

The term atomic operation refers to the operation and not the protocol. A
TCP communication may involve multiple packets going back & forth between
two nodes. The service described by WSDL will never receive a partial
message, only a complete message, therefore has no understanding of how many
messages are exchanged by the underlying protocol.

Similarly, an RM layer may send messages, acks, nacks, pings, etc described
by some protocol-level message exchange pattern (e.g. WS-RM). From the
perspective of the WSDL operation, only one message is exchanged (acks,
nacks, pings are signals are not propagated up to the operation). Similarly,
intermediaries are ignored, though in reality multiple non-operation
messages may be exchanged between the service and the intermediaries.

We define two categories of atomic operations which together form four basic
operation MEPs:

Asynch - An asynchronous operation has a lower bound of one message.
Therefore all asynchronous operations involve one message.

Synch - A synchronous operation has a lower bound of two messages. Therefore
all synchronous operations involve two messages. Either message can be
empty, and either message can have alternative content models (e.g. in WSDL
1.1 an output message or one of several faults).

Unicast - A unitcast operation has one identified consumer, we model it as
an operation which begins by the service receiving a message.

Multicast - A multicast operation has multiple consumers, we model it in
reverse as an operation which begins by receiving a message from the

Matrix for WSDL 1.1 operation MEPs:

                  Synch  Unicast
one-way             -       +
request-response    +       +
notification        -       -
solicit-response    +       -

A synchronous communication pattern can be built using asynchronous
operations. For example, in WSCI an interaction can be bound by a 'request'
message, a 'response' message and a time constraint. However, the semantics
of such a message exchange is different from an atomic synchronous

Since protocol bindings are defined at the WSDL level, such an interaction
may not be able to utilize the protocol in the same way as a WSDL
synchronous operation. For example, sending the request and response over
the same communication channel, or forcing response to be sent immediately
following request when communication channel is reused across operations
(HTTP 1.1 persistent connections).

Semantic differences also occur when factoring other atomic contexts, such
as security and transactions. A synchronous operation is guaranteed to
complete in the same transaction in which it started, and the security
context is guarantee to persist until the operation has completed.
(Long-lasting transactions are not subject to this restriction)

On the other hand, an asynchronous operation may be performed by the service
after the sending atomic transaction has completed, or after the sending
security context has expired. Such a context can range over the interaction
between the implementation and a store-and-forward mechanism (not described
by WSDL), but not across the entire interaction as described by WSDL.

The distinction between asynchronous and synchronous atomic operations
brings not just simplicity but also a better understanding of how
interactions occur based on these atomic operations.

A synchronous operation can be implemented using an asynchronous protocol,
as long as it obeys the semantics that two messages in opposite directions
follow each other and the operation is demarcated by the sending/receiving
of these messages.

For example, using UDP to send a 'request' message and UDP to receive a
'response' message, using different HTTP connections for each, and so forth.
In fact, every TCP communication is implemented using IP and Ethernet, both
of which are asynchronous protocols.

A multicast operation requires multicast protocol bindings. These are not a
normative part of WSDL 1.1 or WSDL 1.2, however, the operation is described
in abstract term and is therefore not constrained to the availability of any
particular protocol bindings.


> Amy!
> --
> Amelia A. Lewis
> Architect, TIBCO/Extensibility, Inc.
> alewis@tibco.com
Received on Friday, 21 February 2003 15:41:29 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:06:28 UTC