The Cover PagesThe OASIS Cover Pages: The Online Resource for Markup Language Technologies
SEARCH | ABOUT | INDEX | NEWS | CORE STANDARDS | TECHNOLOGY REPORTS | EVENTS | LIBRARY
SEARCH
Advanced Search
ABOUT
Site Map
CP RSS Channel
Contact Us
Sponsoring CP
About Our Sponsors
NEWS
Cover Stories
Articles & Papers
Press Releases
CORE STANDARDS
XML
SGML
Schemas
XSL/XSLT/XPath
XLink
XML Query
CSS
SVG
TECHNOLOGY REPORTS
XML Applications
General Apps
Government Apps
Academic Apps
EVENTS
LIBRARY
Introductions
FAQs
Bibliography
Technology and Society
Semantics
Tech Topics
Software
Related Standards
Historic
Last modified: November 10, 2003
Asynchronous Transactions and Web Services

Overview

[Provisional document, under construction.] This reference document provides general information on the topic of asynchronous communication (messaging, protocols) in the context of Internet distributed computing.

Managing Asynchronous Transactions: Example Specifications and Software

We list here (in no significant order) several contexts within which the importance of asynchronous messaging/transaction has been recognized, even if not specified in a generalized or formal way. A host of software application frameworks and products implement solutions for asynchronous messaging, but in non-standard or proprietary ways. Most web services and messaging specifications provide for asynchronous transactions, but do not address the issue as a central concern.

