Re: Issue: Synchronous vs. Asynch.

My intention starts from another point of view. I think SWAP should be a 
protocol for workflow and because of this fact it should fulfil the needs
of workflow(-models). By the way this protocol should be more adapted to
workflow than any other protocol. 
Surely we can start with asynchronous calls and solve the problem of
syncronization at a higher level. But I think the SWAP project should 
also give a design or initiate an other poject to design this higher
communication level. Otherwise I think there is no gain at all if everybody
has to emulate synchronous calls on his own (an we don't end up with 
standardization).

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: Arthur S. Hitomi <ahitomi@zola.ics.uci.edu>
> An: Karsten Illing <k.illing@gis.ibfs.de>
> Cc: kswenson@ms2.com; gbolcer@ics.uci.edu; ietf-swap@w3.org
> Betreff: Re: Issue: Synchronous vs. Asynch. 
> Datum: Freitag, 16. Oktober 1998 21:46
> 
> I see your point for improving security, but the alternatives maybe
> sufficient at dealing with this problem at another layer (e.g. SSL,
> HTTPS)
> 
> It seems to me that asynchronous calls should be the basis for SWAP
> for several reasons 1) from an applications standpoint, processes tend
> to be asynchronous 2) As Keith pointed out earlier, processes are not
> ephemeral.  From my experience, transactions or events within workflow
> activities are relatively infrequent over time.  Asynchronous commands
> may seem less efficent in place of synchronous commands or events, but
> the infrequent nature combined with keep alive services of HTTP should
> keep the damage to a minimum.  3) It's always possible to order
> asynchronous calls with time or step attributes attached to events
> (similar to how streams are reorder in TCP).  This way the receiving
> end could choose to "handle" the event in synchronous or asynchronous
> fashion (at the cost of a little more complexity).
> 
> 
> 
> Art
> ----------------------------------------------------------------
> Arthur Shingen Hitomi			ICS2 (UCI Building 304)  
> PhD Graduate Student			Room 237
> Information and Computer Science	Irvine, CA 92697
> University of California, Irvine	Work: (949) 824-4101
> http://www.ics.uci.edu/~ahitomi/	Fax:  (949) 824-1715
> mail:arthur@uci.edu
> 
> 
> In message <19981015102213.29820.qmail@gis.ibfs.de>, Karsten Illing
writes:
> >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 Monday, 19 October 1998 03:46:12 UTC