OASIS Asynchronous Service Access Protocol TC

Asynchronous Service Access Protocol (ASAP) TC

The original Call For Participation for this TC may be found at http://lists.oasis-open.org/archives/tc-announce/200308/msg00004.html

The charter for this TC is as follows.

Name

OASIS Asynchronous Service Access Protocol (ASAP) Technical Committee

Statement of Purpose

The purpose of the OASIS ASAP TC is to create a very simple extension of Simple Object Access Protocol (SOAP) that enables generic asynchronous webservices or long-running webservices.

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.

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.

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.

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.

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.

List of Deliverables

With three months, the OASIS ASAP TC intends to deliver:

  • Initial draft specification
  • Introduction with examples
  • Reference implementation
  • WSDL specification

Within five months, the TC intends to deliver the completed specification.

 

TOP OF PAGE