Which deployments for an Java EE Application with different interfaces to other systems

Question

I'm developing an Java EE application which links different systems with different interfaces.

I have:

• SOAP, called by a customer
• Another SOAP Interface called by a Webpage
• REST, called by mobile apps

And then I've some business logic behind for database operations and calling some back end systems.

How would you split up this enterprise application in different deployments? I see three different ways:

• Build just one big EAR with everything inside (one deployment)
• Build a module for the business logic and deploy three different front end modules, each containing this business logic module (three deployments)
• Build three front end modules calling a fourth module containing the business logic via remote interfaces (four deployments)

I would tend to the first solution, pack everything together in one deployment, as bug fixes and releases will affect mostly more then one module. But are there also some disadvantages?

In books you can read a lot about JEE but rarely about these kind of best practices.

Answer 1

Bit hard to say which one will be best but here is my 2 cents worth.

So the biggest drawback you can have with a one single BIG ear is that you have to redeploy the world to make a small change. So just based on that I would not go for ONE big ear. Imagine getting to a point where the EAR is 100MB big or something ridiculous like that.

Also since everything is in one EAR if you need to move a module, service, bean or anything to another server to scale you will have to make some fundamental changes to the EAR to split it up. This will incur development time and cost again

Summary:

Your first approach in a nutshell is a simple deployment nothing major. However keep in mind that you have to redeploy everything. In a really large application this will become a problem.The biggest pain Splitting up the application for scaling will cost time,effort and money.

Your second option is a little more modular. However there seems to be some business logic shared by the components. Thus a a update to one EAR might mean a cascading update to other EAR as well.This is essentially duplication of effort.

Summary:

Deployment is more modular allowing you a little more flexibility in your deployment options. However deployment is more complex. Since business logic and probably data access logic is not in a shared module the code is duplicated in several places. This duplication will incur higher testing and development costs.

Your third option separates concerns across domains. In this case the customer domain, web site domain, mobile domain and the business logic domain. While this will require effort to deploy you have a lot more options.

Summary:

Since shared logic is placed in a separate module this will lead a much more maintainable design. Your unit tests in your business logic will also be of a high quality as they are now not bound to the particular interface/domain. Thus testing will be easier and quality assurance will be much higher. You also eliminate duplication of effort.

This design is also relatively easy to scale. Move the different EARS onto different servers and or scale the servers. One down side is that deployment is much more complex.