1 Reply Latest reply on May 5, 2008 4:53 AM by tom.baeyens

signals

tom.baeyens May 5, 2008 4:29 AM

i think there is a problem with the current approach to signals in the pvm.

i think Guillaume already mentioned once that signals were not type safe. that's true from a java point of view. but the solution that i'll present here (to be verified if that can be worked out) takes a broader, process perspective

currently, the signals are interpreted by the activity at runtime. any signal can be given at any time. eventually the external entity like a task or an service invocation entity or the user in the API, will call the signal method.

i think we can and should incorporate the external entity concept into the pvm itself.

an activity shoud calculate the potential external triggers when the execution goes into a wait state and provide them to the execution. This can be done by adding a parameter singals to the waitForSignal() method.

And the signal method requires to use one of those signals to be triggered.

interface Execution {
...
// to be called by the activity impl
void waitForSignal(Set signals);

// to be called by the external user
void signal(Signal signal);

// introspection method to see what external triggers are currently
// available on this execution
Set getSignals();
...
}

Somehow, I want that signal is an interface. The PVM itself should not be involved with the persistence of the signals so that things like a task (outside PVM) can implement Signal, but are not forced in any of the hibernate class hierarchy mappings.

That's what I'm going to try and find out now to see how/if that is possible. In the meantime all ideas/critisisms are welcomed.

1. Re: signals

tom.baeyens May 5, 2008 4:53 AM (in response to tom.baeyens)

please ignore this post. forget about it :-)

The motivation to look into typed signals was to force some kind of activity instance. Now I remember why I didn't do it before: there is no other way then to force a lot of overhead. First, for each external trigger, an extra record would need to be kept. Second, in the runtime transition, the input signal would need to be matched and converted into a signal that is extracted from the execution.

There are 2 ways to look at state machine execution:

1) you just feed in the external signals. it's up to the caller (and his architecture) to know what triggers that can be fed into the state machine.

2) you ask the state machine the trigger before you signal it.

I think that both options should be possible. In the original post on this topic, I wanted to exclude one, which is not good.

I only now realize that you can do 2 also with the current API's: an activity instance id can be generated by the activity and made available somehow to the client (SignalDefinition?). Then the client can pass the activity instance id with the parameters. the activity can then check it if it wants to.

I'll see if i can work out a simple wait state in both ways to show what i mean.
Actions