Don, 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. :-) -Andrew
-----Original Message----- From: Don Elliott [mailto:[EMAIL PROTECTED]] Sent: Friday, June 21, 2002 10:56 To: [EMAIL PROTECTED] 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" type="com.hof.web.action.JSCVWorkHistoryOrgAction" name="JSCVForm" input="/js_cv_orghist.jsp" scope="session"> <forward name="success" path="/js_cv_orghist.jsp"/> <forward name="back" path="/JSCVAchievements.do"/> <forward name="next" path="/JSCVWorkHistoryPosition.do"/> </action> 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 mapping.findForward("success"). 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... session.removeAttribute(mapping.getName()); return (mapping.findForward(action)); } All topNav* actions are set up as global forwards: <forward name="topNavHome" path="/HomePage.do" redirect="true"/> 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 forum.. Regards, Don -----Original Message----- From: Brian Hardy [mailto:[EMAIL PROTECTED]] Sent: Friday, 21 June 2002 4:15 AM To: [EMAIL PROTECTED] 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 workflow? Thanks again --Brian Hardy What --- Don Elliott <[EMAIL PROTECTED]> 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 > www.i4-talent.com > > PS: I've copied this to the struts user forum to > see if it generates any > interesting debate... > -----Original Message----- > From: Brian Hardy [mailto:[EMAIL PROTECTED]] > Sent: Thursday, 20 June 2002 9:28 AM > To: [EMAIL PROTECTED] > 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 <[EMAIL PROTECTED]> 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 > > www.i4-talent.com > > -----Original Message----- > > From: Brian Hardy [mailto:[EMAIL PROTECTED]] > > Sent: Thursday, 20 June 2002 8:01 AM > > To: [EMAIL PROTECTED] > > 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 http://fifaworldcup.yahoo.com -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]> -- To unsubscribe, e-mail: <mailto:[EMAIL PROTECTED]> For additional commands, e-mail: <mailto:[EMAIL PROTECTED]>
