Message Exchange Patterns
Versus
Input/Output Patterns
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.24 $ of $Date: 2003/07/21 05:07:34 $ by $Author: dbooth $
Table of Contents
- Introduction
- Patterns
-
- Pattern p1
- Pattern p1a
- Pattern p1b
- Pattern p2
- Pattern p2a
- Pattern p2a1
- Pattern p2a2
- Pattern p2b
- Pattern p2c
- Pattern p2c1
- Pattern p2c2
- Pattern p2d
- Pattern p2d1
- Pattern p2e
- Pattern p2umci-7
- Pattern p3
- Pattern p4
- Pattern p4a
- Pattern p4c
- Pattern p4d
- Pattern p4e
- Pattern p5
- Pattern p5a
- Pattern p5b
- Pattern p5f
- Pattern p5f1
- Pattern p5f2
- Pattern p6
- Pattern p6a
- Pattern p6b
- Pattern p7
- Pattern p7a
- Pattern p7b
- Pattern p7c
- Pattern p8
- Pattern p8a
- Pattern p8b
- Pattern p8c
- Pattern p8d
- Use Cases that Illustrate Differences Between Patterns
- Pattern Pros and Cons
- Recommendations
Status of This Document
No official standing. Comments are welcome.
Introduction
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
- This TF will describe pros and cons of various patterns, and make suggestions to the WG about which patterns to adopt.
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)
Assumptions: Purpose of a Web Service Description (WSD)
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.
Terminology
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".]
Modeling Objective
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:
- the (partial) ordering of messages within the sequence
- the direction of each message relative to a service node
- the cardinality of each message, i.e., the number of messages sent (though not necessarily the number of recipients), either as a constant or a variable.
Furthermore, in order to highlight differences between pattern styles, every pattern described below also indicates:
- whether or not a particular message transmission assumes conservation of messages
- whether or not the sender/receiver of a message is specified (as a variable)
In addition, patterns with two or more messages between the same two nodes may indicate:
- whether or not the message communication is restricted to being "on the same channel".
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.
Modeling Notation
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]
 |
Patterns
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.
Pattern p1
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.) @
Pattern p1a
Specialization of p1.
 |
Sequence:
1. Client A sends a message to the service S.
Recommended Disposition:
@ Keep? @
Pattern p1b
Not a specialization of p1.
 |
|||
|
|||
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? @
Pattern p2
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.) @
Pattern p2a
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.) @
Pattern p2a1
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? @
Pattern p2a2
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.) @
Pattern p2b
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? @
Pattern p2c
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. @
Pattern p2c1
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 .
Pattern p2c2
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 .
Pattern p2d
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. @
Pattern p2d1
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? @
Pattern p2e
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. @
Pattern p2umci-7
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? @
Pattern p3
This is the Request-Response pattern of PART2.
Specialization of p2.
 |
|||
|
|||
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? @
Pattern p4
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? @
Pattern p4a
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? @
Pattern p4c
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? @
Pattern p4d
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?) @
Pattern p4e
[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.) @
Pattern p5
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?) @
Pattern p5a
Specialization of p5.
 |
Sequence:
1. Service S sends a message to client A.
Recommended Disposition:
@ Keep? @
Pattern p5b
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 .
Pattern p5f
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 .
Pattern p5f1
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 .
Pattern p5f2
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 .
Pattern p6
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? @
Pattern p6a
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:
@ @
Pattern p6b
 |
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:
@ @
Pattern p7
This is the Out-Multi-In pattern of PART2.
@@ unfinished. Not yet converted to the new notation. @@
 |
|||||
|
|||||
 |
|||||
Recommended Disposition:
@ @
Pattern p7a
Specialization of p7.
@@ Description unfinished @@
Recommended Disposition:
@ @
Pattern p7b
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:
@ @
Pattern p7c
Specialization of p7a and p7.
 |
@@ Description unfinished @@
Recommended Disposition:
@ @
Pattern p8
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:
@ @
Pattern p8a
Specialization of p8.
@@ Description unfinished @@
Recommended Disposition:
@ @
Pattern p8b
Specialization of p8a and p8.
 |
@@ Description unfinished @@
Recommended Disposition:
@ @
Pattern p8c
Specialization of p8.
@@ Unfinished @@
@@ Description unfinished @@
Recommended Disposition:
@ @
Pattern p8d
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:
@ @
Use Cases that Illustrate Differences Between IOPs and MEPs
@@ 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.
UC1: Client Defines Abstract WSD [dbooth]
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
}
UC2: Abstract WSD Defined by Industry Organization [dbooth]
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.
 |
UC3: Peer to Peer Interaction [dbooth]
@@ 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.
UC4: Use Case for IOP #7 [alewis]
@@ 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.
UC5: Alternate Use Case for IOP #7 [alewis]
@@ 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.
UC6: An Interesting Pattern [Gudge & Jeffrey]
http://www.w3.org/2003/03/An_interesting_MEP.html
Pattern Pros and Cons
- @@
Recommendations
@@
[End]