Design patterns related to managing the controller

Hello--I'm just working through my first Struts app and have a question which may have more to do with my architectural decisions than anything else.
I've decided to make a single Action class responsible for handling requests and directing traffic for several different related actions. For example, if I were managing a bank account, I have 'Add Account', 'Delete Account', 'Update Account' all going into the same 'ManageAccountAction' class. Easy enough, but for purposes of reusability, I want forward the processing of 'Add', 'Delete', 'Update' out of the Action class and into another 'Manager' class, preferably another servlet.
So here's my question. If I try to use the RequestDispatcher to forward the request onwards, I can only forward the HttpServletRequest and HttpServletResponse, not the ActionForm. While this really isn't a big deal because I could probably stick the ActionForm in the Session object or something, I'm really left wondering if I'm even using the right design approach to this.
Can anyone point me to a design pattern or best practice that might help me figure out how best to coordinate and manage the controller layer.
Thanks.
Michael
[ July 02, 2003: Message edited by: Michael Schmidt ]

I think you will want to look into the Business Delegate pattern. I don't think you necessarily want to forward to another servlet from you action class, you just want to delegate to another class that will handle the business logic. Do you really need to pass the HttpResponse to this business logic class? Probably not. Let the struts action mappings handle that, you just need to worry about where to put your business logic.

Chad... thanks for bringing this out into discussion. How would you compare the IBM Websphere Command Pattern with the business delegate pattern? Is there any place I can find out the pros/cons of these two.. or compare them? Would you(or any Java Ranchers!) be able to provide more insight.
Thanks.

In the Command Pattern--and last I heard, IBM Websphere did not have ownership of it

--a request is encapsulated so that the sender and receiver can be decoupled. It also allows you to implement an "undo/redo" feature.
The Business Delegate allows you to keep "business" logic in layer separate from other layers such as presentation or flow control.
So besides the fact that they both allow you to reduce coupling and have a better assignment of responsibilities, there is really no other way to compare the two. Like comparing apples to oranges, as they say.