OASIS Asynchronous Web Service TC

As shown in the attached email, OASIS is starting up a TC to consider
asynchronous services.  Quoting from below, 

"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."

-----Original Message-----
From: Karl F. Best [mailto:karl.best@oasis-open.org] 
Sent: Tuesday, August 05, 2003 12:45 PM
To: members@lists.oasis-open.org; tc-announce@lists.oasis-open.org;
xml-dev@lists.xml.org; asap@lists.oasis-open.org
Subject: [OASIS members] OASIS TC Call For Participation - OASIS ASAP TC


A new OASIS technical committee is being formed. The OASIS Asynchronous 
Service Access Protocol Technical Committee (ASAP TC) has been proposed 
by the following members of OASIS: Keith D Swenson, Fujitsu; Moshe 
Silverstein, IWay Software, and Jeffrey Ricker, individual member.

The proposal for a new TC meets the requirements of the OASIS TC Process

(see http://oasis-open.org/committees/process.shtml), and is appended to

this message. The proposal, which includes a statement of purpose, list 
of deliverables, and proposed schedule, will constitute the TC's 
charter. The TC Process allows these items to be clarified (revised) by 
the TC members; such clarifications (revisions), as well as submissions 
of technology for consideration by the TC and the beginning of technical

discussions, may occur no sooner than the TC's first meeting.

As specified by the OASIS TC Process, the requirements for becoming a 
member of the TC are that you must 1) be an employee of an OASIS member 
organization or an Individual member of OASIS; 2) notify the TC chair of

your intent to participate at least 15 days prior to the first meeting; 
and 3) attend the first meeting of the TC.

For OASIS members, to sign up for the TC using the new OASIS 
collaborative tools, go to the TC's public page at 
http://www.oasis-open.org/committees/asap and click on the button for 
"Join This TC" at the top of the page. You may add yourself to the 
roster of the TC either as a Prospective Member (if you intend to become

a member of the TC) or an Observer. A notice will automatically be sent 
to the TC chair, which fulfills requirement #2 above. You must sign up 
for membership at least 15 days before the first meeting and must attend

the first meeting of the TC in order to become a member.

Note that membership in OASIS TCs is by individual, and not by
organization.

For non-OASIS members, a public comment list 
asap-comment@lists.oasis-open.org is available for the public to make 
comments on the work of this TC; the public may subscribe to this list 
by going to the mail list web page at
http://lists.oasis-open.org/ob/adm.pl.

The archives of the TC's private and comment mail lists are visible to 
the public at http://lists.oasis-open.org/archives/

Further information about this topic may be found on the Cover Pages 
under the topic of "Asynchronous Transactions and Web Services" at 
http://xml.coverpages.org/async.html

-Karl

=================================================================
Karl F. Best
Vice President, OASIS
office  +1 978.667.5115 x206     mobile +1 978.761.1648
karl.best@oasis-open.org      http://www.oasis-open.org


Name

The name of the technical committee is the OASIS Asynchronous Service 
Access Protocol (ASAP) Technical Committee

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.

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.

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.


Language

US English


First meeting

First meeting will be teleconference to be held on September 9, 2003, at
1pm ET.


Meeting schedule

Meetings will be held regularly on every other Tuesday at 1pm for the 
first three months. After the first set of deliverables, the committee 
will meet once a month to complete the specification. After the 
specification is submitted to OASIS, the committee will continue to meet

in order to address implementation issues that may arise.


Members

Jeffrey Ricker, jricker@izarinc.com, Individual member
Keith D Swenson, kswenson@fsw.fujitsu.com, Fujitsu
Moshe Silverstein, moshe_silverstein@iwaysoftware.com, IWay Software


Chairman

Jeffrey Ricker


Meeting sponsors

Izar Associates and iWay Software.

Received on Tuesday, 5 August 2003 14:42:28 UTC