0

We are currently working on a project for college which we would like to implement as a logic module and UI module. We have little experience deploying web applications, however we came up with the following alternatives:

  1. Deploy it as a single WAR project (which would solve the problem we have about communicating the UI with the backend of our application).
  2. Deploy two WAR projects in the same server using webservices for communication between the projects. (We have a prototype using this approach deployed on a Tomcat server)
  3. Deploy a WAR project and EJB project.
  4. Deploy an EAR project which would contain the references to the WAR and EJB projects. (We have a prototype using this approach deployed on a Glassfish server)

We would like to know if any of these alternatives is incorrect, or if any of the alternatives is better than the other. Specifically, why would it be useful (or not) to deploy the project as an EAR module?

The project right now is starting, so we will only be handling a couple hundreds of users right now. However, if the project succeeds we would need to deal with a couple million of users.

user2100776
  • 81
  • 1
  • 9

1 Answers1

1

None of the alternatives are incorrect, though Tomcat is a servlet container, if you want EJBs there you'd need something like TomEE which is Tomcat extended to full EE support. Or use that Glassfish.

What's best depends on your specific requirements: do you need / value more the decoupling of modules or would you rather have the consistency and reliability you get bundling things together. EJBs also have some additional benefits that might be of interest, but they're not relevant for every project. Note that in addition to alternatives mentioned, there are others, such as JMS-based communication, HTTP REST communication and using OSGi to decouple the packages.

About why it would be useful to deploy the project as an EAR module, quoting wikipedia: "EAR (Enterprise ARchive) is a file format used by Java EE for packaging one or more modules into a single archive so that the deployment of the various modules onto an application server happens simultaneously and coherently. It also contains XML files called deployment descriptors which describe how to deploy the modules.". So basically you get the benefits of coupling that boils down to reliability, you'd always know how your modules are deployed in contrast to each other. EAR modules supports EE mechanisms, such as EJB modules, very well and you get a controllable container.

There already exists a thread When is it appropriate to use an EAR and when should your apps be in WARs?, which might be of interest.

Community
  • 1
  • 1
eis
  • 51,991
  • 13
  • 150
  • 199
  • Thanks for your reply. However now I have another question. If we decide to deploy the project as several WARs, how should the communication between the WARs be done? We were thinking about using ApacheCXF webservices, but we read that using EJBs would be better in terms of performance. Also, could we accomplish that in a better way? (Should we also read about JMS and OSGi?) – user2100776 Feb 23 '13 at 18:10
  • Web services are well defined in standards and there exists good security mechanisms as well as crossplatform support, but they're also complex, somewhat fragile to implement and some other means might be more performant like you say. There is no one answer as to which method you should be using, it depends on your use case. JMS is highly performant, xa-aware and persistable, and easier to grasp than OSGi, I would say, but they're both also possibilities, too. – eis Feb 23 '13 at 18:22