PersistenceBrokerEjbClient

[Michael Mogley <mm...@adelphia.net>]

All,

I'd like to write a PersistenceBroker implementation that acts as a client to a PersistenceBroker EJB session bean.  

For remote clients such as Swing apps (and even server-side business objects accessing a remote EJB), there are currently major scalability issues related to RMI and serialization.  I know the recommended approach is to use DTOs as go-betweens for the client GUI and server-side domain objects.  However, doing this in practice implies having the client layer forgo all the benefits of object-traversal and lazy-loading that a framework like OJB offers for domain objects.

What I propose is the following: a PersistenceBroker implementation specific to client-side code where access to the server-side objects is remote and must therefore incur the overhead of RMI.  A use case will illustrate the mechanics of what I mean:

Consider the following classes:

- Album [ID<Integer>, name<String>, description<String>, coverPhoto<Photo>]
- Photo [ID<Integer>, name<String>, description<String>, album<Album>]

Use Case: client reads Album for given ID and updates Album.name

1) client queries PBEjbClient for Album with given ID
2) PBEjbClient forwards call to PBSessionBean to retrieve Album with given ID.
3) PBSessionBean retrieves given Album and serializes, skipping proxied fields (such as coverPhoto, which is a persistent object mapped to another table)
4) PBEjbClient deserializes Album and returns instance to client
5) client sets Album.name and calls PBEjbClient.store(album)
6) PBEjbClient retrieves Album.ID, Album.timestamp, and the only dirty PersistentField from Album (Album.name) and wraps all three in a DTO
7) PBEjbClient serializes DTO and sends to PBSessionBean
8) PBSessionBean deserializes DTO, retrieves Album for the DTO's ID, and compares the timestamps.  If Album.timestamp is newer, it throws back a StaleObjectException (which is propagated to client).  Otherwise, it updates all fields in the Album to the corresponding DTO field values.

Obviously, this would be more complicated if the coverPhoto was defined and parts of it were also dirty (but then the approach above could be modifed to use recursion).

I am anticipating a project in the very near future that uses distributed EJBs and rich clients and so have an immediate need for such a feature.  I'd like develop this myself and contribute back to the codebase once I'm satisfied everything works.

I need guidance on this.  Has some work already been done that I should look into?  Is my approach all wrong?  To enforce the requirement for objects participating in remote updates to have timestamps, I plan to have a PersistentObject interface.  Would this be terribly wrong, in light of the goals of transparent persistence?

Thanks for your humble opinions,

Michael

Re: PersistenceBrokerEjbClient

[Michael Mogley <mm...@adelphia.net>]

Sorry, didn't mean to exclude anyone.  I'll take arrogant opinions too. :-)

Michael

----- Original Message ----- 
From: "Michael Mogley" <mm...@adelphia.net>
To: "OJB Developers List" <oj...@db.apache.org>
Sent: Wednesday, March 24, 2004 3:38 PM
Subject: PersistenceBrokerEjbClient


All,

I'd like to write a PersistenceBroker implementation that acts as a client
to a PersistenceBroker EJB session bean.

For remote clients such as Swing apps (and even server-side business objects
accessing a remote EJB), there are currently major scalability issues
related to RMI and serialization.  I know the recommended approach is to use
DTOs as go-betweens for the client GUI and server-side domain objects.
However, doing this in practice implies having the client layer forgo all
the benefits of object-traversal and lazy-loading that a framework like OJB
offers for domain objects.

What I propose is the following: a PersistenceBroker implementation specific
to client-side code where access to the server-side objects is remote and
must therefore incur the overhead of RMI.  A use case will illustrate the
mechanics of what I mean:

Consider the following classes:

- Album [ID<Integer>, name<String>, description<String>, coverPhoto<Photo>]
- Photo [ID<Integer>, name<String>, description<String>, album<Album>]

Use Case: client reads Album for given ID and updates Album.name

1) client queries PBEjbClient for Album with given ID
2) PBEjbClient forwards call to PBSessionBean to retrieve Album with given
ID.
3) PBSessionBean retrieves given Album and serializes, skipping proxied
fields (such as coverPhoto, which is a persistent object mapped to another
table)
4) PBEjbClient deserializes Album and returns instance to client
5) client sets Album.name and calls PBEjbClient.store(album)
6) PBEjbClient retrieves Album.ID, Album.timestamp, and the only dirty
PersistentField from Album (Album.name) and wraps all three in a DTO
7) PBEjbClient serializes DTO and sends to PBSessionBean
8) PBSessionBean deserializes DTO, retrieves Album for the DTO's ID, and
compares the timestamps.  If Album.timestamp is newer, it throws back a
StaleObjectException (which is propagated to client).  Otherwise, it updates
all fields in the Album to the corresponding DTO field values.

Obviously, this would be more complicated if the coverPhoto was defined and
parts of it were also dirty (but then the approach above could be modifed to
use recursion).

I am anticipating a project in the very near future that uses distributed
EJBs and rich clients and so have an immediate need for such a feature.  I'd
like develop this myself and contribute back to the codebase once I'm
satisfied everything works.

I need guidance on this.  Has some work already been done that I should look
into?  Is my approach all wrong?  To enforce the requirement for objects
participating in remote updates to have timestamps, I plan to have a
PersistentObject interface.  Would this be terribly wrong, in light of the
goals of transparent persistence?

Thanks for your humble opinions,

Michael


---------------------------------------------------------------------
To unsubscribe, e-mail: ojb-dev-unsubscribe@db.apache.org
For additional commands, e-mail: ojb-dev-help@db.apache.org