Contents for Examples

  • Web Services Transaction Management (WS-TXM)

    • WS-TXM is part of WS-CAF; see "Web Services Composite Application Framework (WS-CAF) for Transaction Coordination."
    • WS-TXM Specification Version 1.0
    • Excerpt: "WS-TXM leverages the WS-CF and WS-CTX specifications. It defines a pluggable transaction protocol that can be used with the coordinator to negotiate a set of actions for all participants to execute based on the outcome of a series of related Web services executions. The executions are related through the use of shared context. Examples of coordinated outcomes include the classic two-phase commit protocol, a three phase commit protocol, open nested transaction protocol, asynchronous messaging protocol, or business process automation protocol... supports three transaction models that address different use cases in current business-to-business interactions. [In addition to the ACID transaction] WS-TXM supports 'Long running action': an activity, or group of activities, which does not necessarily possess the guaranteed ACID properties. A long running action (LRA) still has the all or nothing atomic effect, i.e., failure should not result in partial work. Participants within an LRA may use forward (compensation) or backward error recovery to ensure atomicity. Isolation is also considered a back-end implementation responsibility.... The long running action model (LRA) is designed specifically for those business interactions that occur over a long duration. Within this model, an activity reflects business interactions: all work performed within the scope of an activity is required to be compensatable. Therefore, an activity's work is either performed successfully or undone. How services perform their work and ensure it can be undone if compensation is required, are implementation choices and not exposed to the LRA model. The LRA model simply defines the triggers for compensation actions and the conditions under which those triggers are executed. As with most transaction models, LRA is concerned only with ensuring participants obey the protocol necessary to make an activity compensatable..."

  • Web Services Coordination

    • WS-Coordination. Excerpt: "Web Services increasingly tie together a large number of participants forming large distributed computational units -- we refer to these computation units as activities. The resulting activities are often complex in structure, with complex relationships between their participants. The execution of such activities often takes a long time to complete due to business latencies and user interactions. This specification defines an extensible framework for coordinating activities using a coordinator and set of coordination protocols. This framework enables participants to reach consistent agreement on the outcome of distributed activities. The coordination protocols that can be defined in this framework can accommodate a wide variety of activities, including protocols for simple short-lived operations and protocols for complex long-lived business activities..."
    • "Introducing WS-Coordination." By Jim Webber and Mark Little. In Web Services Journal.

  • Web Services Transaction

  • BPEL4WS

    • "Business Process Execution Language for Web Services. [BPEL4WS.]" By Tony Andrews (Microsoft), Francisco Curbera (IBM), Hitesh Dholakia (Siebel Systems), Yaron Goland (BEA), Johannes Klein (Microsoft), Frank Leymann (IBM), Kevin Liu (SAP), Dieter Roller (IBM), Doug Smith (Siebel Systems), Satish Thatte (Microsoft - Editor), Ivana Trickovic (SAP), and Sanjiva Weerawarana (IBM). Version 1.1. 5-May-2003. 136 pages.
    • "Business Process Execution Language for Web Services (BPEL4WS)" - Reference page.
    • 2003] "Introducing BPEL4WS 1.0. Building on WS-Transaction and WS-Coordination." By Jim Webber and Mark Little (Arjuna Technologies Limited). In Web Services Journal Volume 3, Issue 8 (August 2003), pages 28-33. "BPEL4WS is at the top of the WS-Transaction stack and utilizes WS-Transaction to ensure reliable execution of business processes over multiple workflows, which BPEL4WS logically divides into two distinct aspects. The first is a process description language with support for performing computation, synchronous and asynchronous operation invocations, control-flow patterns, structured error handling, and saga-based long-running business transactions. The second is an infrastructure layer that builds on WSDL to capture the relationships between enterprises and processes within a Web services-based environment."

  • WS-CallBack Protocol and SOAP Conversation Protocol

    • WS-CallBack Protocol (WS-CallBack). BEA Systems. Version 0.91. The WS-CallBack protocol "consists of the CallBack SOAP header and an associated WSDL definition. WS-CallBack is used to dynamically specify where to send asynchronous responses to a SOAP request... The CallBack header is needed in cases where a web service is using asynchronous communication and the address to which to send responses is not known at deployment time. In order to enable asynchronous responses to requests the requestor must specify in the request where to send the responses. The WS-CallBack protocol provides the SOAP and WSDL 1.1 mechanisms needed to enable this behavior..."
    • See also BEA's "SOAP Conversation Protocol (SOAP Conversation) 1.0", by David Bau and David Orchard, June 13, 2002. "SOAP Conversation Specification describes SOAP Conversation, which is a set of SOAP headers, a protocol, and WSDL definitions designed to support asynchronous and conversational messaging... SOAP Conversation (SOAP-Conversation) is a SOAP and WSDL based specification that defines long-running and asynchronous interactions between SOAP based senders and receivers. SOAP-Conversation is expressed as a SOAP header entry within a SOAP envelope making it relatively independent of the underlying protocol. This makes it easy to conduct stateful conversations between two parties asynchronously. Goals: (1) The soap headers must be as simple as possible and meet the "80/20" rule for conversation and dynamic asynchrony functionality; (2) the WSDL that describes the header and the actual header data must be capable of being consumed and produced by senders, proxies and receivers; (3) The WSDL should reflect all the information that SOAP conversation treats as part of the contract, including the conversational phase of each operation... SOAP Conversation Messages are SOAP messages that contain SOAP Conversation Headers; a SOAP Conversation node can be either a sender or a receiver, or both... The SOAP Conversation Protocol defines the permitted sequence of messages and the erroneous messages in the SOAP Conversation state machine. The protocol is [...]
    • "BEA Releases Web Services Specifications Supporting Asynchrony, Reliable Messaging, Metadata."

  • WS-Reliability and WS-ReliableMessaging

    • Asynchronicity is not of itself a central concern in Web Services Reliability (WS-Reliability) and Web Services Reliable Messaging Protocol (WS-ReliableMessaging). Both assume that companion specifications describe appropriate protocols/rules. Thus (in the former) Section 5 (HTTP Binding) describes "the HTTP binding for SOAP, when the original message is sent asynchronously at the application level. When supporting reliable messaging, upon receipt of a reliable message, the server must send a reply. This reply must be either an Acknowledgment or a Fault message. This reply must be sent either synchronously or asynchronously. Reliable Messaging with Asynchronous Acknowledgment Message: The Reliable Messaging Acknowledgment message may also be sent back on a different HTTP connection from the HTTP connection used to send the message being acknowledged. (See examples of the asynchronous acknowledgment message sequence).
    • Reference: see in "Reliable Messaging."

  • Asynchronous Web Services Protocol (AWSP)

    • AWSP is "a standard means of extending Simple Object Access Protocol (SOAP) to support asynchronous web services. In this context, asynchronous means that there is a latency between the request for a resource (or service) and the actual return of that resource (or service results). AWSP is designed to support web services that take more than 60 seconds to create their results. Web services are important to integrating applications and processes across enterprise boundaries, especially for electronic commerce. These web services often represent business processes, some of which involve human intervention and approval. It is difficult to have any process that involves people finish in under 60 seconds. AWSP enables these long running processes to be web services as well..." [from the website Home Page 2003-08]
    • Abstract from the draft AWSP specification [2002-04-05]: "A standard protocol is needed to integrate asynchronous services across the Internet or intranet and provide for their interaction. The integration and interactions consist of control and monitoring of the services. Control means creating the service, setting up the service, starting the service, stopping the service, being informed of exceptions, being informed of the completion of the service and getting the results of the service. Monitoring means checking on the current status of the service and getting a history of the execution of the service. The protocol should be lightweight and easy to implement, so that a variety of devices and situations can be covered. The Asynchronous Web Services Protocol (AWSP) is a proposed way to solve this problem through use of Simple Object Access Protocol (SOAP), and by transferring structured information encoded in XML. A new set of SOAP methods are defined, as well as the information to be supplied and the information returned in XML that accomplish the control of generic asynchronous services. This protocol has applicability to business-tobusiness e-commerce because business processes are an asynchronous service, and they also have the need to be able to call asynchronous services outside of themselves."
    • "Asynchronous Web Services Protocol." By Keith Swenson (MS2 Inc) and Jeffrey Ricker (Trans-enterprise Integration Corp). Copyright (c) the authors. Draft. Proposal for a protocol standard; not approved for adoption. 05-April-2002. 37 pages. Discussion of the draft at awsp-wg@awsp.info. See also the spec reference page. Available in MS Word/.DOC and PDF formats. [cache]
    • Asynchronous Web Services Protocol. Introduction by Examples." By Jeffrey Ricker. Version 1.0. April 7, 2002. 30 pages. Copyright (c) 2002. Trans-Enterprise Integration Corporation. "This document provides an introduction by example to Asynchronous Web Services Protocol (AWSP). We have created an electronic commerce scenario to demonstrate the key capabilities of AWSP. With this scenario, we will trace the exchange of specific documents between applications. It is intended that this document will provide you the level of understanding to begin experimenting and implementing an AWSP solution." [cache]
    • AWSP Technical Summary
    • AWSP Not-so-technical Executive Summary
    • AWSP: Business Significance. "AWSP is key to business process management (BPM)..."
    • Asynchronous Web Services. Reference page from Trans-Enterprise Integration Corp.
    • [Legacy] Mailing lists: for developers, awsp-dev@awsp.info; for users, awsp-users@awsp.info; for technical contributors, awsp-wg@awsp.info; for general information, info@awsp.info.
    • Sponsors. As of 2003-08-03, the AWSP initiative had received support/contributions/endorsement from Trans-Enterprise, MS2 Inc, and the Workflow Management Coalition.

  • OASIS Asynchronous Service Access Protocol (ASAP) TC

    • [August 05, 2003] A 'Call for Participation' in the OASIS Asynchronous Service Access Protocol (ASAP) TC was issued 2003-08-05. OASIS members are forming a new Asynchronous Service Access Protocol (ASAP) TC to create a very simple extension of Simple Object Access Protocol (SOAP) that enables generic asynchronous web services or long-running web services. The TC activity would build upon previous technical work published in the IETF RFC Simple Workflow Access Protocol (SWAP) and in a derivative Asynchronous Web Services Protocol (AWSP) specification developed by Jeffrey Ricker and Keith Swenson. The ASAP work is designed to address the fact that "not all services are instantaneous. A standard protocol is needed to integrate asynchronous services across the Internet and provide for their interaction. The integration and interactions consist of control and monitoring of the service. The protocol should be lightweight and easy to implement, so that a variety of devices and situations can be covered." The TC proposers believe that "asynchronous capability is not specific to any one problem. Rather, it is needed to one degree or another in a number of problem areas, such as workflow, business process management, e-commerce, data mining, and mobile wireless devices. ASAP strives to provide to a simple common asynchronous capability that can be employed in any number of problem-specific protocols." The proposed ASAP specification would be consistent with the W3C XML Protocol (XMLP) work and SOAP; it would provide a general solution complementary to several related specifications, including those produced by the Workflow Management Coalition (WfMC), the W3C Web Services Description Language (WSDL) Working Group, ebXML Messaging Services TC, OASIS Web Services Business Process Execution Language TC, OASIS Business Transaction Protocol (BTP) TC, and OASIS Web Services Reliable Messaging (WSRM) TC. The first meeting of the ASAP TC was scheduled to be held by teleconference on September 9, 2003.
    • Call for Participation in OASIS Asynchronous Service Access Protocol (ASAP) TC. News story 2003-08-05
    • ASAP TC website
    • The Asynchronous Web Services Protocol (AWSP) specification is to provide the basis for work in the OASIS ASAP TC.
    • "OASIS Members Advance Protocol for Monitoring and Controlling Asynchronous Web Services." Announcement 2003-11-10.

  • Workflow Management Coalition Specification

    • Workflow Management Coalition Workflow Standard - Interoperability Wf-XML Binding. The Workflow Management Coalition Specification. Document Number: WFMC-TC-1023. Document Status: Final Draft. 14-November-2001. Version 1.1. 57 pages. Send comments to workgroup4@ftplist.aiim.org. "The XML language described herein, Wf-XML, can be used to implement the three models of interoperability defined in the Interoperability Abstract specification. Specifically, chained workflows, nested workflows and parallel-synchronized workflows are supported. Wf-XML supports these three types of interchanges both synchronously and asynchronously, and allows messages to be exchanged individually or in batch operations. Furthermore, this specification describes a language that is independent of any particular implementation mechanism, such as programming language, data transport mechanism, OS/hardware platform, etc. However, because HTTP is expected to be the most prevalent data transport mechanism used for interchanging Wf-XML messages, this specification provides a description of how Wf-XML messages are to be interchanged using this protocol. This document represents a specification for a language based on the eXtensible Markup Language (XML) designed to model the data transfer requirements set forth in the Workflow Management Coalition (WfMC)'s Interoperability Abstract specification. This language will be used as the basis for concrete implementations of the functionality described in the Interoperability Abstract supporting the WfMC's Interface 4, as defined by the Workflow Reference Model . This version (1.1) of the Wf-XML specification is fully backward compatible with its previous version (1.0). For the sake of clarity, the term 'backward-compatible' is used here to mean that all changes made to the specification in this version have been additive, making it is a superset of version 1.0. For a more detailed explanation of conformance implications, see section 6 Conformance..." See the accompanying V1.1 XML DTD. The ZIP archive contains a Word/.DOC version of the spec and the XML DTD. [cache .ZIP, cache PDF for spec]
    • "WfMC Announces Release of Workflow Standard Interoperability Wf-XML Binding Version 1.1." - "The Workflow Management Coalition (WfMC) is pleased to announce the release of Workflow Standard - Interoperability: Wf-XML Binding version 1.1. This document represents a specification for a language based on the eXtensible Markup Language (XML), designed to model the data transfer requirements set forth in the Workflow Management Coalition (WfMC)'s Interoperability Abstract specification. XML version 1.1 incorporates... Enhanced support for asynchronous processing: This processing model is now addressed more explicitly through the addition of a new message type (Acknowledgement), as well as specification of structures in the Transport section of the message useful for correlation of messages. The release of Wf-XML version 1.0 was a landmark achievement for the WfMC in that it represented the Coalition's initial entry into the XML arena. With this release, the WfMC has further defined the fundamental protocol elements required to support interoperability among workflow systems over any transport mechanism (such as HTTP, SMTP, TCP/IP, etc.), whether synchronous or asynchronous..."
    • XML-Based Workflow and Process Management Standards: XPDL, Wf-XML" - General references.

  • Simple Workflow Access Protocol (SWAP)

    • SWAP provided a basis for further work in Asynchronous Web Services Protocol (AWSP) and in the Workflow Management Coalition Workflow Standard (Interoperability - Wf-XML Binding). On WfMC, see XML-Based Workflow and Process Management Standards: XPDL, Wf-XML."
    • From the August 7, 1998 SWAP draft: "A standard protocol is needed to integrate work providers, asynchronous services, across the intranet/internet and provide for their interaction. The integration and interactions consist of control and monitoring of the work. Control means creating the work, setting up the work, starting the work, stopping the work, being informed of exceptions, being informed of the completion of the work and getting the results of the work Monitoring means checking on the current status of the work and getting a history of the execution of the work. The protocol should be light weight and easy to implement, so that a variety of devices and situations can be covered. The Simple Workflow Access Protocol is a proposed way to solve this problem through use of HTTP protocol, and by transferring structured information encoded in XML. A new set of HTTP methods is defined, as well as the information to be supplied and the information returned in XML, that accomplish the control of generic asynchronous services. This has applicability to workflow because a workflow is itself an asynchronous service, and it also has the need to be able to call asynchronous services outside of itself."
    • "Simple Workflow Access Protocol (SWAP)." By Keith Swenson (Netscape Communications Corporation). IETF Internet-Draft. Reference: draft-swenson-swap-prot-00.txt. August 7, 1998, expires February, 1999.
    • "Requirements for Simple Workflow Access Protocol." November 17, 2003.
    • "Workflow Interoperability Standards for the Internet." In IEEE Internet Computing (May/June 2000).
    • "SWAP: Leveraging The Web To Manage Workflow." In IEEE Internet Computing (January/February 1999).

  • Blocks Extensible Exchange Protocol (BEEP)

    • The IETF RFC describes "a generic application protocol kernel for connection-oriented, asynchronous interactions called the BEEP (Blocks Extensible Exchange Protocol) core. BEEP permits simultaneous and independent exchanges within the context of a single application user-identity, supporting both textual and binary messages... BEEP accommodates asynchronous interactions, both within a single channel and between separate channels. This feature allows pipelining (intra-channel) and parallelism (inter-channel). A BEEP peer acting in the client role may send multiple 'MSG' messages on the same channel without waiting to receive the corresponding replies. This provides pipelining within a single channel. A BEEP peer acting in the server role must process all 'MSG' messages for a given channel in the same order as they are received. As a consequence, the BEEP peer must generate replies in the same order as the corresponding 'MSG' messages are received on a given channel. Note that in one-to-many exchanges, the reply to the 'MSG' message consists of zero or more 'ANS' messages followed by a 'NUL' message. In this style of exchange, the 'ANS' messages comprising the reply may be interleaved. When the BEEP peer acting in the server role signifies the end of the reply by generating the 'NUL' message, it may then process the next 'MSG' message received for that channel... A BEEP peer acting in the client role may send multiple 'MSG' messages on different channels without waiting to receive the corresponding replies. The channels operate independently, in parallel. A BEEP peer acting in the server role may process 'MSG' messages received on different channels in any order it chooses. As a consequence, although the replies for a given channel appear to be generated in the same order in which the corresponding 'MSG' messages are received, there is no ordering constraint for replies on different channels... A BEEP peer acting in the server role may send a negative reply before it receives the final 'MSG' frame of a message. If it does so, that BEEP peer is obliged to ignore any subsequent 'MSG' frames for that message, up to and including the final 'MSG' frame. If a BEEP peer acting in the client role receives a negative reply before it sends the final 'MSG' frame for a message, then it is required to send a 'MSG' frame with a continuation status of complete ('.') and having a zero-length payload... If the processing of a particular message has sequencing impacts on other messages (either intra-channel or inter-channel), then the corresponding profile should define this behavior, e.g., a profile whose messages alter the underlying transport mapping..."
    • "The Blocks Extensible Exchange Protocol Core."
    • "Blocks eXtensible eXchange Protocol Framework (BEEP)."

  • Collaxa Orchestration Server

    • Collaxa 2.0 supports the integration of asynchronous services: "BPEL4WS <invoke> and <receive> activities and the Collaxa patented 2-way proxy make it easy to invoke remote Web services and receive asynchronous callbacks... Collaxa makes it easy for Java developers to publish synchronous and asynchronous Web services and compose them into reliable and transactional business flows... develop, orchestrate and monitor business flows using J2EE components, asynchronous messaging. and XML Web Services..."
    • See also the Collaxa Whitepaper: ""Orchestrating Asynchronous Web Services. Case for a Web Service Orchestration Server."

  • Systinet WASP Server for Java. WASP Server for Java Version 4.6 Features Asynchronous Web Services Enhancements: "Most Web services are invoked synchronously, meaning the client sends a request to a service and then halts operation while waiting for a service response. However, synchronous invocation is not suitable when the service must perform an extraordinarily complex computation, or when it would be inefficient to keep the transport channel open waiting for the results to come. For these applications, using asynchronous invocation makes sense. WASP Server for Java, 4.6 features a new, easy-to-use, event-based mechanism for invoking Web services asynchronously. In many situations involving asynchronous calls, the process needs to wait until the results for one of a set of parallel calls come back. The WASP client and server offer a flexible event model that enables the application to automatically receive a notification from the server once processing has been completed. This mechanism eliminates the need for developers to write code on the client that continually 'polls' the server to receive the response. This mechanism can also be used to manage multiple responses from a single request. For example, an asynchronous SOAP request is sent over JMS transport to multiple JMS recipients. All recipients consume the request message and reply (via JMS) with a SOAP response. Using WASP's asynchronous API, the requesting application can then process all SOAP responses. WASP ensures application reliability by storing the receipt in a persistent store (e.g., on disk) between invocations. So if the client process is terminated and restarted, the deserialized asynchronous receipt will be usable when the process is restarted. WASP Server for Java also features transport-level asynchrony, which relies on using different transport channels for the request and response messages, such as an HTTP request and an e-mail response, or even an email request and an e-mail response..." [from the datasheet]

  • Web Services Invocation Framework (WSIF)

    • WSIF website
    • WSIF Overview
    • Providers - Three providers are enabled for Jms: SOAP, Axis and NativeJms. Asynchronous support is currently only supported over Jms... The WSIF API allows clients to invoke services focusing on the abstract service description -- the portion of WSDL that covers the port types, operations and message exchanges without referring to real protocols. The abstract invocations work because they are backed up by protocol-specific pieces of code called providers. A provider is what conducts the actual message exchanges according to the specifics of a particular protocol -- for example, the SOAP provider that is packaged with WSIF uses a specific SOAP engine like Axis to do the real work..."

