struts-user mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Andrew Hill" <>
Subject RE: Architecting an application's workflow with Struts
Date Fri, 21 Jun 2002 10:01:27 GMT
Thanks for posting this to the forum.
Theres a lot of useful information in there that relates directly to some of
the stuff I am / will be doing, so I think Ill be printing this one out and
going through it to see what methodologies I can make use of.

-----Original Message-----
From: Don Elliott []
Sent: Friday, June 21, 2002 10:56
Cc: Struts-User@Jakarta. Apache. Org
Subject: Architecting an application's workflow with Struts

Hi Brian,

Happy to answer questions - I'm actually doing an Architectural Presentation
on Struts to the Melbourne WebSphere user group next month, so it gives me a
chance to put something on paper in preparation and get some feedback..

In summary, we use a combination of techniques for which Struts is the
foundation.  To understand how we do forwarding, etc you need to understand
a bit about our architecture / presentation paradigm.  Our application is
JSP / Servlet with no EJB, but architected/layered much the same way you
would layer an EJB app.  The reason for this is mainly cost/performance -
EJB is a very expensive architecture (in terms of $$, processor requirement
and cost to develop / manage) and provides little to no real benefit over a
servlet architecture (my opinion - I've yet to see something in it that
would persuade me to move given our only delivery channel is via a browser).

Our page/form design paradigm is to have a form for all tightly related data
in our system that is kept in Servlet session memory.  Our product is an
eRecruitment platform - the main components/areas are things like Resume,
JobAd, Applications, Preferences, TimeSheets, etc.  For each of these there
is generally 1 central page/table, and several 'lists' of related tables
(1:M relationships).  Each list is managed by a seperate web page / Struts
Action, but all related details are managed through a central Business
Process.  We use the struts form to pass the data down from the presentation
layer into the Business Process layer (ie. the EJB valueObject design
pattern).  Data in the lists is lazy loaded (ie. on first entry to the
editing screens) but then kept in servlet session memory.  Data is also lazy
saved - ie. actions on the same page are all batched (add to list, edit,
update, delete) then persisted to the database when you move off the screen.
This greatly reduces the load on the database (which is the most expensive
part of the technology stack) - as we grow, it's very easy/cheap to add more
application servers (either running independantly or load balanced), but a
lot more expensive to up-size our database.

Data in the lists are model beans (ie. a one-to-one column mapping of
tables).  We use these model beans on the form and reference them directly
from the JSP using struts tag nested references - eg:

<td> First Name: </td>
<td> <html:text property="person.firstName"/> </td>

This basically does a  getPerson().getFirstName() /
getPerson().setFirstName() to reference the first name field in the Person
model bean attached to our form.

This means the code in our Struts actions has to do very little as Struts
basically populates the data directly into the objects that are persisted to
the database - all we do is grab things from lists and pop them on the form,
and vise-versa.

The pages of related areas (eg. resume) are linked through a left hand
navigation bar - unrelated areas are linked through the top navigation bar.
All our links are pushed though a submit action - this allows us to
'remember' data when moving between related actions, and clean up memory
when moving between unrelated actions - ie. if you click on the left nav,
the current form data is kept so if you link back it is still there.  If you
click on a top nav, we persist all data to the database and kill the struts
Form from memory.  This is very important for scalability of our app as we
have over 150 tables and you never want to get to a stage where a single
user has loaded the session memory with data that is completely unrelated to
what they may be doing at the time.

Now, back to the original question about handling forward - each page
management action looks as follows in struts-config.xml:

   <action     path="/JSCVWorkHistoryOrg"
      <forward name="success"                 path="/js_cv_orghist.jsp"/>
      <forward name="back"                    path="/"/>
      <forward name="next"

Our Struts Actions in our application do 3 things - manage data on a page,
link to related data, and link to unrelated data.  Most of the processing is
handled through a hidden field on the form called 'action' that we populate
with the requested action.

