Single EAR? Or multiple EARs?

Question

We are in the process of developing a JavaEE 6-based application to be deployed on JBoss EAP 6.1. The app has 2 primary presentation mechanisms: A web admin console, and a RESTful service API. On the backend, both the admin console and the RESTful service API rely on a series of EJBs for performing transactional logic and POJO services for retrieving data.

It is entirely possible that the performance and resource needs for all of these various layers may be different. The RESTful services are rather thin and completely stateless, whereas the admin console is stateful and has more interactive functionality (and therefore more memory and processing required). Since our EJBs perform our primary transactional business logic, they would require more processing power than our POJO data services that simply query the database.

Given such a setup, would it make more sense to deploy a single EAR (in multiple appservers in a clustered configuration) with all of these components, or break down the individual components into separate EARs? My thinking with separate EARs is that I could, for example, deploy more instances of the EJB services if I find there are scalability issues with them, even though the web console (for example) is scaling just fine.

Given the fact that the scalability of each layer/component is different, what approach should I take? Is the overhead of having to make remote EJB calls across EARs too high to consider such a model? Any advice is GREATLY appreciated!

Answer 1

The "Java EE" way would be to deploy application as a single EAR on the cluster. I assume that you are using local interface calls from REST/admin console to EJB-s. Deployment would be simple, if you don't need session replication (you can use sticky sessions) then scalability will be very good.

The only extra element that you will need is load balancer for the web applications (for instance Apache server that would also take care for SSL decoding, static resources serving and, possibly, caching requests that can be cached).

The only problem with such setup might arise for heavy loads, for instance EJBs might eat a lot of server resources, so throughput of the web applications will be difficult to control and can be badly affected by EJBs. If you use sticky sessions user always is redirected to the same server, so no chance to move some users to less loaded server as long as user session lasts.

So, if you plan for high loads then it would make sense to keep web applications and EJBs on separate boxes (or virtual machines) so it is easier to identify bottlenecks and easier to scale that layer which needs that.

The penalty for this would be:

1. remote calls to EJBs. However JBoss 6 has pretty advanced EJBs pooling configuration, so it might not be such a terrible problem.
2. network trafic caused by these remote calls (so if you pass between EJBs and web layer a lot of data, it might be an issue).

Answer 2

In support of Piotr's great comments:

Bundle them together now, and split only if a real need arises in the future.

Consider the Martin Fowler's First Law of Distributed Object Design: Don’t distribute your objects! as a good guideline - if you're going to break it, at least do it consciously and for real business needs.