Articles, Papers, News

A general reference list on asynchronous (message) invocation and asynchronous protocols is provided here. Readers wishing to nominate other citations for reference are encouraged to send email with the bibliographic details and/or URL(s).

  • [October 13, 2003] "Industry Commentary: Think Async." By Edwin Khodabakchian (Collaxa). In Web Services Journal (October 13, 2003). "Within the IT industry, we're seeing a steady shift from an RPC (remote procedure call) integration style to asynchronous, document-based integration. More and more developers are realizing that asynchronous services are core to a new, loosely coupled and message-driven architecture. The main benefits that are enabled by asynchronous services and the associated loosely coupled, message-based architecture are: (1) Reliability: A synchronous integration style results in brittle applications where the weakest link in a chain impacts an entire application or business process. Reliable integration requires asynchronous interactions. (2) Scalability: Message-oriented middleware vendors and developers have shown that queues provide for maximum throughput and efficiency when connecting systems with different processing and availability capacities. The same approach can be taken with all integration projects by leveraging asynchronous services. (3) Long-running services: Integration projects frequently bring the greatest value when automating business processes that involve both manual processes and automated systems. Any service that supports or requires manual intervention must have an asynchronous interface due to the time it will likely need to complete... there are many standards (BPEL4WS, SOAP, WSDL, WS-Addressing, WS-Transaction, etc.) that assist in implementing asynchronous architectures. These standards provide a framework for an asynchronous architecture and bring significant value in both the design and implementation phases of an integration project by supporting asynchronous interactions as first-class citizens. But all of these standards and technology are the second step - the first step is for developers and architects to learn to be more comfortable designing asynchronous, loosely coupled services and systems...

  • [August 2003] "Design and Implementation of an Asynchronous Invocation Framework for Web Services." By Uwe Zdun (Department of Information Systems, Vienna University of Economics, Austria), Markus Voelter (Ingenieurbro für Softwaretechnologie, Germany), and Michael Kircher (Siemems AG, Corporate Technology, Software and System Architectures, Germany; WWW). Prepared for The International Conference on Web Services - Europe, Erfurt, September 23 - 24, 2003. "Asynchronous invocations are an important functionality in the context of distributed object frameworks, because in many situations clients should not block during remote invocations. There should be a loose coupling between clients and remote services. Popular web service frameworks, such as Apache Axis, offer only synchronous invocations (over HTTP). An alternative are messaging protocols but these implement a different communication paradigm. When client asynchrony is not supported, client developers have to build asynchronous invocations on top of the synchronous invocation facility. But this is tedious, error-prone, and might result in different remote invocation styles used within the same application. In this paper we build a framework using patterns for asynchronous invocation of web services. The framework design is based on the asynchrony patterns and other patterns from the same pattern language." [alt URL, cache]

  • [June 2003] "Patterns for Asynchronous Invocations in Distributed Object Frameworks." By Markus Voelter, Michael Kircher, Uwe Zdun, and Michael Englbrecht. Paper prepared for EuroPLoP 2003 (Eighth European Conference on Pattern Languages of Programs), June 25-29, 2003, Irsee, Germany. "OO-RPC middleware typically provides synchronous remote method invocations from clients to server objects. In some scenarios, asynchronous behaviour is necessary, though. This collection of patterns introduces the four most commonly used techniques in this context. FIRE AND FORGET describes best-effort delivery semantics for asynchronous operations that have void return types. SYNC WITH SERVER looks the same from the client's point of view, however it is able to notify the client (by throwing an exception) in case the delivery of the invocation to the SERVER APPLICATION fails. POLL OBJECTS provide clients with means to query the distributed object framework whether an asynchronous reply for the request has arrived yet, and if so, to obtain the return value. Last but not least, RESULT CALLBACK will actively notify the requesting client of the returning result. Note that these patterns are part of a larger pattern language on remoting middleware..." [alt URL]

  • [April 08, 2003] "Will the Real Reliable Messaging Please Stand Up? A.K.A. WS-Reliability, WS-ReliableMessaging, or WS-ReliableConundrum?" By Dave Chappell (Vice President and Chief Technology Evangelist, Sonic Software). Sonic Technical Report (Position Paper). April 02, 2003. 9 pages. Text supplied by the author. "Along with security, reliable asynchronous communications has been one of the gaping holes in today's Web services architecture. Lack of reliability, due to the inherent nature of using SOAP over protocols such as HTTP, is one of the biggest obstacles to the adoption of Web services for mission-critical communications between applications and services, such as complex business-to-business transactions or real-time enterprise integration... The need for open standards for reliable Web services has become so widely recognized that we now have three competing sets of SOAP-based reliable messaging out there. All were recently announced, and all are named under the defacto branding of 'WS-*'. There is the OASIS WS-Reliability spec that a large number of vendors, including Sonic, is a part of. There is a one-vendor set of specs announced by BEA recently, known as WS-Acknowledgement, WS-Callback, and WS-MessageData. Then less than two weeks after that announcement, along came another competing specification announced jointly by Microsoft, IBM, BEA, and TIBCO, known as WS-ReliableMessaging and WS-Addressing... After careful examination, I have come to the conclusion that all of the new specs by-and-large cover the same ground. They all do SOAP-based reliable messaging via acknowledgements, and have varied levels of Quality of Service (QoS) options like at-most-once and at-least-once. All have an ability to specify a URI (URL) as a place to receive asynchronous callbacks, and a message ID based mechanism for correlating asynchronous requests with asynchronous 'responses'. The smaller differences include things like duplicate-elimination, acknowledgement timeouts, or purported support for WS-Security. The following is a summary of the three initiatives... Reliable messaging is a cornerstone to any enterprise capable integration strategy. Regardless of how this WS-Reliable-Conundrum turns out, the world needs to start focusing on the larger issues. Beyond the base reliable messaging protocol, you still need to think about things like how the messages are orchestrated together, how the XML messages get cached and aggregated, and what the buckets are to place things in when good messages go bad. The rapidly emerging ESB category encompasses these types of issues, and allows for multiple reliable protocols to coexist together. In the end its all about the infrastructure that holds it all together in a platform independent fashion." (1) "OASIS Members Form Technical Committee for Web Services Reliable Messaging"; (2) "BEA Releases Web Services Specifications Supporting Asynchrony, Reliable Messaging, Metadata"; (3) "New Web Services Specifications for Reliable Messaging and Addressing." General references in "Reliable Messaging." [source .DOC]

  • [April 02, 2003] "Really Simple Asynchronous Web Services." By Eric Newcomer (IONA Technologies). In Computerworld (March 25, 2003). "The first word in SOAP (Simple Object Access Protocol) is 'simple,' but the world of Web services has become very complicated. In early 2000 the SOAP specification was published, and it was quickly followed by the SOAP with Attachments; Universal Description, Discovery and Interoperability (UDDI); and Web Services Description Language (WSDL) specifications. These core technologies have been very widely adopted, implemented and endorsed. Then came a plethora of proposals for additional functionality, positioned as extensions to the core technologies, such as WS-Security, WS-Transactions, WS-Routing, BPEL, WS-Coordination, HTTP-R and WS-Reliability... Most current Web services applications are used in a connection-oriented manner. That is, in order to use the applications over the Internet, a connection is required between the service requester and service provider. But for the mobile traveler, and for the emerging world of wireless networks, always being connected may not be possible or practical. In the world of high-speed, wireless networking and mobile Internet-enabled devices such as laptops, personal digital assistants (PDA), cellular telephones and automobiles, it is unlikely that a connection will always and constantly be available. A really simple solution works well in this environment, insulating users from worrying about connectivity loss. If a connection is present, the message is immediately transferred. If a connection is not present, the message is queued up for later transfer. ... File-based transfer mechanisms provide a really simple way to implement asynchronous Web services, resolving common concerns such as occasional connectivity, security and reliable messaging without adding the complexity of extended standards. File-based transfer mechanisms are consistent with current and emerging Web services standards. Considerable frustration with current Web services technologies arises when comparing them with RPC-oriented middleware since by definition Web services are not well suited to the RPC-oriented interaction style. Web services are much better suited for the message-oriented interaction style. Extending Web services toward message-oriented middleware architectures provides a better way to improve short-term value than proposing complex RPC-oriented extensions. Client-side applications benefit from the simple asynchronous architecture since they do not have to worry about whether or not they are connected to the Internet; and they can use better GUI tools, work with large documents and participate in long-running business process orchestrations..."

  • [September 20, 2002] "Next-Gen Web Services: Asynchronous Services Preached. Sonic Exec Stresses Need for Asynchronous Technology in Web Services." By Paul Krill. In InfoWorld (September 20, 2002). "Asynchronous Web services, which would support extended transactions that take place over days or months, is a critical need for the success of Web services, said an official of Web services software company Sonic Software at the InfoWorld Next-Generation Web Services II: The Applications conference here Thursday. Sonic's Dave Chappell, vice president and chief technology evangelist at the company, stressed a need for asynchronous technology to make Web services successful. He stressed this technology as an alternative to remote procedure call-based Web services. 'In order for Web services to take root and prosper, what's really needed is an architecture that supports the notion of a constellation of hubs,' to integrate with trading partners and integrate across the enterprise, Chappell said. 'Asynchronous Web services are a must for that kind of architecture,' he stressed... Robert Marcus, CTO at Emerging Technology Strategies, said the industry lacks a standard protocol for asynchronous messaging. 'One of the shocking things for our industry is there's no standard [protocol] for reliable, asynchronous messaging,' Marcus said. Marcus also said there is an opportunity for the use of business process templates for specific vertical industries in conducting transactions..."

  • [October 15, 2002] "Asynchronous Operations and Web Services, Part 3: Add Business Semantics to Web Services. Three new specifications open a world of e-business possibilities." By Holt Adams (Engagement Manager and Solutions Architect, IBM jStart). From IBM developerWorks, Web services. October 2002. ['In previous installments of this series, Holt Adams explained the relevance of asynchronous operations for Web services and saw some patterns for building asynchronous services. Now he tackles three new specifications -- Business Process Execution Language for Web Services, Web Services Coordination, and Web Services Transaction -- and explains how they open up a world of possibilities for Web services developers. You'll see how these three specifications can support asynchronous operations and create an operational programming environment that mirrors real-life business interactions.'] "The development of the Business Process Execution Language for Web Services, Web Services Coordination, and Web Services Transaction specifications is a critical step toward enabling enterprises to leverage Web services in modeling their real-world processes. With BPEL, you can describe a long-running, multistep process of a business transaction using activities to encompass atomic transactions for individual process steps. Once a process is described using the BPEL XML flow language, a business process engine must interpret the process description in order to execute and manage the business transaction. The business process engine will provide the infrastructure services and resources for enabling long-running stateful business transactions that require interactions between the process, internal services, and external partner services (which themselves could be individual services exposed by the partners' process flows). However, at this time, before enterprise processes can be fully realized in an operational programming environment, IBM and other vendors will need to update their business process engines to interpret the BPEL XML flow language and to support the coordination and transactional facilities outlined in the WS-C and WS-T specifications. Likewise, these three critical specifications will need to be moved into a standards organization and approved as open standards. Currently, IBM, Microsoft, and BEA are working towards that goal. Once business process engines generally support BPEL, WS-C, and WS-T, the IT staff of any enterprise that seeks to automate steps in its business processes by leveraging Web services technology and the new specifications will need to: (1) Describe the enterprise's processes using the BPEL XML flow language; (2) Provide the business logic for the activities; (3) Provide the Web services interfaces for legacy applications -- for example, transaction resource managers -- that will be utilized in the process flow activities for realizing the business transaction; (4) Inform the business process engine how to locate the Web services utilized within the process flow activities..." See: "Business Process Execution Language for Web Services (BPEL4WS)."

  • [July 06, 2002] "Asynchronous Web Services!" By Kurt Cagle. Posted July 06, 2002 to W3C xml-dist-app list; 'xml-dist-app' is a forum for discussion of XML in distributed applications, network protocols, and messaging systems. "... The XML Protocol documents have been working toward addressing asynchronous protocols for a while, but the SOAP specification has unfortunately been migrating increasingly into a synchronous model where XML has primarily been used as a convenient stopgap for the limitations of COM or CORBA as brokering agents. There is a growing movement of developers and engineers, however, who are becoming uncomfortable with this model by itself -- it preserves the letter of the law (the XML specification) while violating the spirit of it (the creation of syncronous RPCs, XML solely as a means of expressing data structure without its consideration as a meta-document definition, etc., the complexification of both transport and processing, etc.). Both SOAP and WSDL can, in theory, be used in an asynchronous manner, but whether that remains the case into the future is dubious. SOAP was originally developed (and has consequently been pushed primarily) by Microsoft as a way of extending the brokered COM model out onto the Internet, and it's primary emphasis has always been on stateful, synchronous, strongly connected applications. Compare this with the asynchronous, disconnected models that form the basis for most of the successful protocols on the web -- HTTP and SMTP, to name two -- and look at the success that Microsoft has had in the past with getting closed, connected networks in place (such as MSN, which after a decade of service is still a loss leader for them) and you begin to realize where a synchronous, connected SOAP will lead..."

  • [July 2002] "Asynchronous Web Services." Section 1.2.2 in "Using Web Services Effectively" (Sun Microsystems). From the series Web Services BluePrints. ['This document describes guidelines for designing and implementing Web services on the Java 2 Platform, Enterprise Edition 1.3, J2EE 1.3.'] "With asynchronous services, the client invokes the service but does not -- or cannot -- wait for the response. Often, with these services, the client does not want to wait for the response because it may take a significant amount of time for the service to process the request. The client can continue with some other processing rather than wait for the response. Later, when it does receive the response, it resumes whatever processing initiated the service request. Generally, a document-oriented approach is used for asynchronous class of services. Services which process documents tend to use an asynchronous architecture. A document-oriented Web service receives a document as a service request. The document content determines the processing workflow for the Web service. There can be a number of processing steps required to fulfill the request. A travel agency service is a good example of a document-oriented Web service that might benefit by using asynchronous communication. The client sends a document (such as an XML document) to the travel service requesting arrangements for a particular trip. Based on the document's content, the service performs such steps as verifying the user's account, checking accommodations and transportation availability, building an itinerary, purchasing tickets, and so forth. Since the travel service must perform a series of often time-consuming steps in its normal workflow, the client cannot afford to pause and wait for these steps to complete..."

  • [June 05, 2002] "Asynchronous Web Services and the Enterprise Service Bus." By David A. Chappell (Sonic Software). From WebServices.org. June 05, 2002. ['This article will discuss how standards that exist today with real implementations can fit together to address the need for loosely coupled, reliable, asynchronous Web services.'] "One of the cornerstones of Web services interoperability is SOAP (Simple Object Access Protocol). SOAP began simply as a way of performing a synchronous RPC (Remote Procedure Call) across the Internet over an HTTP connection. However, SOAP is designed to be layered on top of, or 'bound' to, any protocol. In practice, its use has expanded beyond simple RPC to embrace asynchronous communications as well. WSDL (Web Services Description Language) describes whether the invocation style is 'document' or 'rpc'. WSDL defines 4 operation modes - oneway and request/response modes are used to describe an inbound asynchronous receive by a service, or an inbound/outbound synchronous RPC. Notification and Solicit/Response are used to describe the reciprocal of those operations, when the operation is initiated by the server to the client. All operation modes are equal citizens in the world of Web services interactions. Synchronous RPC provides the luxury of immediately knowing whether an operation was successful. However, when performing a synchronous operation across multiple processes, it is an all-or-nothing proposition. If one of the processes is not available, the application initiating the request must somehow make note of the failure, try it again later, or take some other more drastic course of action - like inform a human that they are simply out of luck. Also, as the number of applications and services that need to communicate with each other approaches 100, and each one is unavailable for only 1% of the time...well, you get the idea... In contrast, asynchronous messaging allows each communication operation between two processes to be a self contained, standalone unit of work. Each intermediary in a multi-process communication can have its own distinct conversation with its sender and its sendee. The process initiating the original request need only be concerned with initiating the 'request', knowing that it will eventually receive a 'response' asynchronously. In a complex interaction across multiple processes and services, the 'response' may never go to the original requestor. Each 'response' may be in the form of a new message being generated to be sent to a forwarding address. A number of forwarding addresses may be strung together in the form of an itinerary. Asynchronous processing also has the advantage of allowing critical failures to be centrally reported and dispatched via an administrative alert system... Asynchronous message-based interactions typically require very loosely coupled interfaces. In an environment where multiple applications and services need to interact with each other, it is not practical that every application be required to know the intimate details of every other application's myriad of method calls and parameters. In an environment involving tightly coupled interfaces, the number of interfaces that needs to be created and maintained quickly becomes unwieldy..."

  • [June 01, 2002] "Asynchronous Operations and Web Services, Part 2. Programming Patterns to Build Asynchronous Web Services." By Holt Adams (Engagement Manager/Solutions Architect, IBM jStart). From IBM developerWorks, Web services. June 1, 2002. ['Holt Adams provides concrete blueprints that will help you build your own asynchronous Web services. These practical patterns can be used today for handling responses to Web service requests as separate transactions. You'll also learn which real-world situations each pattern lends itself to.'] "In this paper, I'll examine several design patterns for asynchronous Web services. These patterns will help developers of client and service provider applications to architect their code to support asynchronous behavior while taking into consideration code complexity, use of given transports, and the need for explicit acknowledgements. You may also be interested in reading about another package [WSIF] that supports asynchronous behavior in Web services... The four patterns for support of asynchronous Web service operations discussed here are based on the four transmission primitives that an endpoint can support, as defined in version 1.1 of the Web Services Descriptor Language (WSDL) specification: (1) One-way: The endpoint receives a message. (2) Request/response: The endpoint receives a message, and sends a correlated message. (3) Solicit/response: The endpoint sends a message, and receives a correlated message. (4) Notification: The endpoint sends a message..." On IBM's Web Service Invocation Framework and asynchronous operations: "The Web Service Invocation Framework (WSIF) provides a client API for invoking Web services asynchronously using a local proxy (for example, a stub) with the capability to use different transports based on the context of the invocation. Many of the patterns addressed in this paper can be supported by WSIF components, thus allowing true support for asynchronous Web services operations..."

  • [April 01, 2002] "Asynchronous Operations and Web Services, Part 1: A Primer on Asynchronous Transactions. Build a Web services Architecture that Handles Requests and Responses as Separate Transactions." By Holt Adams (Engagement Manager/Solutions Architect, IBM jStart). From IBM developerWorks, Web services. April 1, 2002. ['Not all Web services work synchronously; in some situations, responses to Web service requests are not provided immediately, but rather sometime after the initial request transactions complete. Such asynchronous operations aren't explicitly supported by Web services specifications and standards; however, those standards do include the infrastructure and mechanisms on which asynchronous operations can be based. In this article, Holt Adams explains why any Web services architect needs to understand how asynchronous operations work. This article will help you begin to adapt your own services for an asynchronous environment.'] "Invocations of Web services are asynchronous in nature in that the service provider must be capable of accepting requests from clients without notice. However, sometimes the response to the Web service request is available on the same thread of execution as the invocation; such operations are often labeled as synchronous. This discussion of asynchronous operations will not focus on the initiation of request messages by clients or the consumption of request messages by service providers; rather, I'll focus on how to handle responses to Web service requests that are not provided immediately but at a time after the initial request transactions complete. Such asynchronous behavior is common for services that require complex processing that may take minutes or even days to complete -- when, for example, the Web service implementation is dependent on batch processing or manual steps requiring human intervention. In this paper, I'll examine the theoretical basis for asynchronous Web services... As the industry further develops specifications that determine how to coordinate flows between Web services and how to describe dependencies between Web services that realize business processes, support for asynchronous operations will be simplified. However, today's Web services specifications and standards do not directly describe the support of asynchronous operations, though they do include the infrastructure and mechanisms on which asynchronous operations can be based. You should now have an idea of how you can start building support of asynchronous operations into your Web services today. In the second installment of this series, I'll take a look at some asynchronous Web services patterns. These patterns will serve as foundations on which you can build advanced asynchronous Web patterns. You can prepare yourself for that article by mastering the concepts outlined here..." Also in PDF.

  • [February 2002] "Orchestrating Asynchronous Web Services. Case for a Web Service Orchestration Server." By Doron Sherman, Dave Shaffer, and Edwin Khodabakchian. Collaxa Whitepaper. February 2002. "Web Services promise to change the economics of integration. This white paper describes how asynchronous messaging and orchestration are key to making Web Services work... In our AutoLoan example, American Loan and Star Loan publish their loan processing capabilities as web services that process submitted loan applications into loan offers and issue loan policies upon acceptance of an offer. American Loan uses BEA Workshop (aka Cajun) and Star Loan uses Microsoft .Net for publishing their respective services. The definition of Web Services can be extended to non-SOAP/XML building blocks to accommodate performance requirements and interoperability with existing messaging infrastructures. In our AutoLoan example, the credit rating functionality is a CICS transaction, which is already published on WebSphere MQ (aka MQSeries). In this case, we can use the Java Messaging Service (JMS) API to access and consume that published functionality reliably and asynchronously... Need for Asynchronous Messaging: In order to achieve reliability, scalability and adaptability, interactions with web services must be implemented over an asynchronous messaging system. In the AutoLoan example, the application interacts with the credit rating system through JMS and with the loan processors through SMTP and 2-way HTTP... The emergence of asynchronous web services as building blocks for applications introduces new challenges. In particular, the synchronous request-reply programming model is giving way to a conversational model based on asynchronous interactions across loosely-coupled web services..."
Hosted By
OASIS - Organization for the Advancement of Structured Information Standards

Sponsored By

IBM Corporation
ISIS Papyrus
Microsoft Corporation
Oracle Corporation

Primeton

XML Daily Newslink
Receive daily news updates from Managing Editor, Robin Cover.

 Newsletter Subscription
 Newsletter Archives
Globe Image

Document URI: http://xml.coverpages.org/async.html  —  Legal stuff
Robin Cover, Editor: robin@oasis-open.org