Re: Issue: Synchronous vs. Asynch.

Its the latter case. Because think of critical processes in certain
industry (e.g.chemical industry). Your aim is to provide secure maintenance

of the system, so you support the maintenance process with workflow. Before
you start with the work at any part of your production place, you have to
fulfill some prerequisites (e.g. no pressure in the system e.t.c) for 
security reasons. If the acknowledge of the fulfillmemt of this is returned
to the workflow engine, the next step, the start of the maintenance is
offered. At the same time, an error in the prerequisites or in the planning
of the maintenance is detected and the start-of-maintenance-step is
suspended. If the suspension of this step will be invoked asyncronously,
somebody might start with the work and security problems arise. This step
has to be canceled immediately an not delayed 'for better times'.
This example might not be the best example, but you have the need for 
syncronisation in every workflow. An other example is an original print of 
some document (e.g. an insurance policy) where you can have only one
'original print'. If the print is started and at the same time there is a
change issued, the print action has to be suspended or the change-step has 
to be suspended, iff the print action can't be suspended. This can't be
done
asyncronously.
Of course, there are problems if your connection to the remote system is
lost, but that's another problem.

Karsten

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

  Karsten Illing
  GiS Gesellschaft fuer integrierte Systemplanung mbH
  Abt. Softwareentwicklung SE/S
  Junkersstrasse 2
  D-69469 Weinheim

  Tel.:[+49] 6201/503-46
  Fax.:[+49] 6201/503-66
  EMail:k.illing@gis.ibfs.de 
----------------------------------------------------------------------------

         
----------
> Von: kswenson@ms2.com
> An: k.illing@gis.ibfs.de; gbolcer@ics.uci.edu; ietf-swap@w3.org
> Betreff: RE: Issue: Synchronous vs. Asynch.
> Datum: Donnerstag, 15. Oktober 1998 10:36
> 
> 
> Could you expand on the details of this example a little?
> Are you saying that you have a well-defined resting state
> of the workflow engine that for some period of time that it
> is in that state can not be suspended?  Or are you saying that
> there are some transient operations that must not be interupted?
> 
> ----------------------------------------------------------------
> Keith D. Swenson, kswenson@ms2.com, MS2 Inc.
> 2440 W. El Camino Real, Mountain View, CA, 94040
> tel: +1 650 623-2329,  fax: +1 650 967-7394
> 
> 
> > -----Original Message-----
> > From: Karsten Illing [mailto:k.illing@gis.ibfs.de]
> > Sent: Thursday, October 15, 1998 1:05 AM
> > To: gbolcer@ics.uci.edu; ietf-swap@w3.org
> > Subject: Re: Issue: Synchronous vs. Asynch.
> > 
> > 
> > I agree with Christoph Bussler that it should be possible for 
> > the caller to
> > chosse between a synchronous or asyncronous suspend command. 
> > The reason why
> > I support the customizable way is my experience with our own 
> > workflow. 
> > There are some special points in the process where you will get data 
> > inconsitency, if you have asyncronous suspend commands. It is 
> > not possible
> > to avoid these points for synchronous suspension.
> > 
> > Karsten
> >

Received on Thursday, 15 October 1998 05:44:13 UTC