struts-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul_T_Sm...@Dell.com
Subject RE: Workflow for Struts
Date Sun, 03 Aug 2003 18:02:47 GMT
Actually I completely agree that business controllers and workflows belong
outside of Struts. I think the problem though lies in the word workflow.
Pageflow is not intended to actually do business work, but to extend the
functionality of the web specific portion of the problem. As a matter of
fact I have actions built to connect pageflow and Struts to WebMethods,
Commons-Workflow, and BEA Weblogic Integration - all completely web agnostic
business controllers. The other thing is not all applications need a full
workflow tool behind struts. Architectural flexibility is what I think we
need. In very complex scenarios a programmer may want to use pageflow and a
workflow engine. In simple scenarios they may want to use just pageflow or
just the workflow. The thing is, pageflow at it's simplist provides
equivalent functionality to the current struts.
Struts needs some elements of these types of functionality to become even
more flexible and provide more ease of use for developers. The thing in
there is significant amount of opportunity for re-use inside the web-tier
alone. For example, navigation/variable handling/errors etc. can present a
significant code challenge in large applications. That's why I created
pageflow, to make struts easier to use for large apps. Recently, I worked on
a large web app with Struts 1.1 using dynamic forms and validator and all of
our business logic was in session beans. This put Struts right in it's sweet
spot and it did very well, the dev team was very pleased. However, we still
had quite a bit of code (14,000 lines) in action classes. 
Here were some of the challenges that pageflow is designed to help with:
- reusable actions - a good deal of the code we wrote was the same. Take a
data object from the business tier, format it for display, take the user
input and pass it to the business tier. The problem was actions aren't
really reusable, you have to factor out common code into utility classes
which doesn't always map well. This is one place were workflow-like (Id
really rather call it pageflow because of the objections you raised) saves
the day.
- contextual pages - if a button (like a save button) was supposed to do
something different in one context over another, we had to do some pretty
convoluted logic in both the actions and the jsp. With pageflow you just use
a separate page-instance and connect it to a separate action. This saves
immense problem around complicated page-action-page combinations.
- variable handling - quite frankly it was difficult to track where form
properties were assigned and how they related to scoped variables. Also, I
had some junior programmers spend significant hours finding bugs in session
memory handling. Pageflow provides a scopes and memory handling that makes
it much easier to track down what is going where.
- flexible events and filters - although not necessary, in our app we wanted
to do some simple filters for a couple of page/action combos, turns out this
is really hard. Also, we had a couple of instances were an event framework
would have simplified our code immensely.

-----Original Message-----
From: Ted Husted [mailto:husted@apache.org] 
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

   ActionForward 
execute(ActionMapping,ActionForm,SerlvetRequest,ServletResponse),

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.

-Ted.



---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org



---------------------------------------------------------------------
To unsubscribe, e-mail: struts-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: struts-dev-help@jakarta.apache.org


Mime
View raw message