How to create 'service' tier with functionality multiple struts apps

Question

I am looking for some advice regarding a future project. I have 3 struts webapps (running on Tomcat 4.1.3) each with some overlapping functionality. I would like to create a 'service tier' to accommodate common functionality which can be shared between the 3 struts web apps.
What framework would best achieve this? Are EJBs the way to go? My struts apps all use DTOs so are not tied to the Action Form object. I have been looking at Spring but am not sure exactly how this will fit? Will tomcat serve my needs or do I need to migrate to something with full J2EE support. I have also considered JBOSS with Seam linking JSF to EJBs. Is this a viable option?
The service layer can be on the same machine as the struts apps although I would like to have the flexibility to move it to a separate server in the future if necessary.
I will be happy to provide more details to any who can offer me some guidance.

Answer 1

Hi Saish,
Thanks for your help.
I have considered both options. The main goal is to
eliminate duplicate code. However the presentation
tiers of the applications are quite different. I
will look into Martins book.
It's outstanding. One of my top five favorite books.
Would creating a jar file which is included in each
.war end up becomming a maintenance nightmare?
Depends on what you mean by ' maintenance'. In terms of onging development with your Java source, in a modern IDE, no. In terms of deployment, it does add a minor bit of complexity. However, if you are using an automated build and deployment tool such as Ant or Maven, the amount of extra work is trivial.
In your opinion what would be the advantages of
implementing the common functionality as a seperate
tier (with SPRING/EJB) vs using a JAR file and
distributing it with each app?They are not mutually exclusive. If you want to remove duplicate code, then simple refactoring is the start. As part of that refactoring, you may decide enough classes are providing similar functionality (such as transaction management, a coarse-grained public API, etc.) and create a tier. You mentioned in particular a service tier. This is a design and architectural decision. You could still completely refactor common functionality into a better design without the introduction of a new tier.
Whether to create a tier is, IMO, more art than science. Adding a tier adds complexity. However, the net effect should be to reduce system complexity. It is more 'work' to implement a true persistence tier than to simply code JDBC in model objects (or use Hibernate/JDO objects). However, as overall system complexity grows, the addition of a persistence tier adds many benefits. Business objects concern themselves solely with business logic, where as data acccess objects concern themselves with persistence. You can even have different developers with different skills specialize within a tier.
So, tiering really is a big topic. Fortunately, there are many architecture templates and design patterns to guide your decisions. "Patterns of Enterprise Architecture" (also by Fowler) compares and contrasts the more common ones. There is lively debate as to the pros and cons of different strategies. In the end, there is no cookie-cutter architecture. You will need (sometimes through the painful process of making a mistake) to see what works best for your actual system.
Finally, about remoting. Remember the first law of distributed objects, "Don't distribute your objects". There is always a performance penalty compared to an in-JVM local call. Remoting has its uses, but these should be careful architecture-level decisions. (I should concded that even this paragraph is sometimes contentious and debated).
- Saish