I'm currently helping with the design of the architecture of a new client-server application the company I'm working in is about to develop, and I would like to have the Spring Community comment my ideas, and give me better ideas maybe, regarding how could I tweak or overhaul the whole design.

To get it short: Client-server rich client web-oriented application, for managing items with an integrated community for information sharing.

Swing Rich Client & Spring/Hibernate Server.

Ideally the user should be able to collect stuff and organize his collections through the client (both online and offline), and have everything submitted automatically and trasparently to the server whenever going 'online', as to be able to find similar items, users with similar tastes regarding the items, and/or discuss the items with the community (votes, reviews, comments, etc...).

I've already modeled the domain objects as simple POJOs with very little logic inside (I prefer to externalize the logic into services, and leave the domain objects as simple POJOs as possible).

Since ideally the client should be able to work offline for potentially long periods, and scale to possibly a large item database (100.000+ items), I was planning to hold an in-memory database (hsqldb, and store it on disk on close) on the client, and transfer the domain objects from the server, to the client, saving them in a local database, and planning to do a 'synchronization' every time the client goes online (by submitting the modified data, and downloading the new data from the server).

Possible architecture:

SERVER - DAO Layer (Spring-Hibernate)
For persistence and data access. Modelled after the domain object, with pinpointed methods to load/search/store/update instances of them. No validation is done here, except the validation esplicitly needed for data consistency (through hibernate/db constraint, or logic constraints).

SERVER - Service Layer (exposed through httpInvoker remoting)
Exposing to the clients all the needed services to interact with the server and the community. This layer should be responsible of checking the user authorization, validating the clients requests and the involved data, and handle the logic for realizing the needed services, by accessing the DAO layer for data access.

CLIENT - Controller Layer (client backend handling the data synchronization and validation)
Client logic for handling the communication with the server. Should implement the needed services, to give the presentation layer the data needed for user interaction, should do a first validation of data prior to forward data to the server, and should implement the possible offline operations, and the synchronizing with the server when needed.

CLIENT - Presentation Layer (GUI)
Client logic for retrieving the needed info through the controller layer, render them, and allow the user to modify and add the needed items, and do everything he should be able to do with the application, both offline and online.

This is a draft of the four layers I was planning to divide the architecture in, but ANY advice regarding a better organization is welcome. Remember though, that while I'm not planning to make this a web application (it's stricly client-server, with a rich swing client), I would love anyway to maintain the flexibility to be able to add a web-client tomorrow, if the service focus will shift from the desktop offline work, to the full online web service.

Now, onto my two biggest doubts/unresolved problems:

DOUBT ONE: Domain Object Relationships DB Mappings
My DOM is made up of several objects which share the same relationships. For example there are several domain objects which can be commented, voted, reviewed, tagged, etc... Since the best way to do this in java is surely to have proper interfaces (Votable, Commentable, Reviewable) implemented in the needed POJOs, I'm now in the process of deciding how could I map this into the database.

Ideally, I would love these associations to be bidirectionals (for example, I would love to do review.getItem() to get the reviewed item, and to do item.getReview() to get the reviews associated with that item), but since they are polimorphic (several domain objects can be reviewed: User, Item, Collection... and they are too different from each other to use a base class for them, and moreover they would need to extend SEVERAL classes, as they have to be commentable, reviewable, votable,... hence the interfaces.), I'm very doubtful on how to do this efficiently. ANy suggestion or proposed solution?


DOUBT TWO: Client-Server synchronization workflow
Given the prerequisite (offline work), should I use a full-fledged database as I said, and persist all the offline modification to the local client database, and synchronize it the server when needed, or just simply cache the retrieved data and save the users operations for submitting later to the server, when going online?

In the case of the database, I don't know exactly how can I handle the synchronization without impacting too much on the database or the network (I don't want to re-read and confront EACH involved ITEM). Maybe I should use some kind of 'tagging' to recognize which items have been modified, both on the server nad the client, since the last synchronization, like a timestamp.

In the case of caching, It would be a nightmare to deal with the overriding cached data. If for example, I add an item to a collection, I would love to show this even if I've not yet synchronized with the server, but this would mean introducing some kind of logic to handle the 'data' not yet submitted to the server, and have these over-ride the DOM data.

Which workflow is easier to deal with? Which is more performant, if implemented correctly? Which one would you suggest, given the prerequisite?n Is there a third better one I've missed?


***

Any help is GREATLY appreciated, and will earn you a couple of beers offered by myself the first time you happen to pass from Milan, Italy ^_^ :)