Recommendations from WSD Patterns Task Force

David Booth, W3C Fellow / HP Software

Amelia Lewis, Tibco

Jonathan Marsh, Microsoft (WSD WG Chair)

Umit Yalcinalp, Oracle

WSD F2F Meeting

30-July-2003

This document: http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/meps-vs-iops/recommendations_clean.htm

$Revision: 1.2 $ of $Date: 2003/08/01 12:25:59 $ by $Author: dbooth $

   

Status of This Document

This document was produced by a task force of the Web Services Description working group for use by that working group in discussions of message exchange patterns. It has no official standing.

Background

• WSDL 1.1 had 4 "MEP"s
• At Arizona F2F, WG tentatively decided on 7 patterns
• In the process, the concept of "pattern" may have subtly changed:
• • WSDL 1.2 Part 2 Patterns draft (hereinafter called " PART2") uses a different sense of "pattern" than "Message Exchange Pattern" in SOAP 1.2 or WS Arch Glossary
  • Might be more accurately called "Input/Output Patterns" (IOPs)
• Misunderstandings within the WG
• Some were thinking MEPs, others IOPs (though for a while they were still called MEPs)

Objectives of This Task Force

• Understand the differences between various message patterns and message pattern styles (previously called "IOPs" and "MEP"s)
• Understand and enumerate the implications of having the WSDL interface/portType indicate each of these patterns or pattern styles
• Provide this information to the WG so that the WG can decide which patterns an/or pattern styles are most appropriate for WSDL interface/portType

• Make suggestions to the WG about which patterns to adopt.

Task Force Participants

Main participants:

• David Booth, W3C Fellow / HP Software
• Amelia Lewis, Tibco
• Jonathan Marsh, Microsoft (WSD WG Chair)
• Umit Yalcinalp, Oracle

Parttime participants:

• Martin Gudgin, Microsoft
• Philippe Le Hegaret, W3C

Signed up but did not participate:

• Don Mullen, Tibco
• Sanjiva Weerawarana, IBM

What We Did

• Illustrated each of the patterns in PART2
• In order to do so, we:
• • Adopted an informal notation for defining and illustrating different patterns
  • Gave a unique name to each pattern variation that we defined
• Identified and discussed ambiguities in the PART2 pattern definitions
• Described alternative interpretations for each PART2 pattern
• Invented potential "clarifications"
• Described variations of each pattern according to different "clarifications"
• Described several use cases
• Analyzed the impact of different pattern variations on use cases
• Analyzed the potential impact of different pattern variations on client code interfaces
• Agreed on recommendations for which variations to adopt and which patterns to drop

Also:

• Tried to define "IOP" (in contrast with "MEP"), but abandoned that because we were wasting time discussing that instead of discussing the implications of the patterns themselves.

How Patterns Were Illustrated

Example: p2 family defined 12 variations of the PART2 "Input-Output" pattern.

See examples of p2 family:

http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/meps-vs-iops/meps-vs-iops_clean.htm#p2

(or

file:///C:/Documents%20and%20Settings/daboo/My%20Documents/home/w3c/DEV/2002/ws/desc/wsdl12/meps-vs-iops/meps-vs-iops_clean.htm#p2 )

Impact on Client Code

• Outlined one hypothetical client code library
• Assumes app separates app logic from transport details
• Useful for understanding the impact on the client code

Example of Hypothetical Client Library Interface

p2b:

  Client A:

  Message sendAndReceiveMessage(ServiceAddress s, Message m);

  Client Bi:

  void registerMessageReceiverCallback(MessageReceiverCallback f);

   

p2c:

  Client A:

  void sendMessage(ServiceAddress s, Message m);

  Client B:

  void registerMessageReceiverCallback(MessageReceiverCallback f);

  Client C:

  void registerMessageReceiverCallback(MessageReceiverCallback f);

   

. . . etc.

See:

http://lists.w3.org/Archives/Public/public-ws-desc-meps/2003Jul/0005.html

Outline of Recommendations to the WG

1. Patterns describe *minimal* behavior.

2. Patterns should only express info that is relevant to more than one party

3. Patterns must specify parties as variables. This also needs to be applied to fault rules.

4. Recommendations for specific patterns (6 to adopt; 2 to drop):

In-Only pattern: Adopt p1a-nf

In-Out pattern: Adopt p2e-nf

In-Multi-Out pattern: Adopt p4c-nf

Out-Only pattern: Adopt p5a-nf

Out-In pattern: Adopt p6b-nf

Out-Multi-In pattern: Adopt p7b-nf

Request-Response pattern: DROP in favor of p2e-nf (listed above)

Multicast-Solicit-Response pattern: DROP. (Subsumed by p6b-nf)

Request with Response to Third Party: Do not adopt. (Details below)

(Guiding principle: Be able to write code based on interface, independent of transport.)

Recommendation: Patterns Specify *Minimal* Behavior

Each pattern represents a contract that specifies *minimal* behavior that is expected between the parties. 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.)

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.

