Message Exchange Protocols for Web Services
Satish Thatte
Microsoft Corporation
[email protected]
+1(425)703-4326
© 2001 Microsoft Corporation. All rights reserved.
Note: The W3C-Document-License was
granted
This paper discusses the problem of specifying the message exchange behavior among the parties in a business process. The specification of such behavior is set in the context of an overall web services framework in which complementary and supporting specifications are provided. The paper covers the requirements for specifying the behavior of a single web service and also discusses the possibilities for specification and verification of multi-role business protocols.
The universal inexpensive connectivity offered by the internet has triggered a wave of innovation and investment. The business world is racing to take advantage of this new opportunity to communicate instantly with customers and partners. In the initial stages this was limited to a web presence that served primarily to offer instant access to information. The focus is now shifting to web services that offer access points for automated systems to communicate with each other in real time across business boundaries. The vocabulary of communication is moving to sophisticated and flexible XML business documents and protocols.
In parallel with this, there has been a strong movement to take advantage of advances in information technology within enterprises to speed up business processes and decision making, and to offer responsive service to customers and partners. Such nimbleness is in fact now the hallmark of a competitive “zero latency” business enterprise.
The coming together of these two trends has created enormous opportunities and pressures for automation of business processes across business boundaries, in areas ranging from health insurance claims processing [1] to securities trade settlement [2].
Business process automation within an enterprise requires workflow systems that allow the definition, execution and monitoring of automated long-running processes to coordinate the activities of multiple business applications. Process definition in this context does not usually attempt to separate implementation from abstract process description. The situation is very different when processes span business boundaries, since the independent parties involved in the process do not share application and workflow implementation technologies and will normally not allow external control over the use of their backend applications.
Cross-enterprise process automation requires formalized business protocols focusing on their externally visible “wire” behavior. This includes a number of somewhat independent aspects.
The RosettaNet Partner Interface Processes™ (PIPs™) [6] along with the RosettaNet Implementation Framework (RNIF) exemplify the current state of the art in business protocol specification. A major limitation of PIPs™ and similar current protocol specifications is that these are essentially “paper specifications”. They are meant to be used for human understanding and human-mediated enforcement. As business protocols proliferate and evolve more rapidly, the social processes necessary for dissemination, common understanding and enforcement of paper protocols will break down as a result of their inability to scale, and progress will be halted unless the specification of protocols is formalized to the point where their enforcement can be largely if not entirely automated. Such a notation must be executable in that it must be able to serve as the basis for automated protocol enforcement engines that can track the state of protocol instances and detect protocol errors in message flows. This should be the primary motivation driving the development of a standard for message exchange protocols for web services.
As pointed out in the companion overview paper titled “Web Services Framework,” there are significant benefits in decomposing the specification of the various functionality elements required for building rich web services. Avoiding a monolithic specification permits compliant specifications that need only a subset of the complete functionality, and avoids the creation of overlapping mutually incompatible “silos” of domain-specific standards by separating logically common pieces into modular composable specifications. In that spirit, this paper focuses solely on the problem of specifying the message exchange behavior among the parties in a business process, that is to say the last item in the list of aspects discussed above. There is an obvious relationship with and dependency on specifications that solve the other problems, which are labeled as “Service Description” in the Web Services Framework. The WSDL specification [7] provides a concrete example of a service description notation.
In the next section, we discuss the requirements for the description of the message exchange behavior of a single web service, which can be thought of as a single role in a multi-role business protocol. The combination of services in business protocols is discussed in a subsequent section.
In this section, we use a simple scenario to motivate the requirements discussion. Consider a corporate Travel Arrangements Web Service (TAWS) that aggregates the web services of providers of car, hotel and airline reservations. TAWS has multiple service descriptions, one for customers and one or more for providers.
The customer protocol allows access to both registered and new customers. Registered customers can use defaults based on known profile information. To the customer, car, hotel and airline reservation are presented as parallel activities—the customer is free to switch between them at will. The process of making a travel plan is considered a long-running interaction. TAWS maintains the itinerary for each travel plan and provides modification and cancellation time windows and processes for each leg of travel and each service. The option of canceling the entire itinerary is always available. There may be penalties or fees applied for cancellation and modification depending on the timing. Being an internal corporate service, TAWS also allows its customers to ask for payroll advances to pay for travel. This is especially helpful when travel arrangements must be made considerably in advance of actual travel, and paid for using corporate credit cards issued to employees. When such an itinerary is cancelled, the refunds on the cards must be reflected in corresponding payroll deductions.
The provider protocols use simple request/response interactions initiated by TAWS. TAWS imposes latency constraints and will time out requests in order to provide a responsive interface to its clients. A timeout may lead to a provider switch, or there may be a retry protocol (with backoff intervals) when the provider has already been fixed as a result of an existing reservation—for instance when a reservation needs to be modified or cancelled.
In some cases there is a need for multiparty protocols, as when an airline paper ticket must be delivered physically by an overnight letter delivery service. In this case TAWS refers the overnight service requested by the client to the airline service provider and helps track the delivery via delivery tracking ids.
We assume that business protocols are constructed from atomic message exchange operations. These operations may be one-way messages or request/response operations, and they may be either incoming or outgoing from the web service concerned. Each operation uses designated message type(s).
The basic sequencing of operations is obviously the core of the message exchange behavior. We highlight some salient control construct requirements below.
Common looping and conditional constructs are needed for the specification of essential behaviors such as retry loops and conditional behaviors based on the results of previous operations. For instance, if a TAWS customer invokes a registered profile the reservations process may take a shortcut bypassing a number of queries.
Concurrency constructs are needed to permit specification of potentially parallel activities. For instance, consider a TAWS customer working in parallel on her car, hotel and airline reservations, using the delays in responses from each provider to make progress on other reservations. Specifying this as all possible interleaving sequences of operations is clearly impractical. Specifying the customer protocol as a set of concurrent activities is far more natural.
Event-based choice is needed to account for alternatives driven by external events. The simplest example is the arrival of either a response from a TAWS service provider or a time signal—the race between the two constitutes a timeout constraint. Timeouts may be common enough to be provided as a primitive but event-based choice as a base construct is needed to ensure that other usage patterns such as cancellation windows can be explicitly coded.
In addition to the basic control constructs, there are a number of complex patterns that occur in business protocols over and over again, and they are important enough to require native support in any practical message exchange protocol specification standard. Several of these are discussed below.
A transaction is normally viewed as an atomic consistency-preserving state update. ACID database transactions have this characteristic along with the guarantee that in case of any failure during the transactional update the partial update will be rolled back and its effects erased. Long running business processes require a different and somewhat looser notion of transaction (often called a business transaction) in which individual steps may be ACID transactions but the overall business transaction may fail or may be cancelled for a variety of business and technical reasons and the partial work done during its progress must be compensated for as best as possible.
For instance the planning and fulfillment of an itinerary can be viewed as a long running transaction in which individual service reservation actions may use ACID transactions at TAWS and at the providers. In case the itinerary is cancelled the reservation transactions must be compensated for by cancellation transactions, and the corresponding payment transactions must be compensated accordingly as well. For ACID transactions in databases the transaction coordinator(s) know all of the uncommitted updates, the order in which they must be reversed, and are in full control of such reversal. In the case of business transactions, the compensation behavior is itself a part of the business protocol and must be explicitly specified. For instance, a reservation must be successfully cancelled before the payroll advance for it can be reversed in the form of a payroll deduction. This means the compensation actions run in the same order as the original transactions, which is not the standard or default in most systems. Moreover, information such as cancellation confirmation codes and refund amounts may need to be transmitted from the compensation for the reservation to the compensation for the payroll advance to make the latter effective.
It is important to design the long-running transaction feature of the message exchange protocol standard to account for these realistic scenarios involving nested transactions and complex compensation behavior. Note that exception handling is a core part of long-running transactions—a cancellation can be viewed as an exception, and would probably be treated as such in the protocol.
The use of correlation ids to track the flow of related messages is a common technique used in message-based systems. Correlation maintenance is a requirement in business protocols and as such must be made explicit in the protocol specification. Correlation is in essence a specification of a set of tokens carried in messages and a set of messaging actions in which messages carry and preserve the specific values of these tokens that were set by the initial message in the correlated exchange.
Correlation patterns can become quite complex. Specifically, the scope of correlation is not in general the entire business transaction specified by a protocol but may span a part of the transaction. In fact, correlated exchanges within a protocol may nest and overlap, and messages may in general carry several sets of correlation tokens. For instance, the interaction between TAWS and a customer for a specific service being reserved as part of an itinerary may carry correlation tokens that identify the specific service request being negotiated. These tokens may be used by TAWS to route these interactions to the appropriate internal service instance handling the specific request. The same messages will also very likely carry tokens representing the itinerary as a whole, for the benefit of state maintenance and other composite services, as well as for use with global actions such as itinerary cancellation.
Consider the overnight ticket delivery part of the TAWS scenario. In this case TAWS refers the delivery service requested by the client to the airline service provider and helps the customer track the delivery via delivery tracking ids. The airline service requests ticket pickup by the delivery service directly. The delivery service notifies TAWS when the ticket has been delivered and TAWS then forwards payment to the airline on behalf of the customer (this is only an example—in real life the airline would probably demand prepayment). In general, the airline service need have no prior knowledge of the delivery service. So long as the latter follows a standardized delivery service protocol, all that is needed by the airline service is a service endpoint referral which may be embedded in a message sent to it by TAWS.
Given the three way interaction required between TAWS, the airline service and the delivery service to complete the airline service request, the dynamic referral of the delivery service must be an explicit part of the protocol. This example also illustrates that business transactions are increasingly likely to involve more than two parties, and this must be provided for in the message exchange protocol standard.
We believe that although cross-enterprise business protocols are in general fairly simple today due to lack of infrastructure to handle specification and control of complex protocols spanning many business entities, this situation is not likely to last, especially if we are successful in defining a web services framework that allows substantial automation of discovery, implementation and enforcement. We must apply the lessons of ordinary software development to allow for composition of protocols to build larger more complex protocols.
All of the feature discussion above has focused on the specification of the behavior of a single business entity, even though the motivating TAWS example is cast in terms of cooperating entities. Specification and modeling of multiple interacting roles is not new—for instance it is addressed in UML interaction diagrams [8]. Sequence diagrams in particular are extremely useful for visualizing the way the behavior of multiple roles is tied together and some of the time sequencing aspects of that behavior. Their weakness is that they completely flatten the structure of the behavior of each role, and are moreover primarily a visualization tool.
Ideally, we would like to have it both ways. We would like a highly expressive notation to capture realistic protocol description for each interacting role as discussed above, and we would also like to put together multi-role contracts that describe the coupling of such roles in full business protocols as in the TAWS example. We can indeed do this but we lose verifiability of well-formedness of the contract in the sense that we cannot ensure that if each role behaves correctly according to its own description then there will be no protocol errors in their interaction. The problem of making this determination is undecidable given the expressive power we require for describing each role.
Given this difficulty, verification of well-formedness of contracts in the sense above must be a manual activity. There may be the possibility of using a weaker notion of well-formedness in which the behavior of each role is described less precisely in the form of a finite state automaton (FSA). Think of this as a sort of “type constraint” on the behavior of the role. The type constraint satisfied by each role can be derived automatically from its full description, and the compatibility of such FSAs can very probably be decided in a tractable way to provide a form of “type-checking” of multirole contracts. Although this is somewhat speculative at this point it is likely to be useful enough to be worth investigation as part of the protocol description standardization effort.
[1] The Health Insurance Portability and Accountability Act of 1996 http://www.hcfa.gov/hipaa/hipaahm.htm
[2] SIA T+1: Streetside Processing Committee Whitepaper http://www.sia.com/t_plus_one_issue/pdf/streetsidepaper.pdf
[3] XML-Signature Syntax and Processing http://www.w3.org/TR/xmldsig-core/
[4] S/MIME Version 3 Message Specification http://www.ietf.org/rfc/rfc2633.txt
[5] Web Services Framework—companion paper.
[6] RosettaNet Standards http://www.rosettanet.org/
[7] WSDL 1.0 http://msdn.microsoft.com/xml/general/wsdl.asp
[8] Unified Modeling Language (UML) http://www.omg.org/technology/documents/formal/unified_modeling_language.htm