[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]