RE: [Hibernate] remotely access persistent objects

[Ara Abrahamian]

I think you need something like EOB but anyway…   I implemented something like that. I add a CGLIB-based interceptor to my Hibernated objects, then whenever a dependent object or a collection of dependent objects are accessed by calling a getBlabla method I send a request to the server and retrieve the rest of the information, then it’s cached. So the whole graph is lazy=”true” but retrieved transparently. A runtime exception is thrown if something goes wrong. Ara. -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andrej Gabara Sent: Monday, February 17, 2003 7:27 PM To: [EMAIL PROTECTED] Subject: [Hibernate] remotely access persistent objects     I'm wondering how many people would like to access persistent objects from a remote client directly. I guess most people use servlets/JSP, in which case they don't care about remote accessibility.   Looking at J2EE, entity beans can be accessed remotely. However, every call to an entity bean to a remote client is basically a remote call, so performance is bad. That's why people recommend the session facade design pattern. Same can be applied if Hibernate is used instead of local entity beans. However, I don't like that pattern that much, because you have to deal with value objects, and the object model is very object oriented.   Ideally, what I would like is a framework that provides the following features:   (1) remote access to business objects. Framework provides smart proxies that can cache property      values, such that a call to a business object from a remote client doesn't always result      in a remote call. A smart proxy could also be serialized to the client with some initial      state, so calling getXYZ() won't cause a remote call. Further, smart proxies could batch      property updates into one remote call (setX(), setY(), flush()). Any update to remote objects      on the server part of the client session could then automatically update cached property      values of smart proxies on the client, implemented as extra data of a RMI call reply.   (2) The framework could use its own version of RMI where RemoteException is a runtime      exception --> remote interfaces are not require to declare throwing RemoteException.      This has the advantage that a remote proxy (or stub) could implement a Java2      collection interface, such as java.util.List, instead of creating its own interfaces for      collections.   Are there other people who would like functionality like this?   Thx Andrej