Interface DirectInvocable

public interface DirectInvocable

This interface marks a tool agent as requiring no or only read-only access to the activity passed to invoke.

The issue arises from the necessity to invoke the tool agent in its own transaction. In order to provide the tool agent with full access to the activity, the activity must not be involved in another transaction. However, as tool agent invocation obviously updates the state of the activity, the activity (having its state updated) is involved in a transaction when the tool agent is invoked. To resolve this, WfMOpen does not invoke the tool agent directly. Rather, its sends a message to a tool agent invocation queue as part of the state update transaction and completes the transaction. The message is then retrieved from the queue and the tool agent is invoked without involving the activity in the message handling transaction.

Of course, this induces a considerable overhead which can be avoided if the tool agent accesses the activity not at all or uses only the methods key, activityUniqueKey or container. Experience shows that this is true for a lot of tool agents; either because they let an application running in another thread or process do the work, or because they use the ResultProvider interface and do not require access to the activity. If a tool agent satisfies these criteria, it may make this known to the workflow engine by implementing this marker interface. If a tool agent implements this interface, the engine does not put a message on the tool invocation queue but rather invokes the tool agent directly during state update.

Note that since the activity is involved in the state update transaction, the engine cannot call setResult and complete in a new transaction after tool agent invocation. Rather, these methods will be called in the same transaction as the tool agent invocation. Thus if RemoteExceptions occur when these methods are called by the workflow engine, the complete transaction, including the tool invocation, will be repeated. Tools that are "expensive" to execute or have side effects should not implement DirectInvocable.

$Revision: 1607 $
Michael N. Lipp