|
This package provides support classes for the implementation of
tool agents and applications. Unlike the {@link
de.danet.an.workflow.omgcore core API} and the {@link
de.danet.an.workflow.api extended API} (including the {@link
de.danet.an.workflow.spis.aii application invocation interface})
this package is not intended to be part of a general Java
workflow API. Rather, it provides some WfMOpen specific utilities
that ease the implementation of tool agents and applications to be
used with the WfMOpen workflow engine.
Using the asynchronous tool invocation API typically requires that the
activity and the data passed to the tool agent as parameters are
saved in persistent store. The tool (application) that is to actually work
with the information typically runs completely independent of the workflow
engine in another operating system process or at least in another thread.
It accesses the persisted information and e.g. presents the tasks that
require human interaction in a GUI. When the interaction has completed, the
application retrieves the activity and calls
"setResult()" and "complete()" on it.
To support the implementation of the function described above, this package
provides a
{@link de.danet.an.workflow.util.SimpleApplicationDirectory
SimpleApplicationDirectory}. This class
implements a general purpose persistent store for the data passed to the
tool agent (i.e. the activity and the actual parameters) and additional
state information. Tool agents create ("register") instances in this
directory. Each instance represents a tool invocation (task) currently
running in an external application. Creating an entry results in a unique
id that may subsequently be used to retrieve, update or remove the
instance. Instances may also be retrieved using an arbitrary key
associated with the instance by the registering tool agent, or by activity
or by searching instances assigned to a particular
WfResource.
Tool agents using the directory should be derived from
{@link de.danet.an.workflow.tools.util.SimpleApplicationAgent
SimpleApplicationAgent}. They can access the directory
by simply invoking the method {@link
de.danet.an.workflow.tools.util.SimpleApplicationAgent#applicationDirectory()
applicationDirectory()}. External application should use
the workflow service and
{@link de.danet.an.workflow.tools.util.SimpleApplicationDirectoryLookup
SimpleApplicationDirectoryLookup} to access the directory.
Applications that run within the application server (or components
running within the applictaion server that act on behalf of the external
application) may obtain the application directory's local interface
by looking it up in JNDI. The name to use for the lookup depends on
your application configuration, see section "Application and client
assembly", subsection "Workflow module" in the user manual.
Note that the directory may also be used to persist application state
across several tool agent invocations by {@link
de.danet.an.workflow.tools.util.SimpleApplicationDirectory#updateInvokingActivity
associating} an existing instance with a new activity. An example of this
requirement is the timer tool. One tool agent creates a timer in a
conceptually independently running application and gets an id for it.
Another tool agent may then cancel this time or wait for it to expire.
I.e. the task initiated by the first tool agent in the application runs
spans several tool agent invocations.
Entries in the directory are automatically cleaned when the process they
relate to (i.e. the activity's container) is removed.
@since V1.2
|