Subject: RE: remotely access persistent objects
Newsgroups: gmane.comp.java.hibernate.devel
Date: 2003-02-17 22:34:22 GMT (5 years, 33 weeks, 2 days, 1 hour and 59 minutes ago)
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:
hibernate-devel-admin <at> lists.sourceforge.net
[mailto:hibernate-devel-admin <at> lists.sourceforge.net] On Behalf Of Andrej Gabara
Sent: Monday, February 17, 2003
7:27 PM
To: hibernate-devel <at> lists.sourceforge.net
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