Workflakes provides a Cougaar-based workflow system that is coupled with Worklets mobile agents and coordinates their remote activities.

Current Version of Workflakes is 1.0
Dependencies:

The Workflakes application exploits Worklets in conjunction with Cougaar in two fundamental ways: For reference, most of the classes that implement shell plugins, their interfaces, WDJs and WEJs and the related support facilities are included in package {@link psl.workflakes.coolets} and its subpackages.

Notice that in case of the choice regarding actuators for Workflakes is different from Worklets, the plugin-based architecture of Workflakes cluster (see  below) allows to substitute Workflakes (and specifically WEJs) with another actuator technology at little cost.

To learn to use Workflakes, it is strongly advised in the first place to familiarize  with Cougaar, and its main concepts, which include nodes (Cougaar units of distribution ), clusters, plugins, assets (for representing facts and resources), dynamic planning, PSP (for reporting and communicating to the outside the state of the workflow) and so on.
An example of a small Workflakes society carrying out a simple workflow is found in the package for {@link psl.workflakes.exercise.tutorial}, which can be run as 2 communicating clusters, either running on the same Java Virtual Machine (a Cougaar Node) or on 2 different JVMs.

Insight  on Workflakes architecture

A typical Workflakes cluster appears as follows:

LDM plugins represent sources of facts and data exchanges with the external world; among those, one represents the repository of WEJs that are available to the cluster for dispatching as a response to given workflow tasks. External world data may for example represent triggers for a reactive workflow, once they are internalized into the blackboard by the appropriate LDM plugin.
In the Workflakes distribution, an example of an LDM shell plugin is provided, which allows to interface a cluster to the Siena event bus in a flexible fashion, which is programmable with appropriate WDJs.

Notice how a WVM is embedded in the cluster to allow docking of WDJs (see Figure on the left below) and dispatching of WEJs (handled in conjunction by AllocatorPlugIn and ExecutorPlugIn on the basis of the junction repository maintained by an LDM plugin- see Figure on the right below ). For substituting WEJs with some other actuation technology in Workflakes, it is sufficient to define new Allocator and Executor plugins with appropriate capbilities and ad hoc logic.

Incoming WDJs can define many facets of the workflow, such as:

Interactions between shell plugins and WDJs

It is noticeable the pattern with which a WDJ interacts with a shell plugin to "fill" it with some workflow logic. First of all, the code of each WDJ must be developed against a certain adaptor interface and an incoming WDJ expects the shell plugin to expose the appropriate adaptor.
The code injected into a plugin by a WDJ has three main parts:
Multiple WDJs can therefore be active at the same time within a plugin, each with its own set of subscriptions and callbacks.
Basic types adaptor interfaces for the most common types of shell plugins are found in the {@link psl.workflakes.coolets.adaptors} package.