Scope of ASAP

[Jeffrey Ricker <jricker@izarinc.com>]

This is the statement of scope as it exists now. What do we need to
discuss, add, remove, resolve, emphasize, etc. to get the draft out the
door?


1. The protocol should not reinvent anything unnecessarily. If a
suitable standard exists, it should be used rather than re-implemented a
different way.
        
     2. The protocol should be consistent with XML Protocol and SOAP.
        
     3. This protocol should be easy to incorporate into other
        SOAP-based protocols that require asynchronous communication
        
     4. 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.
        
     5. 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.
        
     6. Like other Internet protocols, ASAP should not require or make
        any assumptions about the platform or the technology used to
        implement the generic asynchronous service.
        
     7. Terseness of expression is not a goal of this protocol. Ease of
        generating, understanding and parsing should be favored over
        compactness. 
        
8.The goals of ASAP 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 workflow service, ASAP does not provide a way to retrieve or submit
process definitions. The service can be considered to be a "black box"
which has been pre-configured to do a particular process. ASAP does not
provide a way to discover what it is that the service is really doing,
only that it does it (given some data to start with) and some time later
completes (providing some result data back).

9. ASAP will NOT include the ability to perform maintenance of the
asynchronous webservice such as installation or configuration. 

10. ASAP will NOT support statistics or diagnostics of collections of
asynchronous webservices. ASAP is designed for the control and
monitoring of individual asynchronous webservices.

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

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