Last commit for overview.html: 4e556e5fe542d0e2d959d6ace3114d0dc9fb8c84

This is the workflakes version as used in the TILAB demo.

valetto [2002-04-12 09:37:40]
This is the workflakes version as used in the TILAB demo.
It's a new major baseline, which includes numerous new plugins, javadocs and more.
  1. <!doctype html public "-//w3c//dtd html 4.0 transitional//en">
  2. <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1">
  3. <meta name="Author" content="Valetto Giuseppe">
  4. <meta name="GENERATOR" content="Mozilla/4.79 [en] (Windows NT 5.0; U) [Netscape]">
  5. <title>Workflakes overview</title>
  6. </head>
  7. Workflakes provides a Cougaar-based workflow system
  8. that is coupled with Worklets mobile agents and coordinates their remote
  9. activities.
  10. <p>Current Version of Workflakes is <b>1.0</b>
  11. <br>Dependencies:
  12. <ul>
  13. <li>
  14. Cougaar 7.x (migration to 8.x is under way) - see&nbsp; <a href="http://www.cougaar.org">Cougaar.org</a>
  15. : Cougaar is an open-source Java-based decentralized coordination infrastructure
  16. on top of which a workflow formalism can be implemented. Cougaar task processors
  17. are called <i>clusters.</i> Multiple clusters can be distributed over a
  18. network and communicate data among each other via a blackboard mechanism.
  19. Furthermore, clusters contain and run collections of <i>PlugIns. </i>While
  20. clusters are purely part of the infrastructure, plugins can provide application
  21. logic to a <i>society</i> of clusters, i.e. describe and run the workflow
  22. that follows under the responsibility of that society. There are a number
  23. of "canonic" plugins to carry out most typical duties in a workflow, such
  24. as:</li>
  25.  
  26. <ul>
  27. <li>
  28. manipulating data</li>
  29.  
  30. <li>
  31. publishing workflow tasks</li>
  32.  
  33. <li>
  34. expanding tasks in hierarchies of subtasks</li>
  35.  
  36. <li>
  37. allocating resources to tasks</li>
  38.  
  39. <li>
  40. planning the execution of the workflow over time</li>
  41.  
  42. <li>
  43. enacting and supervising it,</li>
  44.  
  45. <li>
  46. and so on.</li>
  47. </ul>
  48. Most canonical plugins are included in the Cougaar distribution. It is
  49. the responsibility of the application programmer to specialize the Java
  50. classes representing those plugins to augment it with the correct logic
  51. for the workflow at hand. (For more information, see the extensive Cougaar
  52. <a href="http://www.cougaar.org">training
  53. material</a> )
  54. <li>
  55. Worklets - see&nbsp; <a href="http://www.psl.cs.columbia.edu">PSL labs</a>
  56. at Columbia University: Worklets is a Java-based&nbsp; mobile agents platform.
  57. A Worklet is a mobile container of code snippets named <i>worklet junctions,</i>
  58. which travels from host to host and deposit a junction at each spot. Deposited
  59. junctions are executed by <i>Worklet Virtual Machines</i>&nbsp; ({@link
  60. psl.worklets.WVM WVMs}) residing on the target hosts.</li>
  61. </ul>
  62. The Workflakes application exploits Worklets in conjunction with Cougaar
  63. in two fundamental ways:
  64. <ul>
  65. <li>
  66. To define and upload a workflow dynamically onto an existing Cougaar society.
  67. Workflakes includes a set of <b>Workflow Definition Junctions</b> (WDJs)
  68. - i.e. special-purpose worklet junctions that can be shipped on board of
  69. worklets to a Cougaar cluster, to provide behavior and logic to <i>shell
  70. plugins. </i>The base class for WDJs is {@link psl.workflakes.coolets.CooletIncomingJunction}<i>.
  71. </i>Shell
  72. plugins are another peculiarity of Workflakes: they are specialization
  73. of Cougaar basic plugin class, which expose some interfaces devoted to
  74. all of the main duties in a workflow system (see above) but with no internal
  75. logic. The base class for shell plugins is {@link psl.workflakes.coolets.WorkletPlugIn}<i>.
  76. </i>Shell
  77. plugins can accommodate and run WDJs that match their interfaces. This
  78. way WDJs can inject logic in a cluster from the outside, which leads to
  79. ease of reuse and evolution of the workflow. It is noticeable that - in
  80. principle - WDJs can be uploaded onto a community either with a push or
  81. a pull paradigm. Push is currently favoured, although a primitive library
  82. to support ontology-based detection and pull of WDJs from a factory had
  83. been implemented as {@link psl.workflakes.smartinf the Smart Interface
  84. package}, which is right now in practice <b><i>deprecated</i></b> since
  85. it's not up to par with the rest of Workflakes and needs some serious restoration
  86. work.</li>
  87.  
  88. <li>
  89. To execute work in the "real world". The workflow defined and executed
  90. within a Cougaar society cannot have any side effects in the real world
  91. unless we provide some computational capabilties that are able to carry
  92. out the work symbolized by Workflow tasks (at least the hierarchy leafs).
  93. Workflakes includes to this end <b>Workflow Execution Junctions</b> (WEJs,
  94. also called Actuation junctions) - i.e. specialized worklet junctions that
  95. can be associated to the definition of workflow tasks and then dispatched
  96. from clusters onto external WVMs for executing there computations corresponding
  97. to those workflow tasks. Such WVMs with the interfaces they expose to incoming
  98. WEJs are maintained as internal information on the blackboard of the Workflakes
  99. system.</li>
  100. </ul>
  101. For reference, most of the classes that implement shell plugins, their
  102. interfaces, WDJs and WEJs and the related support facilities are included
  103. in package {@link psl.workflakes.coolets} and its subpackages.
  104. <p>Notice that in case of the choice regarding actuators for Workflakes
  105. is different from Worklets, the plugin-based architecture of Workflakes
  106. cluster (see&nbsp; <a href="#Architecture">below</a>) allows to substitute
  107. Workflakes (and specifically WEJs) with another actuator technology at
  108. little cost.
  109. <p>To learn to use Workflakes, it is strongly advised in the first place
  110. to familiarize&nbsp; with Cougaar, and its main concepts, which include
  111. <i>nodes </i>(Cougaar units of distribution ), clusters, plugins, <i>assets</i>
  112. (for representing facts and resources), dynamic planning, PSP (for reporting
  113. and communicating to the outside the state of the workflow) and so on.
  114. <br>An example of a small Workflakes society carrying out a simple workflow
  115. is found in the package for {@link psl.workflakes.exercise.tutorial}, which
  116. can be run as 2 communicating clusters, either running on the same Java
  117. Virtual Machine (a Cougaar Node) or on 2 different JVMs.
  118. <h2>
  119. <a NAME="Architecture"></a>Insight&nbsp; on Workflakes architecture</h2>
  120. A typical Workflakes cluster appears as follows:
  121. <center><img SRC="Cluster.png" VSPACE=5 BORDER=2 height=313 width=460 align=ABSBOTTOM></center>
  122.  
  123. <p><b>LDM plugins</b> represent sources of facts and data exchanges with
  124. the external world; among those, one represents the repository of WEJs
  125. that are available to the cluster for dispatching as a response to given
  126. workflow tasks. External world data may for example represent triggers
  127. for a reactive workflow, once they are internalized into the blackboard
  128. by the appropriate LDM plugin.
  129. <br>In the Workflakes distribution, an example of an LDM shell plugin is
  130. provided, which allows to interface a cluster to the <a href="http://serl.cs.colorado.edu/~siena">Siena</a>
  131. event bus in a flexible fashion, which is programmable with appropriate
  132. WDJs.
  133. <p>Notice how a WVM is embedded in the cluster to allow docking of WDJs
  134. (see <a href="#WDJfig">Figure on the left below</a>) and dispatching of
  135. WEJs (handled in conjunction by <b>AllocatorPlugIn</b> and <b>ExecutorPlugIn
  136. </b>on
  137. the basis of the junction repository maintained by an LDM plugin- see <a href="#WEJfig">Figure
  138. on the right below</a> ). For substituting WEJs with some other actuation
  139. technology in Workflakes, it is sufficient to define new Allocator and
  140. Executor plugins with appropriate capbilities and ad hoc logic.
  141. <p><a NAME="WDJfig"></a><img SRC="WDJs.gif" VSPACE=5 BORDER=2 height=310 width=463 align=LEFT><a NAME="WEJfig"></a><img SRC="WEJs.gif" VSPACE=5 BORDER=2 height=311 width=466 align=ABSBOTTOM>
  142. <p>Incoming WDJs can define many facets of the workflow, such as:
  143. <ul>
  144. <li>
  145. Tasks to be posted on the blackboard</li>
  146.  
  147. <li>
  148. Logic to extend posted tasks into <i>Expansions</i>, i.e. concatenations
  149. of further (sub-)tasks (see {@link psl.workflakes.coolets.ExpanderJunction}
  150. for the base class of WEJs defining expansion logic and {@link psl.workflakes.coolets.adaptors.ExpanderAdaptorInf}&nbsp;
  151. for the base interface to be implemented by Expander plugins).</li>
  152.  
  153. <li>
  154. Information about the WEJs in the junction repository that can be associated
  155. to workflow tasks for actuation (see {@link psl.workflakes.coolets.JunctionLDMPlugIn}
  156. for the base class of LDM plugins handling WEJs )</li>
  157.  
  158. <li>
  159. Information on how to process incoming triggers with LDM plugins (see for
  160. example {@link psl.workflakes.coolets.SienaLDMPlugIn} for the base class
  161. of LDM plugins handling triggers coming from an external source such as
  162. the Siena bus and {@link psl.workflakes.coolets.SienaLDMJunction} for the
  163. base class of WDJs providing processing logic for incoming Siena triggers)</li>
  164.  
  165. <li>
  166. Policies that govern the assignment of WEJs to worklets and their dispatching
  167. on board of worklets</li>
  168.  
  169. <li>
  170. etc.</li>
  171. </ul>
  172.  
  173. <h2>
  174. Interactions between shell plugins and WDJs</h2>
  175. It is noticeable the pattern with which a WDJ interacts with a shell plugin
  176. to "fill" it with some workflow logic. First of all, the code of each WDJ
  177. must be developed against a certain <i>adaptor interface</i> and an incoming
  178. WDJ expects the shell plugin to expose the appropriate adaptor.
  179. <br>The code injected into a plugin by a WDJ has three main parts:
  180. <center><img SRC="JunctionIn.gif" BORDER=0 height=205 width=319></center>
  181.  
  182. <ul>
  183. <li>
  184. Initialization: any set of computations that needs to be carried out immediately
  185. when the junction arrives</li>
  186.  
  187. <li>
  188. Subscriptions: the junction can operate subscriptions onto the Cougaar
  189. blackboard on the behalf of the plugin</li>
  190.  
  191. <li>
  192. Callbacks: the junctions define behaviors to be executed as soon as the
  193. blackboard subscriptions are matched and the control is given to the plugin
  194. in order to manipulate the matching elements of the blackboard.</li>
  195. </ul>
  196. Multiple WDJs can therefore be active at the same time within a plugin,
  197. each with its own set of subscriptions and callbacks.
  198. <br>Basic types adaptor interfaces for the most common types of shell plugins
  199. are found in the {@link psl.workflakes.coolets.adaptors} package.
  200. <br>&nbsp;
  201. </body>
  202. </html>