I suppose the big question I would have is "why the 3rd tier"? Not logical tier - you need that - but physical tier.
Management would like to offer the software in an ASP model in the future. The next question would be "Why not an HTML interface?". Because management also mandates the user interface be as identical to the old PowerBuilder client/server UI as possible.
My suggestion to you is to not cache the domain objects in the server - move them to the client as an assembly - monkey with them - give them back to the server - execute server side processing on them, put them back in the db.
Yup. That's what we're doing now. I use Hibernate O/R library to handle data access and keep my server side processing stateless. The reason I need caching on the client is because I often make more than one call to the server during a user interaction and sometimes an object that's already on the client get's sent to the client in subsequent server calls.
Here's an example:
1) John Doe logs in. The system contacts the server to get the login information for a User. It returns the User object for John Doe.
2) The user opens his list of messages. The system contacts the server to get the list of messages. Each Message has a Sender and Addressee which are both Users. The server returns Messages for John Doe and he is the Addressee on them.
Because I'm using Hibernate on the server, it makes sure that the same instance of John Doe is associated with each message. Once it gets to the client and is deserialized, I have two instances of John Doe, the one associated with the messages and the one retrieved when the user logged in.
I need something on the client to make sure only one instance of User exists on the client side after multiple calls to the server.
Regards,
John