Package de.danet.an.workflow.tools.util

This package provides support classes for the implementation of tool agents and applications.

See:
Description

Interface Summary

DirectInvocable	This interface marks a tool agent as requiring no or only read-only access to the activity passed to invoke.
SimpleApplicationDirectory	Remote interface for SimpleApplicationDirectory.
SimpleApplicationDirectoryHome	Home interface for SimpleApplicationDirectory.
SimpleApplicationDirectoryLocal	Local interface for SimpleApplicationDirectory.
SimpleApplicationDirectoryLocalHome	Local home interface for SimpleApplicationDirectory.

Class Summary

SimpleApplicationAgent	This is a base class for writing agents for applications that have a life cycle exceeding a single tool agent invocation, and have only state information that can efficiently be persisted as a binary large object in an RDBMs.
SimpleApplicationDirectoryEJB	This EJB provides a directory for simple applications.
SimpleApplicationDirectoryLookup	This class provides a Batch implementation that looks up and returns the remote interface of the SimpleApplicationDirectory.
SimpleApplicationInfo	This class provides a container for the application instance information managed by the SimpleApplicationDirectory.

Package de.danet.an.workflow.tools.util Description

This package provides support classes for the implementation of tool agents and applications. Unlike the core API and the extended API (including the 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 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 SimpleApplicationAgent. They can access the directory by simply invoking the method applicationDirectory(). External application should use the workflow service and 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 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