I would recommend that you would go with the simplest option B first and migrate to service-oriented option D.
You need to have some common API to access database no matter which option you decide on. So it is logical that you start with database access layer first. WS is nice because you can decouple banking transaction from the web front end. Option B is nice and simple because you can leverage database transactions to ensure atomic operation. Option D (WS) is nice when you start adding or changing functionalities. You can shield the changes to logic from the clients and avoiding deploying new version of database API jar to all the necessary servers. Basically, WS provides a 'facade'. Option C (RMI) - I tend to avoid it. The marshaling object couples the components. Basically, you are at the same position as option A. You have to start worrying about serialization and serializationUID, etc. RMI is not seamlessly when you start to modify. Option E(OSGi) - it is one option but do you want to bring the entire package of OSGi for you project? It really depends on the complexity of your project. I would avoid it until you can justify it. I believe in 'keep it simple' motto. Unless you are starting to build various applications with various components you built from, I would avoid it. There is nothing wrong with sharing 'code' by using 'jar' library. -michael lee etzel 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 -~----------~----~----~----~------~----~------~--~---
