Inter-Process Communication
cappelaere
I start a workflow with some parameters.
the process kicks-off some activities.
one activity starts another workflow somewhere else using a REST API.
How would that activity know when the remote process is done and get
the resulting data back from it?
1. Keep polling. Not very clever.
2. Receive a message when it is done. Would you use some notification
service? like Amazon SQS?
What is the group's experience in that area?
Pat.
John Mettraux
On 8/8/07, cappelaere <cappe...@gmail.com> wrote:
>
> Here is my use-case:
> I start a workflow with some parameters.
> the process kicks-off some activities.
> one activity starts another workflow somewhere else using a REST API.
It could also simply launch a subprocess.
> How would that activity know when the remote process is done and get
> the resulting data back from it?
So my question is, is that activity waiting for that subprocess ? Or
is it doing something else while the "subprocess" is running ?
Best regards,
--
John Mettraux -///- http://jmettraux.openwfe.org
Pat Cappelaere
sub-process. In this particular case, I am more interested in execute a
workflow running on a different machine.
The activity would wait for resulting data.
Pat.
John Mettraux
>
> The specific activity of the running workflow could indeed execute a
> sub-process. In this particular case, I am more interested in execute a
> workflow running on a different machine.
> The activity would wait for resulting data.
Hi Pat,
thanks for the clarification.
I haven't ported/rewritten the mechanisms for doing that from
OpenWFEja to OpenWFEru.
It was usually done by registering the remote engine as a participant.
The workitem from the local engine to the remote engine would be
transformed into a launchitem and dispatched to the remote engine (by
the participant standing for it).
I'd be glad to work on that again, to make OpenWFEru more complete
(and powerful). Your input on that is much welcome. (We should maybe
discuss that on the dev mailing list).
Cheers,
cappelaere
As you know this is a hot topic in the Wf-XML area. We are currently
looking at a RESTFul approach to it and I owe you a document (coming
soon). Short of sharing the document that is currently half-baked,
here is my current thoughts:
A remote engine is REST-accessible and any activity can easily launch
a remote process.
Calling activity would have access to remote process status & data
(using a GET).
Better, this calling activity could be exposed as a URI somehow and
subscribe to process event notification. Calling activity waits for
response, gets the message and continues on.
This does not appear as a huge stumbling block...
V/R,
Pat.
On Aug 8, 8:21 pm, "John Mettraux" <jmettr...@openwfe.org> wrote:
John Mettraux
On 8/10/07, cappelaere <cappe...@gmail.com> wrote:
>
> John,
> As you know this is a hot topic in the Wf-XML area. We are currently
> looking at a RESTFul approach to it and I owe you a document (coming
> soon). Short of sharing the document that is currently half-baked,
> here is my current thoughts:
>
> A remote engine is REST-accessible and any activity can easily launch
> a remote process.
> Calling activity would have access to remote process status & data
> (using a GET).
>
> Better, this calling activity could be exposed as a URI somehow and
> subscribe to process event notification. Calling activity waits for
> response, gets the message and continues on.
> This does not appear as a huge stumbling block...
Indeed,
maybe I could write a stub of a participant that triggers a webservice
REST or SOAP and waits for the reply.
How do you envision the reply part ? (I will read the document to find
out and maybe comment in this thread).
TTYS, cheers,
Pat Cappelaere
It is almost like we need a way for an activity (participant in OpenWFE) to
consume a workitem, send the request and wait for an asynchronous response.
The response comes back to the Workflow Service sitting on top of OpenWFE.
It then needs to find the relevant participant and send the response.
Not sure if we want an internal software bus within OpenWFE to do this or if
the task needs to suspend itself and get restarted by the engine when the
response comes in.
Pat.
> From: John Mettraux <jmet...@openwfe.org>
> Reply-To: <openwfe...@googlegroups.com>
> Date: Fri, 10 Aug 2007 17:45:22 +0900
> To: <openwfe...@googlegroups.com>
> Subject: [openwferu-users] Re: Inter-Process Communication
>
>
cappelaere
Participant executes activity, sends the request, serializes its
workitem to disk.
If this participant has a unique ID that identify itself by name and
by instance, a URI can be generated to eventually retrieve that
participant instance.
Participant goes away after saving workitem
Response comes back eventually
WfCS reinstantiates participant with received response. Participant
retrieves workitem and processes the response. It eventually releases
workitem to engine.
This would be easy to do,
WDYT?
Pat.
On Aug 10, 8:05 am, Pat Cappelaere <cappela...@gmail.com> wrote:
> John,
>
> It is almost like we need a way for an activity (participant in OpenWFE) to
> consume a workitem, send the request and wait for an asynchronous response.
> The response comes back to the Workflow Service sitting on top of OpenWFE.
> It then needs to find the relevant participant and send the response.
> Not sure if we want an internal software bus within OpenWFE to do this or if
> the task needs to suspend itself and get restarted by the engine when the
> response comes in.
> Pat.
>
> > From: John Mettraux <jmettr...@openwfe.org>
> > Reply-To: <openwfe...@googlegroups.com>
> > Date: Fri, 10 Aug 2007 17:45:22 +0900
> > To: <openwfe...@googlegroups.com>
> > Subject: [openwferu-users] Re: Inter-Process Communication
>
> > Hi Pat,
>
John Mettraux
>
> A simpler approach that may already be there...
>
> Participant executes activity, sends the request, serializes its
> workitem to disk.
> If this participant has a unique ID that identify itself by name and
> by instance, a URI can be generated to eventually retrieve that
> participant instance.
> Participant goes away after saving workitem
> Response comes back eventually
> WfCS reinstantiates participant with received response. Participant
> retrieves workitem and processes the response. It eventually releases
> workitem to engine.
>
> This would be easy to do,
Well, OpenWFEru already does it that way. All the expressions have
always been asynchronous, else it's not possible to support long
running [business] processes.
I'm quite busy right now (friend visiting), I will reply with a long
mail later, but in short, all you mentioned is already implemented by
OpenWFEru else I would never have dared calling it a workflow / BPM
engine. I'm quite surprised you didn't already know.
TTYL, best regards,