W3C home > Mailing lists > Public > public-ws-desc-meps@w3.org > July 2003

Proposed MEP TF recommendations

From: David Booth <dbooth@w3.org>
Date: Tue, 22 Jul 2003 15:53:00 -0400
Message-Id: <5.1.0.14.2.20030722154703.028a40e0@localhost>
To: public-ws-desc-meps@w3.org

Here, for discussion, are 5 specific recommendations I propose that MEP TF 
makes back to the WG.  Anyone with other suggestions, please make them so 
that we can discuss them on Wednesday.  Thanks!




Proposed Recommendations from the MEP TF to the WSD WG
======================================================

1. Patterns describe *minimal* expected behavior.
Each pattern represents a contract that specifies *minimal* behavior that 
is expected between the parties. The clients and services may have 
additional behaviors that are not specified by the pattern. Specifically, a 
client or service may send other messages (to each other or other parties) 
that are not described by the pattern. However, in such case, the parties 
must use other means to agree on the handling of the additional messages. 
For example, a message specified in a pattern as being from service S to 
client A might actually be broadcast to other clients in addition to being 
sent to client A.  However, the pattern only governs the agreement to send 
the message to client A.

2. Patterns specify parties as variables.
Every pattern involving more than one message must specify (as variables) 
the sender and recipient of each message.  For example, a pattern might 
specify:

         "Some client A sends a message M1 to some service S.  Subsequently
         service S replies by sending a message M2 to client A."

This example makes clear that S sends the response to A.  As a contrasting 
example, a pattern might specify:

         "Some client A sends a message M1 to some service S.  Subsequently
         service S replies by sending a message M2 to some client B."

This later example makes clear that client A and client B are not 
necessarily the same client.  (However, this pattern description also does 
not prevent a client from assuming roles of both A and B simultaneously.)

3. In general, the WSD (and therefore the patterns) should only contain 
information that is relevant to more than one party.  (For example, 
information that the client and service need to agree on.)


4.  Suggested pattern recommendations (under the "pattern specifies minimal 
behavior" assumption above, and ignoring faults, which are treated separately)

p1 family recommendation: Adopt p1a:
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/meps-vs-iops/meps-vs-iops_clean.htm#p1a

p2 family recommendation: Adopt p2e:
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/meps-vs-iops/meps-vs-iops_clean.htm#p2e
Maybe also adopt p2d (Response to third party):
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/meps-vs-iops/meps-vs-iops_clean.htm#p2d
*If* there is a standard way to indicate where the response should go, then 
p2d could be adopted instead of p2e.  Note that p2d involves two clients, A 
and B, and from each of those client's point of view, it only sends or 
receives a single message, which could just as well be modeled by the 
patterns p1a (input only) and p5a (output only).

p3 recommendation: Adopt as p2e, as described above.

p4 family recommendation: Adopt p4c:
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/meps-vs-iops/meps-vs-iops_clean.htm#p4c

p5 family recommendation: Adopt p5a:
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/meps-vs-iops/meps-vs-iops_clean.htm#p5a

p6 family recommendation: Adopt p6b:
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/meps-vs-iops/meps-vs-iops_clean.htm#p6b

p7 family recommendation: Adopt p7b:
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/meps-vs-iops/meps-vs-iops_clean.htm#p7b

p8 family recommendation: Drop in favor of p6b, which can be used by the 
service as p8d under the "pattern specifies minimal behavior" assumption, 
without affecting the clients.


5.  Fault rules.  Simplify to "message triggers fault", and further specify 
that the fault is sent to the client whose message triggered the 
fault.  For example, in a pattern such as p2d that involves two clients A 
and B, if client A sends an initial request message that causes fault F to 
be generated, then fault F is sent to client A, not client B.



-- 
David Booth
W3C Fellow / Hewlett-Packard
Telephone: +1.617.253.1273
Received on Tuesday, 22 July 2003 15:53:03 GMT

This archive was generated by hypermail 2.2.0 + w3c-0.30 : Friday, 25 March 2005 11:17:39 GMT