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, [EMAIL PROTECTED] 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 [email protected]
To unsubscribe from this group, send email to [EMAIL PROTECTED]
For more options, visit this group at
http://groups.google.com/group/rife-users?hl=en
-~----------~----~----~----~------~----~------~--~---
