Re: Issue: Synchronous vs. Asynch.

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 Friday, 16 October 1998 16:02:34 UTC