[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Async vs Sync processes
Funny you should mention webMethods :) It is nice but literally a million
bucks. I just worked with it on my last project. It's pretty nice in a drag
and drop kind of way but is kind of a pain to integrate into your apps (lots
of your own pipeline parsing classes necessary, etc.). Comically enough, we
ran into a simlar issue (how to process transactions asynchronously) and the
webMethods consultants suggested a scheduled process to poll the db and put
things into wm flows.
Preliminary data seems to suggest that IBM does not have a work flow product
for websphere. They do for MQ, but that is a different group that deals with
data transfer, not workflow. Alas...
I would normally do this with triggers in the db, but lately everyone I've
been working with is trigger averse. For some reason, they prefer polling
>From: Curt Smith <firstname.lastname@example.org>
>To: Unlisted-recipients :;
>Subject: Re: Async vs Sync processes
>Date: Thu, 14 Nov 2002 10:54:08 -0500
>>There is some thought of having the processes that receive the async
>>responses (2.2 and 3.2) reinitiate the processes manually. But if there
>>are errors then we will need something that resubmits the orders after a
>>certain amount of time.
>Your business rules for this work flow mutex is fairly complex. A
>BPM / Work Flow tool/product would be helpful. If you've got
>a million bucks, WebMethods looks great. ;(
>Otherwise, a simple home grown and very purpose built tact might be:
>- persist each completed business event to a db / schema.
>- Use insert-triggers in the DB to kick off external processes based
>on the insert trigger's testing of that row's attributes.
>Note, this _is_ as hard wired of business logic as you can create.
>But, it's easy, cheap and works, which are often a critical set of
Protect your PC - get McAfee.com VirusScan Online