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!
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: