RIFE/Workflow waitForEvent() Granularity

[Andrew]

I've been looking over your RIFE/Workflow project and i'm intrigued by
it's possible application.  I have the need to write a workflow
engine...many of the "job steps" that need to be performed by this
action are long latency operations ...i.e. calls to external web
services which may take many seconds before I can continue doing work
myself.  It seems like this might be a natural fit for utilizing
continuations in some fashion.

The primary question I have though is looking at your implementation
of com.uwyn.rifewf.Task and com.uwyn.rifewf.run.TaskRunner classes,
after calling the waitForEvent method, all continuations waiting for a
given Event class will be resumed.  But I'm fearing I need to be more
grainular about when i resume a given continuation.  For instance I
might have 20 continuations waiting on 20 different Web Service calls
to the same web service concurrently  each continuation can only
continue when it's specific request comes back, not when any of the 20
calls recieve their response.

The only way I can think to handle it is to have all the contuations
wake up and see if this given Event pertains to them...that is that
this is the response to the request that they previously issued....and
if it's not...then they waitForEvent again.  But that seems quite
inefficient.

So could you tell me if I'm thinking about this correctly and any
suggestions to solve this type of problem with continuations.
Depending on your response I plan to prototype a solution with RIFE/
workflow ASAP.

Thank you for your time,
Andrew
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "rife-users" group.
To post to this group, send email to rife-users@...
To unsubscribe from this group, send email to rife-users-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rife-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Andrew]

FYI...posting Geert's response as it may be valuable to others....

> I've been looking over your RIFE/Workflow project and i'm intrigued
> by it's possible application.  I have the need to write a workflow
> engine...many of the "job steps" that need to be performed by this
> action are long latency operations ...i.e. calls to external web
> services which may take many seconds before I can continue doing
> work myself.  It seems like this might be a natural fit for
> utilizing continuations in some fashion.

Sounds like it, indeed.

> The primary question I have though is looking at your implementation
> of com.uwyn.rifewf.Task and com.uwyn.rifewf.run.TaskRunner classes,
> after calling the waitForEvent method, all continuations waiting for
> a given Event class will be resumed.  But I'm fearing I need to be
> more grainular about when i resume a given continuation.  For
> instance I might have 20 continuations waiting on 20 different Web
> Service calls to the same web service concurrently  each
> continuation can only continue when it's specific request comes
> back, not when any of the 20 calls recieve their response.
>
> The only way I can think to handle it is to have all the contuations
> wake up and see if this given Event pertains to them...that is that
> this is the response to the request that they previously
> issued....and if it's not...then they waitForEvent again.  But that
> seems quite inefficient.

With the current implementation, that is a limitation indeed.

> So could you tell me if I'm thinking about this correctly and any
> suggestions to solve this type of problem with continuations.
> Depending on your response I plan to prototype a solution with RIFE/
> workflow ASAP.


It shouldn't be difficult to add proper support for this though.
The
'trigger' method of TaskRunner already supports data for events.
You
could change the waitForEvent method to not wait for the event
type,
but for a wrapper object instead. That wrapper can then contain the
event type class and another field. This field could either be the
data that you're waiting for, or even better, an instance of a
'condition' class that is able to evaluate the data that is sent.

This additional condition can be stored inside the TaskRunner for
each
continuation ID. Then, when the trigger method executes, instead of
always waking up every continuation that corresponds to the
triggered
event, the condition object can be looked up and evaluated. Only
when
that returns true, the continuation would be woken up.

Does that sounds feasible?

Hope this helps,

Geert

--
Geert Bevin
Terracotta - http://www.terracotta.org
Uwyn "Use what you need" - http://uwyn.com
RIFE Java application framework - http://rifers.org
Music and words - http://gbevin.com

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "rife-users" group.
To post to this group, send email to rife-users@...
To unsubscribe from this group, send email to rife-users-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rife-users?hl=en
-~----------~----~----~----~------~----~------~--~---

[Andrew]

I also realized that I can simply extend EventType in the following
way:

public class UniqueEventType {
   public String uniqueIdentifier;

   public UniqueEventType(String id) {
     this.uniqueIdentifier = id;
   }

  @Override
  public String getType() {
    return this.uniqueIdentifier;
  }
}

I can then instantiate an instance of  UniqueEventType...with a
generated unique identifier.  Seems practical enough.

-Andrew

On Nov 21, 12:04 pm, decr...@... wrote:

> FYI...posting Geert's response as it may be valuable to others....
>
> > I've been looking over your RIFE/Workflow project and i'm intrigued
> > by it's possible application.  I have the need to write a workflow
> > engine...many of the "job steps" that need to be performed by this
> > action are long latency operations ...i.e. calls to external web
> > services which may take many seconds before I can continue doing
> > work myself.  It seems like this might be a natural fit for
> > utilizing continuations in some fashion.
>
> Sounds like it, indeed.
>
> > The primary question I have though is looking at your implementation
> > of com.uwyn.rifewf.Task and com.uwyn.rifewf.run.TaskRunner classes,
> > after calling the waitForEvent method, all continuations waiting for
> > a given Event class will be resumed.  But I'm fearing I need to be
> > more grainular about when i resume a given continuation.  For
> > instance I might have 20 continuations waiting on 20 different Web
> > Service calls to the same web service concurrently  each
> > continuation can only continue when it's specific request comes
> > back, not when any of the 20 calls recieve their response.
>
> > The only way I can think to handle it is to have all the contuations
> > wake up and see if this given Event pertains to them...that is that
> > this is the response to the request that they previously
> > issued....and if it's not...then they waitForEvent again.  But that
> > seems quite inefficient.
>
> With the current implementation, that is a limitation indeed.
>
> > So could you tell me if I'm thinking about this correctly and any
> > suggestions to solve this type of problem with continuations.
> > Depending on your response I plan to prototype a solution with RIFE/
> > workflow ASAP.
>
> It shouldn't be difficult to add proper support for this though.
> The
> 'trigger' method of TaskRunner already supports data for events.
> You
> could change the waitForEvent method to not wait for the event
> type,
> but for a wrapper object instead. That wrapper can then contain the
> event type class and another field. This field could either be the
> data that you're waiting for, or even better, an instance of a
> 'condition' class that is able to evaluate the data that is sent.
>
> This additional condition can be stored inside the TaskRunner for
> each
> continuation ID. Then, when the trigger method executes, instead of
> always waking up every continuation that corresponds to the
> triggered
> event, the condition object can be looked up and evaluated. Only
> when
> that returns true, the continuation would be woken up.
>
> Does that sounds feasible?
>
> Hope this helps,
>
> Geert
>
> --
> Geert Bevin
> Terracotta -http://www.terracotta.org
> Uwyn "Use what you need" -http://uwyn.com
> RIFE Java application framework -http://rifers.org
> Music and words -http://gbevin.com

--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups "rife-users" group.
To post to this group, send email to rife-users@...
To unsubscribe from this group, send email to rife-users-unsubscribe@...
For more options, visit this group at http://groups.google.com/group/rife-users?hl=en
-~----------~----~----~----~------~----~------~--~---