For the sake of our
discussion on Struts & Workflow, below is most of an internal
company proposal from me to a co-worker concerning a simple Workflow demo.
This proposal is drawn, in part, from recent ideas posted to this list.
What may be different in what I am suggesting is that Workflow really means the
"composition" of existing applications. That is, an application that wraps
up some number of existing apps. The "View" might be a Todo list in
one window in a frameset spawning links to display in the "main"
window of the frameset.. Struts inside of Struts.
Dan Connelly
Keeping [our] Workflow extremely simple at this point, it seems
to me that our next step is to show that we can interpose a
"pre-condition" between two separate, pre-exisiting applications. Also,
that we can wrap the two applications in pre- and post- actions.We have two interesting applications from Apache running on our Tomcat
server: "Mail Accounts" (aka "example") and "File Upload" (aka
"upload). The default setup for these two applications is to run them
in two separate Web Contexts within the server. Currently, there is no
interaction between these two applications. They are just separate
demonstrations of "Struts," the MVC framework (Release 1.0) from Apache.I propose that we will now develop a Workflow Context (WFContext) to
require that a user wanting to run "File Upload" must first "login"
through the "Mail Accounts" applications and that there must be listed
a "notification account" among that user's email accounts. This is the
Workflow pre-condition to be demonstrated.Once this pre-condition is satisfied, then the user may proceed to use
"File Upload" to transfer data. For each file transferred, an email
notification of the upload completion status will be sent to the
designated account. This is the Workflow post-action to be
demonstrated. (There will also be pre-actions, but they will be
hidden.)The aim here is to subsume two existing applications into a new "Upload
with Mail Workflow" application which will control these apps out of its
own Web Context.(The Web Context is a server concept, while the WFContext is part of the
Workflow logic framework, unknown to Web server. In a previous email I
described a WFContext as an application specific data structure --
principally a hashtable -- that gradually instantiates unknown data in a
controlled manner.)Our goal is to utilize the logic of the existing applications without
modification to their Java code or to any existing database. It will
be permitted, however, to modify the code of the Struts framework and to
modify the "struts-config.xml" for both of the affected application.
Despite these changes and despite the new Workflow logic (application),
the two applications should continue to run with unchanged
functionality.It is assumed that Tomcat's security settings would prevent the direct
use of the two applications once the Workflow became a requirement.
Privileged "LDAP" accounts would continue to have direct access to the
two separate applications.
