| This interface marks a tool agent as requiring no or only read-only
access to the activity passed to
de.danet.an.workflow.spis.aii.ToolAgent.invokeinvoke .
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.
author:
Michael N. Lipp
version:
$Revision: 1.2 $ |