Re:SWAP Working Group Charter -- Any comments/sugg

Hello Surendra,
The charter is pretty much okay with me.

My comment: In the "In-Scope-Goals" you mention
Basic Auditing Functions. I think this should really only
be basic, otherwise it can get complex, too complex for a first
version of SWAP. I also see a great potential in
"Subscribe and receive events from the service", but again,
there seems to be quite some debate going on here, and I do not
know whether we arrive at a satisfactory solution with verision 1.0.

Best regards
Rainer
SAP AG

------------------------------


I have posted an updated SWAP WG charter to this list couple of days
back
and not seen any feedback on the charter yet. It is important to agree
on
the charter so that we can send the updated charter to Area Director for
consideration of SWAP as an official working group.
I would really appreciate if you can take sometime and review the
charter:
If you agree with this charter or any suggestions/comments, please post
them to the list.

--Surendra

SWAP -- Simple Workflow Access Protocol Working Group

Chair(s)

   * Surendra Reddy (skreddy@us.oracle.com)

Applications Area Director(s):

   * Keith Moore <moore+swap@cs.utk.edu>
   * Patrik Faltstrom <paf@swip.net>

Area Advisor

   * TBD

Mailing List Information

   * General Discussion: ietf-swap@imc.org
   * To Subscribe: send msg to ietf-swap-request@imc.org with
"subscribe"
     in subject
   * Archive:http://www.imc.org/ietf-swap/
   * Documents: http://www.ics.uci.edu/pub/ietf/swap/

Problem Statement

Currently all services or processes on the Internet are well suited for
short
lived interactions between users and systems that provide information
and
services. There is no standard way to support long running interactions
on the Internet. A standard protocol is needed to integrate work
providers and
asynchronous services across the Internet and provide for creating the
work,
setting up the work, starting the work, stopping the work, being
informed of
exceptions, being informed of the completion of the work, getting the
results
of the work, checking on the current status of the work and getting a
history
of the execution of the work.

Workflow service is a good example of a generic service which when
invoked
can take anywhere from minutes to months to complete, so this protocol
can be
used to initiate workflows without being concerned with how the
workflow system
accomplishes it.  Secondly, workflow services are used to invoke and
coordinate
external asynchronous services, and this protocol allows a standard way
to plug
generic services from anywhere on the Internet into a workflow process.


Description of Working Group

The purpose of this working group is to provide a simple protocol to
invoke,
monitor, control, and be informed about a generic asynchronous service.

An ad-hoc group has analyzed the functional needs of several
organizations,
and has developed requirements for Simple Workflow Access Protocol.
These requirements encompass the following capabilities, which SHALL BE
considered by this working group:

IN-SCOPE GOALS:

   * a standard way to start, stop and monitor a generic service
   * query the status of the service,
   * pass data values to the service
   * pause or resume the service,
   * retrieve preliminary results of the service,
   * subscribe and receive events from the service.
   * basic auditing functions
   * internationalization
   * security considerations

NOT IN SCOPE:

Many decisions have been made to reduce the scope of this working
group.
This working group will limit its scope to the IN-SCOPE goals and will
not address the following issues, unless they are critical for
successful
completion of the IN-SCOPE goals:

    * exchange of process definition
    * transactions
    * statistics gathering or monitoring of processes other than
retrieving
      the status of the specific instance of a service.
    * administration functions such as installation or general
      management of a service
    * presentation of data to humans in HTML or other types of form
layout.

Deliverables

The final output of this working group is expected to be three
documents:

1. A requirements document, which describes the high-level functional
   requirements for Simple Workflow Access Protocol, including
rationale.

2. A scenarios document, a description of how this protocol can be used
   effectively.

3. A protocol specification, which describes methods, request bodies,
and
   response bodies, to implement the  Simple Workflow Access Protocol
   requirements.

Goals and Milestones

 DONE    Hold the first meeting on May 4 & 5, '98 of the ad-hoc
         group. Review the initial version of the specification
document.
         Review the charter for the working group, and decide on a final
         form to be used to propose the formation of the working group.

 DONE    (Aug '98) Submit initial version of the requirements document
	 as an I-D.

 Aug 98  Initial version of the scenarios document distributed for
review
         within the working group.

 Nov 98  Submit revised versions of all  Requirements, Scenarios and
         Protocol documents as Internet-Drafts.

 Dec 98  Meet in 43rd IETF in Orlando, review requirements and Scenarios
	 documents.

 Jan 99  Submit all Requirements and Scenario drafts as Informational
RFCs

 Feb 99	 Issue WG last call for protocol specification

 Mar 99	 Meet in 44th IETF, and review the final specification

 Apr 99  Submit SWAP specification as a proposed standard

Current Internet-Drafts

	Requirements for Simple Workflow Access Protocol(http://
	www.ietf.org/internet-drafts/draft-sreddy-swap-requirements-01.txt)

	SWAP Specification(strawman) ( http://www.ietf.org/internet-drafts/
	draft-swenson-swap-prot-00.txt).

No Request For Comments

Received on Wednesday, 30 September 1998 06:45:43 UTC