Hello folks, here i facing a problem, is a good approach break a big J2EE application into many small J2EE applications? I could put all EJBs into an ejbModule and all other webModules would share it, may am i right to do that?
The problem with that is you will have lots of overhead from EJBs because EJBs are considered heavy weight.
I guess you would want to have modularized system so it's easier to maintain and more efficient in terms of sharing resources. I suggest you look at ESB making use of SOA architecture. Within internal, you can turn all these J2EE apps into Services, using ESB to expose them to others. ESB is capable to integrate with different technologies like JMS, SOAP and JCA so you can relax on integration part. With this you will also have your architecture SOA ready to scale large with affordable overhead..........IF you are creating a heavy duty enterprise system.
I'm actually looking for advice on the same topic. So we have a large enterprise e-commerce application. Thousands of classes and JSPs, hundreds of use cases. Today we build it as a large ear and deploy it to a JEE app server farm.
It's a challenge to do a clean release every time as our QA team, whether running manual or automated tests, has a lot of breadth and depth to cover. To be able to move faster and have more reliable releases, we're considering different strategies: longer release cycles, breaking the application up into smaller pieces, etc.
So I'm considering breaking this up into several wars within an ear (based on functional divisions in the system, so functional area A would have all its flows in war, etc.). We could push just the wars that are updated in a release, limiting the scope of change.
Here's some of the challenges: Design could be negatively impacted by such a strategy (well, the right way to do this is to make a change in the common or shared code, but that means a big regression test which my manager/business lead doesn't want, so I'll just put it in this war, copy the code, etc.). Also, we have some common code: a single sign on and an account representation stored in session used throughout the site for personalization. So if you have to change the common code, you just put it in the ear and require a full build/regression test?
How have others managed a web application or similar system that has many functional flows and shared functionality/code, but has grown too cumbersome for a single ear? Is more automated testing the solution?