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 redesigni

Answer 1

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).

Answer 2

Based on your project requirements like independent modules development and update in runtime, Maven is the best solution. It provides great support of dependencies and plugins and looks like everything you need for your project is already available:

• Spring/Struts/CXF/etc. maven artifacts,
• WAR/JAR/etc. plugins,
• Application servers deploy/testing plugins etc.
• And you can provide only common maven artifacts for teams that develop only specific modules without sharing of all codebase.
• Maven is supported by all Continuous Integration Servers (Hudson/TeamCity etc.)

OSGi. If you like to use it you have to look carefully on your current design and try to adapt it to μServices. In general, you'll have modules with API, API consumers and API providers. It helps you more to split development between teams (e.g. one develops API consumer module, another - API provider module). If you need you can split API consumer/provider module to 2+ OSGi bundles (that are Maven modules).

Answer 3

Your structure does look good to me, which is the typical structure for most projects - one recommendation that I would give is to version your dependencies, so for eg, let your webproject.war depend on webmodule1-1.3 say, this way potentially different end projects may have different versions of dependent jars.

Using maven would definitely simplify managing these dependencies

If your requirements are to replace dependencies at runtime then yes, you will have to go for technologies like OSGI, however if it is not runtime modularization that you are looking for, I would recommend not to start with OSGi and to keep the stack simpler.

Answer 4

After dealing with OSGi a little and get some pain, we've developed osgi-less modularity for Spring https://github.com/griddynamics/banshun You are wellcome!

Answer 5

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.