multiple WARs/EARs for a web application

I support a web application that consists of multiple modules. Each module is accessed via menu and modules may require to interact with each other to complete a particular transaction.
I want to understand if it is possibe and feasible to create a separate WAR file and treat each module as a stand alone web application. Then using some method make it possible for  modules (which are separate stand alone application) to talk to each other to complete the transaction.

If it is feasible, will there be any impact on the performance? Will the impact be significant?
Who is Participating?

Improve company productivity with a Business Account.Sign Up

shalomcConnect With a Mentor CTOCommented:
forgot about this thread :)

> 1. The only way for diffrent modules (designed as a stand alone web application) to interact with each other is via Web Services.
Well, it is not the ONLY way, but probably the best and most cost effective way.

As for security, integrity and governance:
When all the business processes ran in a single CPU, you
a. had no security authorization problem because the interfaces were internal and you trust internal processes.
b. had no security data leakage problem because internal processes do not use the network to communicate.
c. had no integrity problem because internal processes are usually complete and it is difficult to inject anything foreign into them.
d. all internal processes tend to fail together, so you do not have to manage SLA for each and every one.

When you split business logic among different components,
a. the interface is external and you have to ensure proper authorization, entitlement and authentication.
b. the data runs on the wire and can be sniffed.
c. due to network "noise" and disruptions the message can be incomplete, and things like proxies and IPS enable injection and modification of data on the wire.
d. it is common for a single module to fail while others did not, this must be taken into account.

These issues have solutions, but the thing is that they have to be addressed explicitly. web services  do not deal with any of these issues by default.

javaCaravan0Author Commented:
still waiting for the feedback

You can split up the business logic in the way you describe. The separate modules can even be deployed to different servers.
However, the modules cannot share objects in this scenario. They will have to communicate by web services, either synchronous (via http) or asynchronous via queueing/messaging. This raises the questions of security, transaction integrity, governance and some more.  
Also, your deployment is likely to become much more complex.

Despite the shortcomings, this very well may be the way to go. Application componentization is what SOA is all about :)

javaCaravan0Author Commented:
Thanks for the reply.
Let me clarify what you have explained above:
1. The only way for diffrent modules (designed as a stand alone web application) to interact with each other is via Web Services.
2. can you please elaborate more about your comment on security, transaction integrity and governance. Does web services not provide good security?

I believe if you use an EAR file, you can share the objects & classes between the WARs and other java resources without issues.  A little more information on EAR in general is here in the wikipedia article.  If you were wanting to share objects between EARs, I think that would be when you would have issues as described above. 
From what I understand, an EAR file with multiple WAR files within it should meet your needs.  There may be some performance hit from the general overhead of breaking out the application into a more distributed fashion (more XML to parse, extra classes getting everything loaded) but probably nothing significant and likely well worth it to get the separation that you're hoping to achieve.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.