- From: <jones@research.att.com>
- Date: Fri, 27 Jun 2003 12:46:47 -0400 (EDT)
- To: dmh@contivo.com, www-ws-arch@w3.org
From: Dave Hollander <dmh@contivo.com> To: www-ws-arch@w3.org Date: Fri, 27 Jun 2003 09:04:47 -0700 Subject: RE: MEP text Thanks Mark. I have one big concern. > a message exchange pattern may be expressed > in a choreography description language. I fear that this may end up in circular difinition. I expect that Choreography will need to ground upon the definition MEP's. It would only be circular if we said that choreography was subsumed by MEPs, which it is not. The way I see it, MEPs talk in terms of the messages exchanged at a a rather atomic binding/operation level. Choreography builds on the foundation that the MEPs provide. Since one-way messages can also be simple MEPs in their own right, you can potentially express MEPs such as request-response in a choreography language. You would not typically want to do so for things like the SOAP HTTP request-response binding, but you might use choreography to describe an asynchronous request-response rendezvous that uses a SOAP module for callbacks. I am assuming that MEPs describe the arrows in the diagram, not the entire diagram. If not, wouldn't it be clearer to use the word MEP in (2) and (3)? eg: B then uses an MEP to send a separate ... Yeah, since an MEP is a message and its response(s), I was using message and MEP rather interchangeable in (2) and (3). That could be tightened up. ------------------------------ A------------>B \ | \ (3) | (2) \ V --------->C In this pattern: (1) node A uses an MEP (possibly request-response) to communicate initially with B. (2) B then sends a separate, but related message to C. (3) Node A sends another message to C but gets a reply only after C has processed (2). ----------------------------------------------------- I also have a few minor concerns: I inherited both of the following clauses from the original text and left them in. > a message exchange pattern has > a unique identifier There may some merit in keeping this, particularly if the WSDL group uniquely identifies its various patterns. Shouldn't that be "may have"? > a message exchange pattern is > the life cycle of a message exchange I would just as soon lose this one altogether. Is "life cycle" defined somewhere? I doubt there is any widespread understanding of a precise difinition for life cycle. I know I would have difficulty defining when the life cycle ends for a "message exchange". In one sense, the message exchange within this wg will span the entire existance of the WG. I would make the same assumption in thinking about two agents and their message exchanges. daveh Mark Jones AT&T -----Original Message----- From: Mark Jones [mailto:jones@research.att.com] Sent: Friday, June 27, 2003 8:49 AM To: www-ws-arch@w3.org Subject: MEP text Per my action item to flesh out section 2.2.22 on MEPs, here is a new synthesis of my January f2f MEP text with the current doc structure. It includes a discussion of MEPs at both the binding/operation level and the choreography level. It also includes both the SOAP and WSDL perspectives on MEPs. Finally, there is an example to motivate the choreography issues and a stab at a layering discussion. Some of the material can be moved elsewhere for editorial purposes. Mark Jones AT&T ================================================================ 2.2.22 Message Exchange Pattern (MEP) 2.2.22.1 Summary A message exchange pattern is a minimal set of messages, together with their sender and receivers, that constitutes a single use of a service. 2.2.22.2 Relationships to other elements a message exchange pattern is set of messages between agents that corresponds to a single instantiation of a service a message exchange pattern is a feature of the architecture a message exchange pattern has a unique identifier a message exchange pattern is the life cycle of a message exchange a message exchange pattern describes the temporal and causal relationships, if any, of multiple messages exchanged in conformance with the pattern. a message exchange pattern describes the normal and abnormal termination of any message exchange conforming to the pattern. a message exchange pattern may be expressed in a choreography description language. a message exchange pattern may realize message correlation a message exchange pattern may describe a service invocation. 2.2.22.3 Description Distributed applications in a Web services architecture communicate via message exchanges. A Message Exchange Pattern (MEP) is a template that establishes a pattern for the exchange of (one-way) messages between agents. These message exchanges are logically factored into patterns that may compose at different levels. These patterns can be described by state machines that indicate the flow of the message, the handling of faults that may arise, and the correlation of messsages. At the SOAP messaging level, an MEP refers to an exchange of messages in various invoking-response patterns. Each message at this level may travel across multiple transports en route to its destination. A message and its response(s) are correlated, either implicitly in the underlying protocol (e.g., request-response in HTTP) or by other correlation techniques implemented at the binding level. The exchanges may be synchronous or asynchronous. An asynchronous exchange involves some form of rendezvous to associate the message and its responses, typically due to separate invocations of the underlying transport or to long response time intervals. Web service description languages at the level of WSDL view MEPs from the perspective of a particular service node. A simple request-reponse MEP, for example, appears as an incoming message which invokes an operation and an associated outgoing message with a reply. Extremely simple applications based on single message exchanges may be adequately characterized at the operation level. More complex applications require multiple, related message exchanges; choreography describes patterns where the units of communication are themselves instances of MEPs. Especially at this higher level of abstraction, the communicating nodes are seen as peers which play various roles in more complex applications. These choreographic patterns form the communication structure of the application. Consider the following simple structure: (1) A------------>B \ | \ (3) | (2) \ V --------->C In this pattern: (1) node A uses an MEP (possibly request-response) to communicate initially with B. (2) B then sends a separate, but related message to C. (3) Node A sends another message to C but gets a reply only after C has processed (2). The example makes it clear that the overall pattern can't be described from the perspective of any single node. The pattern involves constraints and relationships among the various messages. It also illuminates the fact that exchange (1) is in in-out MEP from the perspective of node B, and mirrored by an out-in MEP from the perspective of node A. Finally, an actual application instantiates this communication pattern and completes the picture by adding computation at A, B and C to carry out application-specific operations. The following stack roughly captures the typical layering described above: application | | (application instantiates some choreographic structure | and provides message content) V choreography | | (application + choreography yields an XML Infoset, | attachments, and messaging features including the | MEP) V message transport binding | | (the binding produces a serialization, implements | required features, manages MEP-level coordination | for associating request/responses, etc.) V transfer/transport protocol It is instructive to consider to consider the kinds of fault reporting that occur in such a layering. Consider a fault at the transport protocol level. This transport level may itself be able to manage certain faults (e.g., re-tries), but it may also simply report the fault to the binding level. Similarly the binding level may manage the fault (e.g., by re-initiating the underlying protocol) or may report a SOAP fault. The choreography and application layers may be intertwined or separated depending on how they are architected. There is also no rigid distinction between the choreography and binding layers; binding-level MEPs are essentially simple choreographies. Conceptually, the choreographic level can enforce constraints on message order, maintain state consistency, communicate choreographic faults to the application, etc. in ways that transcend particular bindings and transports.
Received on Friday, 27 June 2003 12:46:39 UTC