Large Enterprise Java Application - Modularization

Question

I work for a country-wide company, so the software we develop is large scale.

Our core system is Web based including webservices. We are currently redesigning the entire project and is moment to start the project structure.

We have like 7 web modules including for the web project based on Struts2 and Spring 3.1. A Webservice core based on JAX-WS and Spring 3.1

My question is what are the best practices to design the project structure and modularization for a project like this:

We'll definitely use Maven and OSGi if needed. I'm thinking in something like

WebProject.war
   |---Web.xml
   |--- Libs
   |
   |--- Web Module1.jar
   |--- Web Module2.jar
   |--- Web Module3.jar
   |--- Web Module4.jar
   |--- Web Module5.jar
   |--- Web Module6.jar

 WebService.war
   |---Web.xml
   |--- Libs
   |
   |--- Service.jar
   |--- Service2.jar

 EJBProject.jar
   |
   |--- module.jar
   |--- module2.jar

This is what I personally have in mind, but we are looking for something better modularized so we can work and deploy WebModule1.jar without affecting the other modules and main project WebProject.war. Also with this we want the specialized teams to only have the code of their projects, so if a Team must work only with Service2.jar in their IDE they will only have the code for Service2.jar and a resource project with the others project already compiled.

Thanks

Answer 1

The key aspect of modularity is that your module knows as little as is humanly possible so that it can be reused in many different contexts. Bugs only occur when an assumption is violated, minimizing the assumptions is the biggest bug killer. OSGi provides tools like µservices that are very good in allowing assumptions to remain local.

Your layout looks very much like a web project, which imho is wrong since most code we have to develop ourselves should be independent of the technology used to present it. All this technology is likely to change in the near future since web applications are shifting rapidly to the browser, browsers are becoming fat clients again. I.e. the very modern REST interfaces already feel very old fashioned if you see what pure messaging is doing. All this volatility means that you want to make your modules as decoupled as possible.

So I would never couple any domain code to anything that is coupled to libraries that are coupled to web technology. These transitive dependencies are going to hurt you in the (near) future. Built small cohesive uncoupled modules and then use them as lego blocks to build your applications.

Answer 2

I'd highly recommend reading Kirk Knoernschild's "Java Application Architecture: Modularity Patterns with Examples Using OSGi". You could start by modularizing the app before migrating to OSGi (and I'd definitely invest in good test coverage if you don't already have it).

If you're using servlet spec 3.0 then look at using web-fragments.

In terms of the structure you've shown, I'd say don't nest anything (except web-fragments), the WARs can become WABs (web application bundle - basically a skinny WAR). Also leverage OSGi's μServices as much as possible - that's where the fun starts =)

Enterprise OSGi frameworks like Karaf and Virgo offer a lot of support while you're straddling the JEE-OSGi divide (Equinox and Felix alone are a little to barebones).