Best design for multi-webapp access to multiple services

[james]

We have a number of webapps (actually portlets) that need to talk to each other's business layers. Initially we were looking at creating a jar for each portlet's business layer and putting it into tomcat's shared/lib and making each a singleton. This does not seem to be a clean approach and I fear it will come back to bite us in the end if we deploy it this way. Is there a prefered way using spring to allow N number of webapps to access each other's backend services? Ideally I would like to keep each backend service deployed in it's own jar so that they can be maintained seperately, but also have them accessible through one context. Is this possible with spring? This design seems like it could pretty easily be implemented in an EJB tier using stateless session beans, but so far we have looked to avoid adding an EJB container unless necessary.

It seems that this has to be a fairly common request. Are there any best practices for implementing this in spring? Is spring the right solution for this problem or should I look further at an EJB approach?

Thanks,

James

[Stefan Arentz]

We have a number of webapps (actually portlets) that need to talk to each other's business layers. Initially we were looking at creating a jar for each portlet's business layer and putting it into tomcat's shared/lib and making each a singleton. This does not seem to be a clean approach and I fear it will come back to bite us in the end if we deploy it this way. Is there a prefered way using spring to allow N number of webapps to access each other's backend services? Ideally I would like to keep each backend service deployed in it's own jar so that they can be maintained seperately, but also have them accessible through one context. Is this possible with spring? This design seems like it could pretty easily be implemented in an EJB tier using stateless session beans, but so far we have looked to avoid adding an EJB container unless necessary.

I deploy my applications in JBoss with the following structure:

Each application is deployed as an EAR that contains a JBoss service and one or more web applications. (And usually some other app specific things like datasources or connectors)

The service is responsible for instantiating a Spring application context that contains all the core logic. I wrote a very simple JMX bean for that.

The Web applications all have a custom context loader (JMXContextLoaderServlet) that looks up the parent context in the JBoss JMX server and then configure themself as a child of that context.

When applications need to talk to eachother I imlement a simple Service pattern and make that available through RMI. The only thing the other app needs to know then is the RMI endpoint URL and an Interface describing the service (plus support objects if needed).

It works great for me. The 'deploy spring as a service' pattern is also very simple. I've implemented it for Geronimo and JBoss in just a couple of hours.

S.

[james]

We'd like to not increase our footprint to include an EJB container. How would we go about doing this via just Tomcat. We're looking at the ejbtest in cvs mentioned in sprnklings across the forum, but we're just starting to wrap our minds around this.

[Ben Alex]

Any particular reason you need a single, shared application context?

One approach some applications use is to rely on a SSO solution (see Yale CAS w/ Acegi Security for example) and this "ties together" many little webapps into one apparently large webapp. From the user's perspective, anyway. Other benefits of this approach include that your different webapps can be deployed on different servers, with different clustering configurations , with independent development lifecycles, separate deployment operations etc. It's just a more granular approach.

You will of course find some applicationContext.xml files shared between webapps but that is more a version control / build system issue.

[justinus]

Wouldn't caching (thinking of hibernate with oscache) be a good reason to share a root application context, containing DAOs and business logic.
To my knowledge a caching mechanism could not possibly know if some other process has modified data in the database.
Therefore if you have multiple applications that are deployed seperately but access the same database layer they should physically share instances instead of using seperate instances of the database layer logic.
In my case I have a web inteface for managing content and another web interface for reading and searching.
Both interfaces/projects are fairly different in scope but have to access the same database layer.
So instead of putting two Dispatch Servlets in one war file sharing a root application context I would prefer creating two war files. For each project one.
The business logic and the DAOs would reside in a seperate archive (sar - for service archive) and would be deployed seperately.
I'm thinking of doing what Stefan Arentz recommends, although I don't know about the RMI part. I don't see why a service should be called via RMI when it resides in the same application server. I thought that calles would be made directly.

Anyway, I would like to hear more on how to deploy multiple applications with shared resources. What does the Spring philosophy say about this?

Cheers :wink:

Justinus