Workflow: Struts inside of Struts

[Dan Connelly <ds...@adelphia.net>]

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.

Re: Workflow: Struts inside of Struts

[Dan Connelly <ds...@adelphia.net>]

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 ----- 
  From: Dan Connelly 
  To: struts-dev@jakarta.apache.org 
  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.