🚀 go-pugleaf

One approach would be to make Person a serializible class, and make the
collection of children that Person holds a remote class.  Then, whenever a
Person gets serialized from server to client, the contents of the collection
won't be serialized, only its remote reference will be transferred.

The server implementation of the collection class could use lazy
initialization to defer doing any work (like querying a database) until the
client starts asking for children.  If the collection supports a method that
allows for many children to be requested at once, then just those children
that are needed at any given time can be serialized, avoiding repeated calls
over the network.

By the way, I'm having trouble finding information that discusses these
types of issues - if anyone out there knows of a good source of practical
information on "how to design distributed apps", I'd like to hear about it.

Vidur Dhanda wrote:

> I'm having some trouble fully understanding a design issue.  Perhaps,
> some reader can point out a design pattern or offer some insight.
> Please bear with me, I think I'm making it a lot harder than it need be.
>

Vidur Dhanda <vdhanda@active-solutions-inc.com> writes:

> I guess, ideally, I want the "primary" object to live on the server, and
> have the ability to migrate a copy/replica to the client.  However, I do
> not want to migrate the entire object but only as much as is required
> and can be "efficiently" transferred.  I suppose that would at least
> suggest not sending embedded collections unless required.  Does this
> make any sense and where would I look for further information?  Or am I
> totally missing the mark?

You might find the following paper helpful for some background
information on these issues:

    http://www.inf.fu-berlin.de/inst/pubs/tr-b-98-13.abstract.html

Basically, I think you are trying to do something for which current
mainstream distribution technology just isn't powerful or flexible
enough.  The main problems with Java/RMI are that

  (1) RMI makes it a property of the _type_ of an object whether it
      should be passed by value (copied to remote sites) or by
      reference (stay on the server and access it remotely).  But in
      situations like yours you want more flexibility, e.g. to decide
      on parameter passing modes per _method_ or per _parameter_.  The
      upcoming CORBA Objects-by-Value will be somewhat closer to this.

  (2) Copying object state around (as RMI's serialization does) is
      only a poor substitute for true object migration (where
      references are redirected so that an object always only exists
      at a single place in the system), or object caching.  Migration
      and caching should be controllable both statically in the code
      (e.g. passing modes such as pass-by-move or pass-by-visit) and
      dynamically by a run-time system that moves or caches objects to
      optimize communication behaviour.  Research systems like Emerald
      or Orca demonstrated this ten years ago, but there is no
      off-the-shelf technology that does this for you yet.

Sorry for this rather academic remark, but I believe you are simply
pushing the current technology to its limits, which also explains why
there is little practical advice on such issues yet -- people are just
beginning to do this on a large scale, and technology is still
struggling to keep pace with that.  See the above paper for references
to some more experimental distribution platforms that, I believe, are
much closer to your needs already.

As for a real practical solution of your problem, I think what David
Pirkle wrote is about as good as it currently gets.

Regards,

Andre Spiegel
Free University of Berlin

David Pirkle wrote in message <36A10272.E1CA0111@dp.dp.dp>...
>One approach would be to make Person a serializible class, and make the
>collection of children that Person holds a remote class.  Then, whenever a
>Person gets serialized from server to client, the contents of the
collection
>won't be serialized, only its remote reference will be transferred.
>
>The server implementation of the collection class could use lazy
>initialization to defer doing any work (like querying a database) until the
>client starts asking for children.  If the collection supports a method
that
>allows for many children to be requested at once, then just those children
>that are needed at any given time can be serialized, avoiding repeated
calls
>over the network.
>
>By the way, I'm having trouble finding information that discusses these
>types of issues - if anyone out there knows of a good source of practical
>information on "how to design distributed apps", I'd like to hear about it.

Have a look at the book "Corba Design Patterns" by Thomas J. Mowbray and
Raphael C. Malveau which is published by John Wiley and Sons, Inc.

>
>Vidur Dhanda wrote:
>
>> I'm having some trouble fully understanding a design issue.  Perhaps,
>> some reader can point out a design pattern or offer some insight.
>> Please bear with me, I think I'm making it a lot harder than it need be.
>>
>
>
>