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 will be held by teleconference on September 9, 2003.

From the Announcement

Motivation

Most existing Internet protocols like HTTP are based on an unwritten assumption of instant gratification. If a client asks for any resource that takes longer than about a minute to generate, then the request times out, that is, it fails. As we have applied Internet technology to more and more scenarios, this assumption of instant gratification has become more strained. There are many things we would like to access as webservices that cannot respond within 60 seconds such as data mining, workflow engines, manual processes and mobile wireless devices. What is needed is a simple ability to ask for a resource and for that resource to be able to respond, "The information isn't ready yet. Where would you like me to send it when I'm done?" That is what we mean by start an instance of a generic asynchronous service and be notified when it is complete. Someone asking for the resource should be able to pester, just like in the real world, with questions like, "Are you done yet? Where is that document I asked for?" That is what we mean by monitor. Finally, we should be able to change our mind in mid process, just like in the real world, with statements like, "Change that to five widgets, not six." That is what we mean by control.

TC Objectives

• The protocol should be consistent with XML Protocol and SOAP.
• This protocol should be easy to incorporate into other SOAP-based protocols that require asynchronous communication
• The protocol should be the minimal necessary to support a generic asynchronous service. This means being able to start, monitor, exchange data with, and control a generic asynchronous service on a different system.
• The protocol must be extensible. The first version will define a very minimal set of functionality. Yet a system must be able to extend the capability to fit the needs of a particular system, such that high level functionality can be communicated which gracefully degrades to interoperate with systems that do not handle those extensions.
• Like other Internet protocols, the ASAP specification should not require or make any assumptions about the platform or the technology used to implement the generic asynchronous service.
• Terseness of expression is not a goal of this protocol. Ease of generating, understanding and parsing should be favored over compactness.

Out of Scope

• The goals for the ASAP specification do not include a way to set up or to program the generic services in any way. Especially for the case where the service is a business process or workflow, ASAP does not provide a way to retrieve or submit process definitions. The service is considered to be a "black box" which has been pre-configured to do a particular process.
• The ASAP specification will not include the ability to perform maintenance of the asynchronous webservice such as installation or configuration.
• ASAP will not support statistics or diagnostics of collections of asynchronous webservices. ASAP is designed for the control and monitoring of individual asynchronous webservices.
• ASAP does not specify security. Rather, it relies on transport or session layer security. ASAP can adopt SOAP-specific security protocols once they are finalized.
• ASAP does not address service quality issues of transport such as guaranteed delivery, redundant delivery and non-repudiation. Rather, ASAP relies on the session layer, the transport layer, or other SOAP protocols to address these issues.

Previous Work

The proposers of the OASIS ASAP TC anticipate that the TC will base its work on the asynchronous webservices protocol draft specification developed by Jeffrey Ricker and Keith Swenson. The authors of this work intend to contribute it to the new TC at its first meeting as described by the OASIS IPR Policy.

Relation to Other Efforts

• Workflow Management Coalition (WfMC). The ASAP specification is designed to be fully compatible with WfMC efforts. ASAP is intended to provide a more generic asynchronous capability that can be applied to workflow as well as other applications.
• W3C Web Services Description Language (WSDL) Working Group. The ASAP specification will employ WSDL and make WSDL easier for specifying asynchronous services.
• OASIS ebXML Message Services (MSG) specification version 2.0. The ASAP specification will be fully compatible with ebXML MSG.
• OASIS Web Services Business Process Execution Language. BPEL has already identified the need for asynchronous or long running services. However, asynchronous services are not particular to business processes. The ASAP specification will provide a generic means for asynchronous services that can be easily incorporated in BPEL as well as other protocols.
• OASIS Business Transaction Protocol (BTP) version 1.0. BTP focuses on coordination of transactions across organizations. A generic means for asynchronous services may complement BTP.
• OASIS Web Services Reliable Messaging (WSRM). Quality of service is specifically out of scope for The ASAP specification. Like ebXML MSG, it should be possible to make the ASAP specification fully compatible with WSRM.
• IETF RFC Simple Workflow Access Protocol (SWAP). The ASAP specification is a direct descendent of the work initial begun in SWAP. The ASAP specification attempts to fulfill using SOAP most of the objectives defined in SWAP.