On editing data, we always do a forward to the jsp page that is managing the
data (ie. you select something from a list, the action gets it, puts it on
the form and then forwards to the page by returning

We generally have back/next buttons on these pages - this allows us to
configure which pages are required by different customers (eg. some
customers may want to capture lots of details, others only a few).  To
support this, we deploy the same software but just change the back/next
mappings in this file to drop out the unwanted pages.  Notice that these
forward to the manager actions to potentially pre-load the required data
into session if it hasn't already been loaded.

Lastly, if someone clicks on a top Navigation bar, we know they are leaving
the subject area, so we clean up memory - this is  done as follows (our
assumption is that all top navigation forwards are called 'topNav*':

    if (action.startsWith("topNav"))
        ... do any persistance processing required...

	return (mapping.findForward(action));

All topNav* actions are set up as global forwards:

      <forward name="topNavHome"              path="/"

Note the use of redirect="true" - when submitting a form, standard forwards
will pass along all submitted data, URL parameters, etc which may confuse
the new action, and if your original page is a multi-part form (ie. you have
a file upload tag on it) it will cause an ugly java crash if the new action
isn't expecting a multi-part form - redirect="true" looses the request parms
hence on entry to the new action everything will be blank.

Other questions:

Q) Couldn't you have made a Struts action that all actions get forwarded to.
Then that main action could return approiate forwarding codes to "real"
actions.  In that case though, you would need one mother form, that
encompased all the actions you anticipated going through - I think.

A) Yes, you could do the above but for a large app you would find managing
the session memory very difficult, and also you would loose the ability for
different programmers to work independantly - the struts-config.xml file and
what I've explained above makes it very easy for people to work
independantly and then integrate later.  Also, this strategy would loose the
ability we have to quickly configure modules together based upon customer
requirement - while we could modularise through proprietary tables, I'm
trying to utilise as much struts controller functionality as I can because
it means I don't have to re-invent (and re-test) the wheel.

Q) Since you have a workflow now, do you use the Struts config file to map
actions to jsp's, or is all that mapping now in your workflow? How do you
get the form data to each action in your workflow?

A)  Workflow is much bandied-about term that can mean many things on many
levels.  Struts workflow (as I understand the proposals) is purely about
allowing the configuration of a set of modules (actions / pages) into
different logical orders for different uses with some simple decision making
(eg. tree logic, looping, etc).  This will allow easy configuration of
existing components into different orders for different applications without
coding.  It will not address 'business' level workflow requirements such as
assignment of tasks based upon actions (eg. approvals, scheduling, queueing
of tasks in peoples inboxes, etc) nor should it, as this is no longer a
technical infrastructure issue but a business process and decision making
issue.  As I see it, the business workflow/logic decides what to do at a
high level - the struts workflow modules then guide the user through all the
steps required to complete the individual tasks.

Our workflow addresses the business level requirements and is simply a set
of 2 tables - one records the process steps and requirements (for things
such as Job Applications, etc), and the other records where an individual
application is in that process.  This allows us to persist where someone is
and make decisions about who needs to perform the next action - this is very
complimentary to what struts does in managing the configuration of how web
pages/actions fit together (which is what we use the struts-config.xml for).
When someone goes to perform the scheduled action (eg. fill out a CV or do a
timesheet), the struts config provides the linking between the pages
required to do this..

I hope this isn't too long-winded, and we get some other feedback from the

-----Original Message-----
From: Brian Hardy []
Sent: Friday, 21 June 2002 4:15 AM
Subject: Re: Struts workflow - status and general Struts comments

Thanks again Don.

You have great information.

I want to ask you some more regarding Struts and
workflow, but I've already bugged you quite a bit and
you've really given me some great information to think
about, so please feel free to ignore this.

When you forward from an action in Struts, do you
always map to a jsp page that then has an associated
action?  Or can you map from one action to another
action that has no view associated with it.

Aside from the multi-session, multi-person interation,
Couldn't you have made a Struts action that all
actions get forwarded to.  Then that main action could
return approiate forwarding codes to "real" actions.

In that case though, you would need one mother form,
that encompased all the actions you anticipated going
through - I think.

Since you have a workflow now, do you use the Struts
config file to map actions to jsp's, or is all that
mapping now in your workflow?

How do you get the form data to each action in your

Thanks again

--Brian Hardy

