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