First, ask yourself whether this is really necessary. If your real objective
is to minimize client/server interaction, why have objects on the client
at all?
IBM's Ultra-Thin Client is an example of an approach that discards
client side objects in the interest of improved performance.
Clients operate on strings, not objects.
If you really need objects on the client, you'll need a way to let developers
specify the "shape" of the object graphs they wish to receive. I call this
specification a "tracing". It specifies which instance variables of which
classes will be retrieved. Other instance variables will not be
transferred. I use the term "tracing" because this specification
guides the path that the object marshaller follows when packing the
object for transfer.
1. A real system will need to support multiple tracings.
Consider a simple system for editing Persons.
Such a system will likely have a query feature that returns
a set of minimal Person data, allowing the user to select
a Person to edit. At the point, you'll want to load all
the data for that Person.
For efficiency, you'll need two tracings for this example.
The query should use a tracing that just returns identifying
information. A second tracing will return the complete Person.
In a real system, Person may require many tracings, so that
different applications can specify precisely the Person data they
need.
The scope of a tracing can be the current thread, the current]
window, a piece of code, or an entire application.
2. Avoid ripple loading.
In the interest of transparency, many systems use Proxies
that implement the interface of the object they represent,
and fault the object in if it's not present.
If you take this approach, and you're not careful, you'll
get miserable performance.
Consider the previous Person example.
Let's say the user queries for Persons with first names
starting with 'Dav'. Following the approach outlined above,
we retrieve some Persons, each of which contains real data
for only the FirstName and LastName instance variables.
Now, let's say we fill each of the other instance variables
with simple Proxies.
Our user goes on to select 'David Smith', and we open an editing
window on that Person. Each field requests a different value from
its corresponding instance variable, and each request turns into a
call across the network for the corresponding instance variable.
I call this situation "ripple loading", and it leads to poor
performance.
Here's a better approach.
Let the Proxy object hold its parent object. In this approach,
expanding a proxy involves reretrieving the parent object under the
current tracing. The result overwrites any proxies during unpacking,
but does not disturb nonproxy instance variables. This can be further
optimized -- the client can tell the sender to avoid sending instance
variables the client already has.
Lisa Retief wrote:
> Hi,
>
> I am trying to come up with and elegant way to share high-level objects
> between server and clients (in a multi-tier environment), but without
> creating unnessary network traffic. For example, the server may pass a
> Person object to the client, but containing just the bare minimum in terms
> of data. The client could then assess what further information it needs, tag
> these data structures somehow, and then ask the object to retrieve them.
> Obviously one would want to minimise server calls, but as trasparently as
> possible. I am calling this "lazy loading". These high level objects will
> probably take the form of Entity Java Beans.
>
> Does anyone have any experience, suggestions or patterns regarding an
> elegant implementation of this?
>
> Thanks in advance, Lisa
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
