Pattern Task Force
of the W3C WS Description WG
David Booth, W3C Fellow / HP Software
Martin Gudgin, Microsoft
Philippe Le Hegaret, W3C
Amelia Lewis, Tibco
Jonathan Marsh, Microsoft (Working Group Chair)
Don Mullen, Tibco
Sanjiva Weerawarana, IBM
Umit Yalcinalp, Oracle
http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/meps-vs-iops/meps-vs-iops_clean.htm
$Revision: 1.19 $ of $Date: 2003/07/21 05:07:25 $ by $Author: dbooth $
No official standing. Comments are welcome.
·
1. A WSD is intended for use by a WS and its client or clients.
2. A primary purpose of the WSD is to establish a contract on the syntax, datatypes, and protocols that the interacting parties will use to interact.
3. The meaning of a Web Service Description (WSD) is determined solely by its logical content (abstract model).
4. The WSDL interface/portType portion of a WSD defines an abstract interface that is potentially usable by multiple clients to interact with multiple Web services.
5. A WSDL service defines an interface that is potentially usable by multiple clients to interact with that Web service.
Client. In this document, the term "client" is used to indicate a role that is relative to a particular service. An agent that sends/receives a message to/from a service is called a client of that service. This use of the term "client" is not meant to imply any limitations on the capabilities of the agent that acts in a client role. For example, an agent might act as either a service or a client or both.
[Ed. note: Amy has suggested the term "counterparty" instead of "client", to avoid preexisting connotations that may be associated with "client".]
This document attempts to enable the rational comparison of patterns and pattern styles that make various kinds of message transfer assumptions.
Definition: Conservation of messages. For any one message that is sent by one node, one message is received by one node.
Definition: Message Pattern. A template for the exchange of messages between nodes. [Definition from http://dev.w3.org/cvsweb/~checkout~/2002/ws/arch/glossary/wsa-glossary.html]
Definition: Actual Message Sequence. An actual sequence of messages (not message types) that are exchanged between agents.
Every message pattern described below indicates at least:
Furthermore, in order to highlight differences between pattern styles, every pattern described below also indicates:
In addition, patterns with two or more messages between the same two nodes may indicate:
Finally, any pattern may also specify additional constraints expressed in prose.
Some patterns are related to each other by being more or less specialized versions of each other.
Definition: Pattern Specialization. A pattern p2 is a specialization of pattern p1 iff every actual sequence of messages that conforms to p2 also conforms to p1.
The modeling notation attempts to be precise and explicit about what assumptions are made. It attempts to be general enough to describe patterns that make loose or few assumptions (for example, patterns that do not assume conservation of messages) and precise enough to describe patterns that are much more tightly constrained (for example, patterns that do assume conservation of messages).
Patterns are modeled as pseudo-graphs, in which nodes correspond to message senders or message receivers (i.e., either Web services or clients), and arcs correspond to message transmissions:
1. A blue-filled circle represents a node: a double circle for a node acting as a Web service, a single circle for node acting as a client. A node may be labeled (such as "A", "B", "A1", or "S") or unlabeled. Labels are used to refer to specific nodes elsewhere.
2. A solid arc with one tail and one head indicates message transmission with conservation of messages. It indicates that a message is sent from one sender and received by one recipient.
3. A dotted arc with one tail and multiple heads indicates message transmission without conservation of messages. It indicates the transmission of a message from one sender to zero or more recipients.
4. An arc with no node at its tail indicates that the sender is unspecified. This is semantically equivalent to an arc with an unlabeled node at its tail.
5. An arc with no node at its head indicates that the recipient is unspecified. This is semantically equivalent to an arc with an unlabeled node at its head.
6. Black arcs indicate normal messages; red arcs indicate fault messages.
7. A numeric label on an arc indicates the relative ordering of message transmissions within a pattern. For example, the first message transmission is labeled 1, the second 2, etc. If two arcs are labeled with the same sequence number, then accompanying prose should indicate whether (a) both transmissions are intended to occur during that step; or (b) a choice of message transmissions.
Bear in mind that this modeling notation is used to describe templates for message exchanges that will be performed by actual software agents, and an actual software agent could assume the role of more than one node.
Example 1:
Non-conservation with specified clients
The following diagram illustrates a single message transmission, without conservation of messages, from specified sender S to zero or more specified receivers A1, A2, ... An.
[Image: example-non-conservation-with-specified-clients]
Example 2:
Non-conservation with unspecified clients
The following diagram illustrates a single message transmission, without conservation of messages, from specified sender S to zero or more specified receivers A1, A2, ... An.
[Image: example-conservation-with-unspecified-clients]
Since two arcs are labeled with the same sequence number (2), accompanying prose would have to indicate whether they represent a choice of messages in step 2 or that both messages must be sent in step 2.
Example 3:
Logical nodes versus physical agents
The following diagram involves three logical nodes: client A, client B and service S. Clients A and B are shown visually as separate nodes because a conforming instance of this pattern may use different software agents for A and B. However, A and B are not required to be different agents. A single software agent could, for example, play the roles of both A and B. In other words, A, B and S are variables that may have different values, but they are not required to have different values.
[Image: example-logical-nodes]
The following diagram illustrates a single request message sent from one unspecified client to service S, followed by a single message from service S to some other unspecified client -- not necessarily the same client that sent the original request. This example has exactly the same meaning as example 3 above.
[Image: example-unspecified-client]
This section presents several patterns that either (a) were described in PART2, (b) seemed interesting to someone, or (c) were included only for the purpose of analysis. Inclusion in this list does not imply endorsement or recommendation by this task force or the working group.
Patterns from PART2, and are so marked. Also, some patterns are specializations of other patterns; they are also marked. Note that this grouping of patterns will not necessarily form a hierarchy (though it would form a lattice), since one pattern could be a specialization of two patterns that are not specializations of each other.
This is the In-Only pattern of PART2.
Sequence:
1. A client sends a potentially-broadcast message that the service receives.
Recommended Disposition:
@ Delete? (Adequately covered by p1a.) @
Specialization of p1.
Sequence:
1. Client A sends a message to the service S.
Recommended Disposition:
@ Keep? @
Not a specialization of p1.
<operation
pattern="p1b">
<input>
<ofault>
</operation>
Sequence:
1. Client A sends a message to the service S.
2. (Optionally) Services S sends an ofault message back to client A.
Recommended Disposition:
@ Keep? @
This is the In-Out pattern of PART2.
Sequence:
1. A client sends a potentially-broadcast message that the service receives
2. Either: (a) the service sends a potentially-broadcast output message; or (b) the service sends a potentially-broadcast ofault message.
Comments: This pattern does not indicate that the output or fault message is to be returned to the same client that sent the input message.
Recommended Disposition:
@ Delete? (Adequately covered by others, below.) @
Specialization of p2.
Sequence:
1. Client A sends a message to service S.
2. Either: (a) service S sends a potentially-broadcast output message that is received by zero or more clients B1 ... Bn; or (b) service S sends an ofault message to client C.
Comments: This pattern does not indicate that the ofault message is to be returned to the same client that sent the input message.
Recommended Disposition:
@ Delete? (Better to have the fault return to A.) @
Specialization of p2a and p2.
Sequence:
1. Client A sends a message to service S.
2. Either: (a) service S sends a potentially-broadcast output message that is received by zero or more clients B1 ... Bn; or (b) service S sends an ofault message to client A.
Comments:
Recommended Disposition:
@ Keep? Potentially useful. But do we need this separate from p2d? @
Specialization of p2.
Sequence:
1. Client A sends a message to service S.
2. Either: (a) service S sends a potentially-broadcast output message that is received by zero or more clients B1 ... Bn; or (b) service S sends an ofault message that is received by zero or more clients B1 ... Bn.
Comments: This pattern does not indicate that the ofault message is to be returned to the same client that sent the input message.
Recommended Disposition:
@ Delete? (Better to have the fault return to A.) @
Specialization of p2a and p2.
Sequence:
1. Client A sends a message to service S.
2. Either: (a) service S sends a potentially-broadcast output message to client A and zero or more clients B1 ... Bn; or (b) service S sends an ofault message to client A.
Recommended Disposition:
@ Drop? @
Specialization of p2a and p2.
Sequence:
1. Client A sends a message to service S.
2. Either: (a) service S sends an output message to client B; or (b) service S sends an ofault message to client C.
Comments: No information is given about whether clients A, B and C are the same or different clients. Hence, this pattern does not indicate that the output or ofault message is to be returned to the same client that sent the input message.
Recommended Disposition:
@ Drop? The fault should go to A or B. @
Specialization of p2c in which "The Client is responsible for specifying the recipient address, and the client must agree with the Service about the mechanism by which it will be communicated.".
See http://lists.w3.org/Archives/Public/public-ws-desc-meps/2003Jul/att-0015/030714-ws-desc-irc.htm
.
Specialization of p2c in which " The Client is NOT responsible for specifying the recipient address. It's up to the service to decide on the recipient of the response.".
See http://lists.w3.org/Archives/Public/public-ws-desc-meps/2003Jul/att-0015/030714-ws-desc-irc.htm
.
Specialization of p2c, p2a and p2.
Sequence:
1. Client A sends a message to service S.
2. Either: (a) service S sends an ofault message to client A; or (b) service S sends an output message to client B.
Comments
This is a classic request / response to a third party. However, no information is given about whether clients A and B are the same or different clients.
Recommended Disposition:
@ Keep? Drop? Request/response to a third party. Can be modeled as two one-way messages. @
Specialization of p2c, p2a and p2.
Sequence:
1. Client A sends a message to service S.
2. Either: (a) service S sends an ofault message to client B; or (b) service S sends an output message to client B.
Comments
This is a request with both the response and the optional ofault directed to a third party. No information is given about whether clients A and B are the same or different clients.
Recommended Disposition:
@ Drop? @
Specialization of p2d1, p2d, p2c, p2a and p2.
Sequence:
1. Client A sends a message to service S.
2. Either: (a) service S sends an output message to client A; or (b) 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.
Recommended Disposition:
@ Keep? Classic request/response. @
This pattern was described by Amy in http://lists.w3.org/Archives/Public/public-ws-desc-meps/2003Jun/0021.html , and does not explicitly model the faults.
Sequence:
Ignoring faults,
1. Client A sends a potentially-broadcast message that is received by service S.
2. Service S sends an output message to client B.
Recommended Disposition:
@ Drop? @
This is the Request-Response pattern of PART2.
Specialization of p2.
<operation
pattern="p3">
<input>
<output>
<ofault>
</operation>
Sequence:
1. A client sends a potentially-broadcast message that the service receives.
2. On the same "channel" as the received message, the service sends either: (a) a potentially-broadcast output message; or (b) a potentially-broadcast ofault message.
Comments:
[dbooth notes: The current description of Request-Response
pattern in PART2 constrains the output and
ofault messages to be on the same channel as the input message.
This is quite different from simply specifying that the output and ofault
messages are to be sent back to the same client where the input
originated. Depending on what is meant by "on the same
channel", this pattern may or may not indicate that the output or fault
message is to be returned to the same client that sent the input message. ]
Recommended Disposition:
@ Drop in favor of p2e? @
This is the In-Multi-Out pattern of PART2.
Sequence:
1. A client sends a potentially-broadcast message that the service receives
2. The service sends zero or more potentially-broadcast output messages
3.Optionally, the service sends a potentially-broadcast ofault message.
Comments: This pattern does not indicate that the output or ofault messages are to be returned to the same client that sent the input message.
Recommended Disposition:
@ Drop? @
Specialization of p4.
Sequence:
1. Client A sends a message to service S.
2. Service S sends zero or more output messages to clients B1 . . . Bn.
3.Optionally, service S sends an ofault message to client C.
Comments: Clients A, B1 ... Bn and C may be the same or different clients. Hence, this pattern does not indicate that the output or ofault messages are to be returned to the same client that sent the input message.
Recommended Disposition:
@ Drop? @
Specialization of p4a and p4.
Sequence:
1. Client A sends a message to service S.
2. Service S sends zero or more output messages to client A.
3.Optionally, service S sends an ofault message to client A.
Comments: Clients A, B1, ... Bn and C may be the same or different clients. Hence, this pattern does not indicate that the output or ofault messages are to be returned to the same client that sent the input message.
Recommended Disposition:
@ Keep? @
Specialization of p4a and p4.
Sequence:
1. Client A sends a message to service S.
2. Service S sends zero or more output messages to clients B1 ... Bn.
3.Optionally, service S sends an ofault message to client A.
Recommended Disposition:
@ Drop in favor of p2d? (Who cares if other clients also receive messages?) @
[dbooth notes: This seems to be a duplicate of p4c. I'm not sure what I intended this to be.]
Specialization of p4d, p4a and p4.
Sequence:
1. Client A sends a message to service S.
2. Service S sends zero or more output messages to client A.
3.Optionally, service S sends an ofault message to client A.
Recommended Disposition:
@ Keep? (The client needs to know whether to expect 0 to n messages.) @
This is the Out-Only pattern of PART2.
Sequence:
1. The service sends a potentially-broadcast message.
Comments: The number of recipients is unspecified.
Recommended Disposition:
@ Drop? (Who cares if other clients may receive the message?) @
Specialization of p5.
Sequence:
1. Service S sends a message to client A.
Recommended Disposition:
@ Keep? @
Specialization of p5 that "mandates (rather than leaving undefined) the multicast nature of the OUT message".
See http://lists.w3.org/Archives/Public/public-ws-desc-meps/2003Jul/0022.html .
Variation of p5. However, instead of including no faults, the "message triggers fault" rule is used.
See http://lists.w3.org/Archives/Public/public-ws-desc-meps/2003Jul/0022.html .
Specialization of p5f that is "unicast; a fault is returned if the receiving node detects the need".
See http://lists.w3.org/Archives/Public/public-ws-desc-meps/2003Jul/0022.html .
Specialization of p5f that is "multicast: each receiving node may return a fault".
See http://lists.w3.org/Archives/Public/public-ws-desc-meps/2003Jul/0022.html .
This is the Out-In pattern of PART2.
Sequence:
1. Service S sends potentially-broadcast a message that is received by 0 or more clients.
2. Either: (a) A client sends a potentially-broadcast message that is received by the service (among possibly others); or (b) a client sends a potentially-broadcast ofault that is received by the service.
Recommended Disposition:
@ Drop? @
Specialization of p6.
Sequence
1. Service S sends an output message to client A.
2. Either: (a) Service S receives an input message from
client B; or (b) service S receives an ifault from client C.
Comments: No information is given about whether clients A, B and C are the same or different clients.
Recommended Disposition:
@ @
Sequence:
1. Service S sends an output message to client A.
2. Either: (a) Service S receives an input message from client A; or (b) Service S receives an ifault from client A.
Comments: This is classic "solicit-response".
Recommended Disposition:
@ @
This is the Out-Multi-In pattern of PART2.
@@ unfinished. Not yet converted to the new notation. @@
<operation
pattern="p7">
<output>
<input>
<fault>
</operation>
Recommended Disposition:
@ @
Specialization of p7.
@@ Description unfinished @@
Recommended Disposition:
@ @
Specialization of p7a and p7.
Sequence
1. Service S sends an output message to client A.
2. Service S receives zero or more input messages from client A.
3. Optionally, service S receives an ifault message from client A.
Recommended Disposition:
@ @
Specialization of p7a and p7.
@@ Description unfinished @@
Recommended Disposition:
@ @
This is the Multicast-Solicit-Response pattern of PART2.
Sequence:
1. The service sends a potentially-broadcast message.
2. Zero or more occurrences of the following happen:
a. Either:
i. The service receives a potentially-broadcast message;
ii. The service receives a potentially-broadcast message and then sends a potentially-broadcast ofault; or
iii. The service receives a potentially-broadcast ifault.
[dbooth notes: Is this correct? The description of Multicast-Solicit-Response pattern in PART2 (the second bullet item in particular) is quite confusing, and I don't know if I got it right. I am assuming that where it says "One or two messages" it means "(one output) or (one output followed by one ifault)", although that isn't clear. If so, it seems to indicate:
output, ( ( input | (input, ofault)) | ifault )*
which, after removing some unnecessary parentheses, is the same as:
output, ( input | (input, ofault) | ifault )*
]
Comments: Clients A, B1, ... Bn and C may be the same or different clients. Hence, this pattern does not indicate that the output or ofault messages are to be returned to the same client that sent the input message.
Recommended Disposition:
@ @
Specialization of p8.
@@ Description unfinished @@
Recommended Disposition:
@ @
Specialization of p8a and p8.
@@ Description unfinished @@
Recommended Disposition:
@ @
Specialization of p8.
@@ Unfinished @@
@@ Description unfinished @@
Recommended Disposition:
@ @
Specialization of p8c and p8.
Sequence:
1. Service S sends a potentially-broadcast message that is received by zero or more clients, A1 ... An.
For each client Ai that received the message and chooses to respond to it:
a. Either:
i. (2) Client Ai sends a message to S;
ii. (2) Client Ai sends a message to service S, and (3) service S responds by sending an ofault to Ai; or
iii. (2) Client Ai sends an ifault to S;
Recommended Disposition:
@ @
@@ This section is not been updated with the new pattern numbers yet @@
This is not intended to be an exhaustive set of use cases. These are only use cases that seem relevant for illustrating the differences between using IOPs and MEPs at the WSDL interface/portType level.
BigCo has just informed all of its suppliers that they must provide Web services. BigCo supplies an abstract WSD, which each supplier must implement. BigCo wishes to use a simple, uniform classic request-response pattern (p2e) to interact with all suppliers, regardless of the transport protocols that they support. Individual suppliers will use the abstract WSD as a basis for their own WSDs, which will add the transport bindings that they support and their service URI. Some transport bindings use HTTP; others use email.
Case 1: Suppose the WSDL
interface/portType represents p2e
WSDL interface/portType:
<interface name="SupplierInterfaceP2E">
<operation name="getPrice" pattern="p2e">
<input type=PriceRequestMessage />
<output type=PriceResponseMessage />
</operation>
</interface>
The BigCo Client App programmer feeds the WSDL interface/portType description into a tool and generates the following (pseudo) code interface:
interface SupplierInterfaceP2E
{
// p2e:
PriceResponseMessage getPrice(PriceRequestMessage);
}
Next, the programmer gets the specific WSDs for all of the suppliers. The suppliers' WSDs reference the common WSDL interface/portType definition, but also supply specific bindings for the transports that they support, such as:
<binding>
??? // Email binding
</binding>
<binding>
??? // HTTP binding
</binding>
The programmer feeds each supplier-specific WSD into a tool to automatically generate a class that implements SupplierInterface. That class contains the binding-specific implementations for the particular transports that the supplier supports.
Finally the programmer writes the following method to find the best price for a part over all suppliers, not knowing or caring what kind of transports are used:
Price findBestPriceMEP2b(Part part)
{
PriceRequestMessage req = new PriceRequestMessage(part);
Suppliers suppliers = lookupSuppliers(...);
Price bestPrice = infinity;
foreach s in suppliers
{
// s will handle transport details
PriceResponseMessage m = s.getPrice(req); // p2e
if m.price < bestPrice { bestPrice = p }
}
return bestPrice
}
Case 2: Suppose the WSDL
interface/portType represents p2
WSDL interface/portType:
<interface name="SupplierInterfaceP2">
<operation name="getPrice" pattern="p2">
<input type=PriceRequestMessage />
<output type=PriceResponseMessage />
</operation>
</interface>
The BigCo Client App programmer feeds the WSDL interface/portType description into a tool and generates the following (pseudo) code interface:
interface SupplierInterfaceP2
{
// p2:
void sendPriceRequest(PriceRequestMessage);
PriceResponseMessage receivePriceResponse(); // ????
}
Again, the programmer feeds each supplier-specific WSD into a tool to automatically generate a class that implements SupplierInterface. That class contains the binding-specific implementations for the particular transports that the supplier supports.
Then the programmer writes the following method to find the best price for a part over all suppliers:
Price findBestPriceP2(Part part)
{
PriceRequestMessage req = new PriceRequestMessage(part);
Suppliers suppliers = lookupSuppliers(...);
Price bestPrice = infinity;
foreach s in suppliers
{
// s will handle transport details
s.sendPriceRequest(req);
PriceResponseMessage m = s.receivePriceResponse(); // p2
// Oops!!! m is not necessarily in response to req!!!
// (Other requests might have been sent by different threads.)
if m.price < bestPrice { bestPrice = p }
}
return bestPrice
}
Tomato Buyers and Sellers Association wishes to define an abstract WSD that describes standard interaction patterns between tomato buyers (as clients) and sellers (as Web services). Most of these interactions are simple request-response patterns (p2e). Individual tomato sellers will use the abstract WSD as a basis for their own WSDs, which will add the transport bindings that they support and their service descriptions.
@@ Unfinished. Not yet updated with new pattern numbers @@
XCo has a Web service that it provides for its clients. YCo has a Web service that it provides for its clients. XCo and YCo wish to interact as peers. Each application acts as a client to the other's Web service.
YCo models its interaction with XCo as a classic
request-response pattern (p2e):
XCo models its interaction with YCo as a simple solicit-response
pattern (MEP #5b):
They wish to ensure that their applications will properly interact. Since the abstract parts of their WSDs are the complements of each other, it is easy to compare them mechanically, to ensure that they are compatible.
@@ Unfinished. Not yet updated @@
[dbooth: I think this needs to be updated to reference MEP#8c instead, because the definition of IOP#7 above is not what Amy had originally intended.]
IntrepidCo wants to announce additions to its inventory, and allow responses to reserve product. It creates a simple WSD which will require a publish/subscribe model, using IOP 7. The binding specifies MEP 7A using a simple encapsulation protocol over IP multicast. Business partners retrieve the WSDL, and set up an IP multicast listener on the specified endpoint.
@@ Unfinished. Not yet updated @@
[dbooth: I think this needs to be updated to reference MEP#8c instead, because the definition of IOP#7 above is not what Amy had originally intended.]
MegaMucketyBigCo mandates web service usage inside the firewall. After the failure of centralized registries, a system of discovery is adopted instead. Each service is associated with a client stub, which is equipped with a WSDL describing a discovery service. Any service may discover any other (adopting the role of THE service for this particular WSDL/operation) by sending a solicitation on the advertised channel (some enterprise-class messaging system). The associated client stubs all listen to this channel, and respond when they see a request that matches their associated service.
http://www.w3.org/2003/03/An_interesting_MEP.html
@@
[End]