Having also scanned the other replies... The main issue as I see it is that you have shared data undergoing a degree of concurrent access, so data consistency and integrity issues must be at the top of your agenda.
Therefore I think a shared persistence layer is a must, but only where your applications data models overlap. Design all your persistence code in the same way and partition it into 'shared' (entities used by more than one application) and 'non-shared' (used only by one application). Use approachs 'B' and 'C' and build each application completely self-contained except for the shared model, which you should make available as a separate 'core' application. If you use Spring to wire the apps to the core, then you can trial the different transport options (true RMI, Spring remoting, web services) with just configuration changes and decide which works best for you - which mitigates the risk of choosing a 'bad' protocol. Don't forget that you'll want a JTA transaction that encompasses the database changes made by both parts of your application, the shared and non-shared. If an 'unshared' entity becomes shared them move it into the core application. Don't start making cross-calls between applications just to get hold of data. Soap based web services are unlikely to be the answer. Soap is good for infrequent communication between applications, it is too heavyweight for messaging between application tiers. Remember, web services should expose just that, services, not low-level database operations. On Dec 3, 7:04 pm, etzel <[EMAIL PROTECTED]> wrote: > Hi guys, > > 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 > fulfill their requests. The requiremnt 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? > > Thanks > Nick --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "The Java Posse" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/javaposse?hl=en -~----------~----~----~----~------~----~------~--~---
