org.hypergraphdb.peer.workflow
Class TransitionMap

java.lang.Object
  org.hypergraphdb.peer.workflow.TransitionMap

public class TransitionMap
extends java.lang.Object

Holds the definition of the FSM (Finite State Machine) associated with a particular Activity type. There are two kinds of transitions that can be associated with an activity:

• message transitions are triggered upon reception of a new message by another peer.
• sub-activity transitions are triggered upon a state of an activity of which the activity of interest is a parent.

Author:

Borislav Iordanov

Constructor Summary

TransitionMap()


Method Summary

Transition	getTransition(WorkflowStateConstant fromState, Activity fromActivity, WorkflowStateConstant atActivityState)
Transition	getTransition(WorkflowStateConstant fromState, java.util.Map<java.lang.String,? extends java.lang.Object> messageAttributes) Try to find an appropriate transition given the set of message attributes.
void	setTransition(WorkflowStateConstant fromState, java.util.Map<java.lang.String,java.lang.String> messageAttributes, Transition transition)
void	setTransition(WorkflowStateConstant fromState, java.lang.String subActivityType, WorkflowStateConstant atSubActivityState, Transition t)

Methods inherited from class java.lang.Object

equals, getClass, hashCode, notify, notifyAll, toString, wait, wait, wait

Constructor Detail

TransitionMap

public TransitionMap()

Method Detail

getTransition

public Transition getTransition(WorkflowStateConstant fromState,
                                java.util.Map<java.lang.String,? extends java.lang.Object> messageAttributes)

Try to find an appropriate transition given the set of message attributes. Transition defines for each of the attributes are considered and only if a unique matching transition can be determined, it will be returned. Otherwise, an exception is thrown. Unique matching is determined as follows:

1. For each message attribute A, consider the set of transitions S(A) defined for it. Ignore attributes for which no transitions have been defined.
2. Consider the intersection I of all those sets S(A).
3. If all sets S(A) interest into a single transition T, i.e. if I has only one element, then that transition is returned.
4. If I has no element that means that attributes point to different transitions and there's ambiguity - we throw an exception.
5. If I has more than one transition in it, then we try to find the unique one (if any) that is pointed exactly by the set of all As and by nothing else.

The reasoning behind the last rule might not be obvious: it allows one to define general transitions that are overriden for more specific cases. For example one could have a transition that's based on pair of attributes (performative=X, ontology=Y) and another that's based on a similar pair (performative=X, ontology=Z) that differs in the ontology attribute. One could then define a third transition that's based solely on the performative=X attribute and that handles all other cases where ontology != Y and ontology != Z.

Parameters:

fromState -

messageAttributes -

Returns:

setTransition

public void setTransition(WorkflowStateConstant fromState,
                          java.util.Map<java.lang.String,java.lang.String> messageAttributes,
                          Transition transition)

getTransition

public Transition getTransition(WorkflowStateConstant fromState,
                                Activity fromActivity,
                                WorkflowStateConstant atActivityState)

setTransition

public void setTransition(WorkflowStateConstant fromState,
                          java.lang.String subActivityType,
                          WorkflowStateConstant atSubActivityState,
                          Transition t)