|
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.
|
