Architecture - Multiple web apps operating on the same data

Question

I'm asking for a suitable architecture for the following Java web application:

The goal is to build several web applications which all operate on the same data. Suppose a banking system in which account data can be accessed by different web applications; it can be accessed by customers (online banking), by service personal (mostly read) and by the account administration department (admin tool). These applications run as separate web applications on different machines but they use the same data and a set of common data manipulation and search queries.

A possible approach is to build a core application which fits the common needs of the clients, namely data storage, manipulation and search facilities. The clients can then call this core application to fulfil their requests. The requirement is the applications are build on top of a Wicket/Spring/Hibernate stack as WARs.

To get a picture, here are some of the possible approaches we thought of:

A The monolithic approach. Build one huge web application that fits all needs (this is not really an option)

B The API approach. Build a core database access API (JAR) for data access/manipulation. Each web application is build as a separate WAR which uses the API to access a database. There is no separate core application.

C RMI approach. The core application runs as a standalone application (possibly a WAR) and offers services via RMI (or HttpInvoker).

D WS approach. Just like C but replace RMI with Web Services

E OSGi approach. Build all the components as OSGi modules and which run in an OSGi container. Possibly use SpringSource dm Server or ModuleFusion. This approach was not an option for us for some reasons ...

Hope I could make clear the problem. We are just going the with option B, but I'm not very confident with it. What are your opinions? Any other solutions? What are the drawbacks of each solution?

Answer 1

I think that you have to go in the oppposite direction - from the bottom up. Of course, you have to go forth and back to verify that everything is playing, but here is the general direction:

Think about your data - DB scheme, how transactions are important (for example in banking systems everything is about transactions) etc.

Then define common access method - from set of stored procedures to distributed transaction engine...

Next step is a business logic/presentation - what could be generalized and what is a subject of customization.

And the final stage are the interfaces, visualisation and reports

Answer 2

B, C, and D are all just different ways to accomplish the same thing.

My first thought would be to simply have all consumer code connecting to a common database. This is certainly doable, and would eliminate the code you don't want to place in the middle. The drawback, of course, is that if the schema changes, all consumers need to be updated.

Another solution you may want to consider is giving each consumer its own database, using some sort of replication to keep them in sync.