Separate Web Tier and Business Logic tier.

[dcioccar]

Hi all,

I'm trying to understand how I might put together an application where I have a number of web applications which all need to reuse common business logic. Rather than place the logic in each web application, I would like to create a separate tier (which could run on a separate machine).

Using spring in my web tier (inside Tomcat) is quite well documented and straightforward. My concern is how to run Spring in the middle tier, where ideally there won't be any Tomcat? How can one instantiate a Spring container in a standalone mode (and I'm not talking rich client here, I'm talking about on the server side). How could I, for example, construct a Spring container, which handled all my business objects and their persistence and ran as an NT (windows) service?

Has anyone constructed an architecture such as this? Which remoting protocol would be the most efficient for communications between the web tier (tomcat + spring) and the middle tier (spring standalone)? RMI?

Thanks for any assistance,
Dominic.

[fonz]

I can't give you an advice about which remoting-communication protocol
to chose - i'm only doing 'small-systems',
but to create an application in 'standalone-mode' simply
use a FileSystemXmlApplicationContext.

To use your java application as daemon(*nix) or service(windows),
take a look at this project http://wrapper.sourceforge.net/

chris

[tentacle]

You can put your business logic in a seperate WAR and deploy that in your servlet container. In this WAR you can expose your services with HTTP invoker.

Your client applications (web application, rich clients, ...) can access the business logic using HTTP invoker.

[wpoitras]

Why do you want to run the business tier on a seperate machine? Initially you can design your business objects so they run locally, and when you later want to scale the system you can move the business objects to another machine without having to redesign your web tier.

[tentacle]

Why do you want to run the business tier on a seperate machine? Initially you can design your business objects so they run locally, and when you later want to scale the system you can move the business objects to another machine without having to redesign your web tier.

I'm not agrueing to run business logic on a separate machine although this is entirely feasible. Running your business logic centrally through remoting instead of in each deployed client locally offers a guarantee that there is only one version of your business logic deployed.

[manifoldronin]

There is difference between "sharing the same codebase", and "sharing the same physical deployment". I'd like to understand why it is worth all the remoting cost and extra architectural complexity to share one single physical deployment of the business tier, vs. sharing the same code base by including th same jar in every web app - how often do we redeploy a production web app in real world, like, three times a year?

[tentacle]

There is difference between "sharing the same codebase", and "sharing the same physical deployment". I'd like to understand why it is worth all the remoting cost and extra architectural complexity to share one single physical deployment of the business tier, vs. sharing the same code base by including th same jar in every web app - how often do we redeploy a production web app in real world, like, three times a year?

I'm not saying this is always a requirement. If you have N client deployments depending on a single business logic tier accessing this business logic through remoting instead of local executions allows you to re-deploy the central BL deployment once instead of updating N clients as long as the client side API does not change. This can be an important feature, for example to fix bugs in a short timeframe.

[Martin Kersten]

This can be an important feature, for example to fix bugs in a short timeframe.

Arn't there solutions available for distributed updates? Just wondering... .

[manifoldronin]

I'm not saying this is always a requirement. If you have N client deployments depending on a single business logic tier accessing this business logic through remoting instead of local executions allows you to re-deploy the central BL deployment once instead of updating N clients as long as the client side API does not change. This can be an important feature, for example to fix bugs in a short timeframe.

Mmm, I still don't buy it. :wink:
I admit it's more convenient, but my question is whether it's worth the performance and architectural complexity penalties. Especially when you consider that whenever you deploy a new version of this central BL, chances are you will need to run all the client apps through regression tests anyway (and lots of other release preparation work), so is the time spent on repackaging client apps with a new version of the BL jar really that significant?

[dcioccar]

You can put your business logic in a seperate WAR and deploy that in your servlet container. In this WAR you can expose your services with HTTP invoker.

Your client applications (web application, rich clients, ...) can access the business logic using HTTP invoker.

Effectively, this is the other scenario that I was thinking about. In this case, though, if the business logic tier was running in the same tomcat instance (asame JVM) as the web applications, it would seem to be a pity to use a remoting protocol for the communications.

My question in this case would be:

Is there any way to use Spring with Tomcat at a lower level than at a web application level? Can you get Tomcat to load Spring using a lower level classloader so that any services, beans, etc. could be made available to all the web applications running within the specific Tomcat instance?