Recommendation: 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.)

Recommended Patterns to Adopt

Ignoring faults, these are the pattern variations we think the WG should adopt.

These patterns omit the faults because faults are now described separately by general-purpose fault rules.

Pattern p1a-nf

This addresses the In-Only pattern of PART2.

Sequence:

1. Client A sends a message to the service S.

Pattern p2e-nf

Addresses the In-Out pattern of PART2.

Sequence:

1. Client A sends a message to service S.

2. Service S sends an ofault message to client A.

Comments: This pattern represents the classic "request-response", since the response is specified as going back to the original requester.

Pattern p4c-nf

This addresses the In-Multi-Out pattern of PART2.

Sequence:

1. Client A sends a message to service S.

2. Service S sends zero or more output messages to client A.

Issue:
Should this pattern require that messages be delivered in order?

Pattern p5a-nf

Addresses the Out-Only pattern of PART2.

Sequence:

1. Service S sends a message to client A.

Pattern p6b-nf

Addresses the Out-In pattern of PART2.

Sequence:

1. Service S sends an output message to client A.

2. Service S receives an input message from client A.

Comments: This is classic "solicit-response".

Pattern p7b-nf

This addresses the Out-Multi-In pattern of PART2.

Sequence

1. Service S sends an output message to client A.

2. Service S receives zero or more input messages from client A.

Issue:
Should this pattern require that messages be delivered in order?

Patterns We Recommend Dropping

1. The Request-Response pattern of PART2.

• Same as the Input-Output pattern of PART2, except that it requires the reply to be on the same channel as the request.
• Superceded by p2e-nf.

2. The Multicast-Solicit-Response pattern of PART2.

• Subsumed by p6b-nf

Considered But Not Recommended: Pattern p2d-nf

Addresses the In-Out pattern of PART2.

Sequence:

1. Client A sends a message to service S.

2. Service S sends an output message to client B.

Observation 1 on p2d-nf

1. This is request / response to a third party. 

Observation 2 on p2d-nf

2. p2d-nf is more general than p2e-nf:

• There is no requirement for clients A and B to be distinct agents.
• If this pattern is applied to a scenario in which the same agent is performing both roles of A and B, then it acts as classic request-response.
• Might there be some economy in having only p2d-nf instead of p2e-nf, since p2d-nf is more general?
• I.e., could a service publish a WSD specifying p2d-nf, but a client use it as p2e-nf?

Observation 3 on p2d-nf

3. This pattern only matters to the service

• From S's perspective, S is doing p2d-nf. HOWEVER . . .
• From A's point of view, A is doing p1a-nf (input only).
• From B's point of view, B is doing p5a-nf (output only)
• Therefore the clients and service do not need to agree on the same information. I.e., the fact that S is NOT just doing two one-way patterns only matters to S.

Observation 4 on p2d-nf

4. The client cannot conveniently use p2d-nf as p2e-nf:

• Guiding principle: Client should be able to write code based on the interface that is independent of transport
• For a client to use this for classic request-response, the client and service must agree on the mechanism that the client should use to indicate what client should receive the response.
• We don't have a standard way for the client to indicate the desired response recipient.
• Therefore client code generators/libraries cannot provide a p2e-nf-like interface for p2d-nf, such as:

  Message sendMessageAndReceiveReply(Message m);

Recommendation on p2d-nf

Do not adopt (unless the WG defines a standard way for a client to indicate the identity of the intended recipient.)

Remaining Issues

1. Faults. Could the fault rules be simplified to a single "message triggers fault" rule?

2. Correspondence with SOAP MEPs.

Summary of Recommendations to the WG

1. Patterns describe *minimal* behavior.

2. Patterns should only express info that is relevant to more than one party

3. Patterns must specify parties as variables. This also needs to be applied to fault rules.

4. Recommendations for specific patterns (6 to adopt; 2 to drop):

In-Only pattern: Adopt p1a-nf

In-Out pattern: Adopt p2e-nf

In-Multi-Out pattern: Adopt p4c-nf

Out-Only pattern: Adopt p5a-nf

Out-In pattern: Adopt p6b-nf

Out-Multi-In pattern: Adopt p7b-nf

Request-Response pattern: DROP in favor of p2e-nf (listed above)

Multicast-Solicit-Response pattern: DROP. (Subsumed by p6b-nf)

Request with Response to Third Party: Do not adopt. (Details below)

(Guiding principle: Be able to write code based on interface, independent of transport.)

[End]