Controller / EJB

Using action classes as adapters and session EJBs for business logic sounds like a good way to go. Is also using EJBs as actionforms is a good idea because they are a good target for object reuse

Actually, I do not believe it is a good idea to re-use an EJB as an ActionForm. In fact, this will be somewhat more difficult in 1.0, now that ActionForm is a class rather than an interface.

The reasoning behind my belief goes like this:

• An ActionForm is part of the view layer of MVC, not the model layer like an EJB (or a regular JavaBean that represents persistent data).
• The sole purpose of an ActionForm is to maintain the state of all the input variables on a particular form, so that you can reproduce the form pre-filled-in if the user made an error that they need to fix. This matches the expectations of users who are used to GUI-based client server apps, that never make you retype any input except the stuff you did wrong.
• Because of the above, the "domain" of an ActionForm does not necessarily match any existing EJBs or model layer JavaBeans. It is not uncommon to have inputs from a single form that will ultimately cause updates to more than one undelrying EJB or model bean.
• Using a separate class for the ActionForm means you can change the underlying organization of your model beans or EJBs without impacting the view layer (although there might be modest impacts on the Action classes that copy things back and forth).
• In addition, most EJBs and model beans have validation rules internally that prevent them from accepting semantically invalid data. Such rules would prevent you from accomplishing the primary purpose of an ActionForm -- storing all of the user's input fields, so that you can reproduce the input screen.
• Also, if your form is multiple pages and you were using the real EJB, let's say you start updating properties based on receiving the first page. Now, you've potentially started locking resources in the underlying database -- and you have to deal with the fact that the user may never come back and finish this transaction.

So, my bottom line recommendation is that you plan on building simple JavaBeans for your ActionForms. Most of the time, an ActionForm will have just getters and setters, with no error checking (other than a validate() method if you want to use it, plus the reset() method). PropertyUtils also has a convenience function that can copy properties with like names from your EJB to the ActionForm bean (or vice versa), to reduce the amount of tedious code that this
approach implies. And, at some future point, it's reasonable to expect a development tool to be able to auto-generate ActionForm beans for you. 

Using an EJB as a bean that provides data values used in the presentation, on the other hand, is pretty easy. Just store the client-side instance you get back from the EJB server as a request attribute or session attribute -- from the
perspective of the Struts custom tags, this EJB just looks like a JavaBean with getter methods, so they don't care that it is really an EJB. NOTE: If the EJBs are really on a remote server this could have some performance impact -- you
might be better served to copy data into local beans in that case.