I am just wondering. How are you going to structure your application if application is going to be really huge. Are you still going to keep it in one big war? Imagine that you will have tones of both EJBs and Endpoints. This will be really painful to maintain and redeployment (in dev mode) of whole app would become the issue.

Is not EAR better solution in that case? (multiple EJB components and maybe more then one WAR with pure web related stuff)

Posted by Thomas on August 23, 2014 at 11:41 PM CEST #


a very good question. It is going to be answered during the next Airhacks Q & A live show:

thanks for the question :-),


Posted by Adam Bien on August 25, 2014 at 11:30 AM CEST #

Hi Adam, thanks for reply

Just one more thing to add to that subject. How entities are going to be grouped? (just entities) It seems that sooner or later there will be need to share entities between separate modules. Should in this case be packed together and share as dependencies between modules. Or, maybe there is a possibility to pack modules this way that entities are never needed to be share.

Posted by Thomas on August 25, 2014 at 07:49 PM CEST #

Interesting topic. Some argue to package by feature, others by layer, and some say a hybrid of the two. But, then how do you deploy the software? One or more EARs? One or more WARs? If you are using Maven, how do you structure your source code tree (which is independent of how you structure your package names). What if your system is big enough that you have multiple nodes and you need to worry clustering? I don't think there is a one-size-fits-all solution and good luck when senior engineers on your program have different opinions on how to tackle these issues. I think one could write a book on this subject and it would be quite a long book.

One project I support uses a single EAR which contains a single WAR plus multiple JAR files. Having all servlets in the single WAR is nice, as there is only a single web.xml (and related set of descriptors) to maintain. Deployment of the system is a simple -- just copy the EAR out to the JBoss deployment area and the system is redeployed. The simplicity here works well as the system will always be deployed on a single node at a customer site (no clustering/failover capabilities needed).

Another project I support creates a new WAR for each web service. This seems wasteful, as now there is a need to maintain multiple web.xml (and related descriptors), leading to duplication of common things like error pages. This particular project initially wanted nothing to do with EAR files, but now sees EARs as a way to simplify deployment and to help control the order in which WAR files are deployed within the EAR.

Years ago, the first system I worked wasn't a Java system, but had a good overall structure that I am still impressed with today. Essentially, related services were grouped together into service blocks and a set of service blocks constituted a deployment configuration. The system supported multiple configurations, so you could generate a deployment configuration for demonstration (it had everything), a deployment configuration for database operations, a deployment configuration for user interface, etc.... Those specialized instances where then placed on their own hardware. The nifty thing about this approach was how modular the system was and how there was a clear separation of how the system was deployed vs how the services were created. New configurations could be created quickly when required for different customers. The lesson I learned from that experience was to keep things simple so that a modular structure for the overall system could be achieved.

I'll try to catch the upcoming Airhacks session, as it will be interesting to hear your thoughts on this.

Posted by Brian Stark on August 29, 2014 at 08:56 AM CEST #

As with anything, there's balance.

If you're talking simple services, multiple WARs, separately deployed vs bundled in an EAR, offer the ability to granularly deploy and update your application without having to bounce the monolithic EAR.

Their is a management downside of working with individual WARs, simply more moving parts to keep track of. Also, each WAR drags it's own copy of ostensibly "common" libraries along with them.

This also affects JPA memory and caching.

A single WAR is important for an actual "web app", notably just to manage shared session state, especially things like the login status. These can be mitigated by using external actors to manage the session, but kind of a pain when session management comes for free, plus you'd need to (ideally) add some kind of SSO capability.

You also can not readily share EJB functionality across WARs, with resorting to Remote EJBs. Mind, most containers optimize Remote calls within the container.

But a single WAR, with embedded EJBs, perhaps leveraging a local, separately deploy MDB (since WARs cannot have MDBs) covers a startlingly large number of use cases. Even the EJBs can be shared, to a point, if implemented in a common, shared library. But this breaks down for Singletons (assuming you want a Singleton per container/"application").

There's value in keeping the deployable sizes down just in terms of turnaround time, and application risk during upgrades if you can partition your overall app that way.

Add in the capability of some containers to offer parallel deployments (deploying the same WAR over an existing WAR, with old session working against the original, while new traffic hits the new WAR). Things like this suggests towards a "more WARs" deployment methodology than a "single big EAR".

For the record, our apps are single EARs. One of our apps has seven WARs in it, all working against the common EJB core.

But legacy code is not the easiest ship to steer.

Posted by Will Hartung on August 29, 2014 at 11:57 PM CEST #

Post a Comment:
  • HTML Syntax: NOT allowed
Online Workshops
...the last 150 posts
...the last 10 comments