struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
Subject RE: Workflow for Struts
Date Sun, 03 Aug 2003 18:06:59 GMT
Sorry I keep uploading the same message, having some problems with my
email:-) Anyway, I downloaded Tomcat 4.1.27 and deployed the war file and it
worked ok. Maybe you need to delete you work directory so that it loads the
new files. I had some trouble with that initially.

-----Original Message-----
From: Ted Husted [] 
Sent: Sunday, August 03, 2003 11:58 AM
To: Struts Developers List
Subject: Re: Workflow for Struts

The thing I keep coming back to is whether workflows are a Struts 
problem. I would agree that multipage form *wizards* that collect input 
are definitely a Struts problem. But, I can't but help wonder whether 
more advanced types of workflows would be better defined as part of a 
business application controller -- rather than a presentation front 
controller, like Struts. (Or, presentation service-to-worker controller, 
if you are a J2EE Blueprints follower.)

AFAIK, there really aren't any open-source business application 
controller frameworks "out there" now, and Struts often ends up filling 
this void. Before we talk about extending Struts so that it encroaches 
on business application space, perhaps we should consider whether 
"Struts is enough".

What I'm thinking is that below Struts there should be a pure business 
application controller framework. It would have all the same hallmarks 
as Struts, such as input helpers, locations, handlers, and message 
resources. But, these would all have pure signatures, free of web and 
servlet semantics. Essentially, Struts without HTTP.

While things like "wizards" would live in the Struts layer, things like 
"workflows" would live in this business layer.

Struts could work as an extension of the business framework. Struts 
gathers up the input parameters, and other user gestures, and passes 
them to the business framework. The business framework then passes back 
dispatch tokens (like "success"), messages, and value objects (or 
collections of value objects).

The business application controller decides whether to go to "success", 
"failure", or "outForBeer". Struts fills in the path to the web 
application resource representing each token. Likewise, the business 
application controller passed back keys to the message resources, and 
Struts renders the localized versions. And, of course, the business 
application controller passes back objects with dynamic data to display, 
and Struts sends them to the server pages that can render them.

This is exactly what many (or even most) of us are doing now, except 
that we are all rolling our own proprietary solutions. I've worked with 
some companies that have already designed full-blown business layer 
frameworks such as this, based on the Struts architecture.

It may be time to take the hint and develop an open source business 
application controller framework where we can "share the wealth" as we 
have done with struts. Essentially, the idea would be to take Struts and 
abstract-out the web and servlet semantics. Where Struts might use an 
Action with an


the business layer framework would use a Handler with a

   Location process(Dispatcher,Helper,Context)

Struts then becomes a HTTP/Servlet extension of the business application 
controller framework. Where many developers are now writing "Actions", 
they could write web-semantic-free "Handlers" instead. Action classes 
would still be available when you really need to use web semantics, but 
otherwise, development effort can be put into web-free Handler classes. 
When web-semantics are not required, a single "gateway" Action can 
provide an adapter between Struts and the business layer framework. This 
moves most of the hard-core development completely out of Action classes 
and into platform-independant "POJO" classes.

I think the overall Struts architecture works great for a lot of people 
(including me!). But when it comes to putting development effort into 
things like true "workflows", we want that effort to be on the business 
layer and outside of Struts.

The need for a true business application controller is burning issue for 
most teams, and perhaps it's time that we addressed it head-on. We've 
been drifting in this direction by moving many of our utilities to the 
Commons, and splitting packages like the Validator in to a Commons 
component and a dependent Struts components. Before we think about 
adding anything like workflow support to the Struts core, perhaps we 
should declare our feelings about whether there should be a business 
layer framework below Struts, and whether any of us are willing to work 
on such a thing.

Or, perhaps it is the case that the server-side of JavaServerFaces will 
be able to fill this role. In which case, the question becomes whether 
an approach to workflows will complement JSF or not.

Though, personally, I would be most interested in a business application 
controller framework that was platform-independant and could be 
implemented on Java or C#, or even PHP.


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

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

View raw message