Craig McC. wrote, concerning attempts to concoct a new scope for workflow across multiple applications:
For the first, the servlet spec is not going to help you much.  It has
very little to say about cross-application support.  ......   The standard
advice is to use databases or EJBs for data that needs to be available
across web applications.
Not quite.  It seems to me that there is at least one other interesting avenue by which a cross-application context may be created:  HTML scraping.    That is, the Struts Controller (given some chained-in Action parsers) can hook hard data from the data stream of a URL connection.   The data comes from a second application.  There are no shared databases or EJBs between the two applications.  Just some AI-ish good sense in the Action servlet. 
 
Ok, "scraping" idea is crude and ad hoc.  But soon we will have the exact technologies, SOAP and Web Services, in widespread use.  SOAP will pump hard data, client-server style, over URL connections.  Someday, http will be just the obligatory eye candy for the XML-challenged client agent.  Yes, the web will have EJBs and SQLs for applications that are explicitly created to share within some narrow realm.  However, URLs will rule (as they do now) as the lingua franca.
 
At any rate, that is the way my workflow project is running.  (See old post, below.)   The applicaions I want to have running with the workflow do not use a shared database or EJBs.   My rules say that I can't change the applications.
 
In Struts Inside of Struts the browser doesn't invoke the inner app, it gets the Struts Action Controller to do the invocation, using a URL connection.   Struts Inside of Struts??   Well, the inner app doesn't really need to be Struts.  It just needs to be reasonable HTML text.
 
Maybe I should just call this approaoch Scraping Inside of Struts.  Eventually it could be Soap Inside of Struts.
 
My WFContext, mentioned below, was a bad idea.    The session scope of the outer app works just fine.  Or, Ted's Hashtable, if you prefer.
 
----- Original Message -----
Sent: Tuesday, June 19, 2001 2:52 AM
Subject: Workflow: Struts inside of Struts

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.
 
 
 
 
 

Reply via email to