--- Don Elliott <> wrote:
> Hi Brian,
> Our application is very much a struts application -
> despite not being able
> to do what we need from workflow, it is still very
> useful for delivering the
> View and Controller components of MVC - we use the
> taglibs extensively, and
> have all our modules called via the Struts
> Controller.
> The way we manage workflow is through a single
> workflow module that we call
> from our actions to both update the status of the
> workflow in the database
> based upon what action has just been taken and then
> determine what needs to
> happen next - what needs to happen next is generally
> a combination of
> kicking off/scheduling new workflows in the database
> and returning a next
> appropriate action to the calling action - this is
> then passed back to
> Struts and the next page/module for display is
> handled through struts global
> forwards.
> I'm probably being a bit harsh on Struts saying it
> doesn't do multi-session
> / multi-person workflow as Struts is very much an
> execution architecture,
> not an application system - to do
> multi-session/person you have to persist
> the current step and participants to the database at
> some stage, which is
> well outside the scope of struts.  Struts could be
> improved to do a bit more
> in being able to group sets of actions into
> different higher-level
> workflows, which would take a lot of logic out of
> our workflow process - my
> understanding is that they are looking to do this,
> but haven't had the
> resources as yet.
> We have steered away from modifying the struts
> framework as (from
> experience) coding exits to something you don't
> control generally means a
> lot of rework down the track.  The only change we
> have made to struts is to
> implement an SSL redirection mechanism (which is on
> the contributions page).
> I have seen on that page that someone has
> contributed an extensions
> mechanism which wouldn't require re-coding when new
> releases of struts come
> out - this looks very promising and I'm looking at
> it to see if we could
> push a lot of repeated code into it (eg. all our
> security and authorisation
> checking, standardised module entry/exit logging for
> audit trail, etc).  The
> only other thing I think struts is lacking is the
> ability to have the struts
> configuration in a database rather than an XML file
> - this would be great,
> but I don't think it's on the agenda...
> Regards,
> Don Elliott
> PS:  I've copied this to the struts user forum to
> see if it generates any
> interesting debate...
> -----Original Message-----
> From: Brian Hardy []
> Sent: Thursday, 20 June 2002 9:28 AM
> To:
> Subject: RE: Apache workflow
> Hello Don.
> Thank you for that very insightful information.
> Very much appreciated.
> I know you created your own solution.
> Did you build your solution as modification to the
> Apache Struts framework, or was your solution
> completely separate from the Struts framework?
> If your solution was separate, did it interact with
> Struts?
> Thanks Again.
> --Brian
> --- Don Elliott <> wrote:
> > Hi Brian,
> >
> > I had a lot of input in the early stages to
> workflow
> > with struts, but it
> > appears that not much has happened.
> >
> > The current version of struts is really a subset
> of what is needed - it
> > provides the ability to configure through the
> struts-config.xml file a
> > number branches (action forwards) based upon the
> return code of an Action.
> > It also allows you to define a  global set of
> forwards that apply if the
> > return code from the action doesn't have a local
> forward.
> >
> > From my perspective, this didn't help a lot in
> real workflow - ie. being
> > able to re-use the same components in the same
> system for a number of
> > different processes.  Also, it only addressed
> 'real time' workflow, and
> > didn't have any concept of workflows involving the
> interaction of multiple
> > people over time (eg. data entered by person 1 -
> routed to person 2 for
> > action, etc).  We also had a requirement to
> deliver our system as an ASP
> > product, hence the workflows could be different
> for each company logging
> on.
> >
> > To get around this we coded our own solution that
> used a set of relational
> > tables to drive the decision making.  I did look
> at a number of commercial
> > products, but most tied you to the platform and
> were fairly expensive.  As
> > an ISV we wanted our solution to work on a number
> of databases and app
> > servers.  When I was looking around I did have a
> look at Weblogics
> > solution - if you are using Weblogic then this
> appears to fit most needs
> in
> > terms of online workfow, but from memory didn't
> address multi-person,
> > multi-session workflows.
> >
> > Sorry I couldn't be of more assistance.
> >
> > Regards,
> > Don Elliott
> >
> > -----Original Message-----
> > From: Brian Hardy []
> > Sent: Thursday, 20 June 2002 8:01 AM
> > To:
> > Subject: Apache workflow
> >
> >
> > Hello Don.
> >
> > I'm looking at using workflows on a current
> project.
> > I've worked with Apache Struts quite a bit in the
> > past, but haven't used workflows; we had some
> > actions
> > that had several states though. I saw that you
> were
> > heading up development with the workflow for
> Struts.
> > Is workflow ready to be used?  What state is in?
> Is
> > it
> > available yet?  If so can you direct me where to
> > find
> > it.  At this time do you recommend using another
> > workflow product over Struts, like WebFlow from
> > weblogic?
> >
> > Thank you very much.
> >
> > --Brian Hardy
> >

Do You Yahoo!?
Yahoo! - Official partner of 2002 FIFA World Cup

To unsubscribe, e-mail:
For additional commands, e-mail:

To unsubscribe, e-mail:   <>
For additional commands, e-mail: <>

View raw message