Home/ Questions/Q 7218487
In Process

The Archive Base Latest Questions

Editorial Team
  • 0
Asked: 2026-05-28T21:29:20+00:00

Let’s say I’m writing a Java backend for some front-end GUI (Swing) tool. This

  • 0

Let’s say I’m writing a Java backend for some front-end GUI (Swing) tool. This backend will consist of many different types of EJBs for middleware/business logic, as well as some web services that filter & forward requests on to those EJBs.

As far as packaging & deployment goes, we have several different possible strategies:

  • 1 monolithic EAR/1 appserver – package all EJBs into JARs, and the web services into a WAR, and package all of these inside 1 monolithic EAR; that EAR is then deployed to an app server (say, GlassFish)
  • Many tiny EARs/1 appserver – package each component (each EJB, and each web service) into its own JAR/WAR, and then each JAR/WAR into its own EAR; thus there is a 1:1 ratio between component and EAR; each EAR is then deployed to the same app server
  • Many tiny EARs/Many appservers – same as above, except each “tiny” EAR gets deployed to its own app server; thus there is a 1:1 correlation between component and app server
  • No EARs/Many appservers – same as above except remove the “middlemen” EARs and just deploy each packaged JAR/WAR to its own appserver

What are the pros/cons of each of these 4 strategies? Are some more secure? Performant? More conducive for clustering/replication? Are some of these strategies just plain silly?!?

Thanks in advance!

Share

Leave an answer

You must login to add an answer.

Need An Account,

1 Answer

  1. Editorial Team

    Packaging applications has no inherent impact on security. The number of services exposed, individual servers, request endpoints, etc. as well as the way in which the services access resources that need to be protected are what security is concerned with, not how something is packaged.

    That said, the main issue you are looking at here is monolithic vs. modular. Once you understand that that is the core issue, all of the existing literature about tradeoffs involved are relevant.

    Specifically, you will be looking at:

    1. Scaleability – Many small pieces are more flexible to scale, since you can scale each piece on it’s own
    2. Complexity – Wireing together small services allows you to keep the individual services much less complex, since they have to worry about fewer things
    • 0