- From: M. Jones <sweetidad@yahoo.com>
- Date: Thu, 23 Jan 2003 10:09:41 -0800 (PST)
- To: www-archive@w3.org
- Cc: jones@research.att.com
(sorry I'm having to use my freemail account due to firewall issues) This is some prose that I wrote up to summarize some owrk done in a break out session at the face-to-face yesterday on MEPs, web services stack layering, etc. Mark Jones AT&T jones@research.att.com ___________________________________ Distributed applications in a Web services architecture communicate via message exchanges. These message exchanges are logically factored into patterns that compose at different levels. These patterns can be descibed 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, the message exchange pattern (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 associate instance of MEPs with particular operations from the perspective of a particular service node. 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 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. Conceptually, the choreographic level can enforce constraints on message order, maintain state consistency, communicate choreographic faults to the application, etc. __________________________________________________ Do you Yahoo!? Yahoo! Mail Plus - Powerful. Affordable. Sign up now. http://mailplus.yahoo.com
Received on Thursday, 23 January 2003 13:10:12 UTC