Options to communicate between WARs in the same EAR

Question

What options do you have to communicate between the WARs in an EAR? We have several WARs providing different webservices deployed within one EAR. For their tasks they need to communicate with the other WARs. Of course they could communicate using webservices. What other, perhaps more efficient, options are there?

EDIT: The reason for the communication is that the modules use some shared functionality, and we want to locate this functionality in only one place, since it requires a significant amount of resources. Also, this requires synchronous communication.

Answer 1

Two things come to mind

1. There's JMS for sending signals.
2. EJB could record shared information.
3. A lib jar in the EAR's lib directory.

If you just need shared methods, 3 is what you want. But your edit points tells me you've got shared functionality that operates on shared data. For example, you've got user records that both WARs access and update. If so, you want an EJB.

Answer 2

Why not put the common classes into a JAR and work with them directly? Or slightly more heavy weight make the common classes session beans?

Answer 3

Since your edit seems to imply that the communications are not actually required between WARS, but both need to access the same shared resources. The simplest solution would be to put the jars for this resource in the EAR and add the dependency for those jars to both web projects so they are using the shared resource.

If there is stateful code in both web projects that need to be updated, then your only option is to make a call to the servlet for the web project (assuming the stateful code is contained within the web project).

Just remember that the shared resource must be threadsafe.

Similar question here.

Answer 4

First, you should be clear about what is that you are sharing. You should differentiate between the service and a library. Library lets you share the common functionality, this is what you achieve when you use log4j library for example. In that case, you setup log4j in each project that is using it. On the other hand, you could have the centralized logging service that has its own logging configuration and lets you manage this in a single place. In this case, you need to share the service.

You can share the library by placing the jar inside each war or inside the ear. You can share the service by being the service client. So, your web services can use another service. In that case, one web service is a client of another, achieving service composition (a common pattern in enterprise development)

If both service client and service itself reside inside the same ear, than you might avoid some overhead by calling the service “directly”, for example using the Spring’s parent context feature: http://springtips.blogspot.com/2007/06/using-shared-parent-application-context.html but I would advise against flattening the service because you will loose different benefits that having service in the first place provides like governance, manageability etc.