This discussion is archived
6 Replies Latest reply: Apr 12, 2010 3:10 PM by EJP RSS

Optionally serializing a part of object graph

843790 Newbie
Currently Being Moderated
Hi all,

I have a problem regarding Java custom serialization. I have a graph of objects and want to configure where to stop when I serialize a root object from client to server.

Let's make it a bit concrete, clear by giving a sample scenario. I have Classes of type

Company
+{color:#3366ff}*Employee*{color} (abstract)+
Manager +extends {color:#3366ff}Employee{color}+
Secretary +extends {color:#3366ff}Employee{color}+
Analyst +extends {color:#3366ff}Employee{color}+
Project


Here are the relations:
Company(1)---(n)Employee
Manager(1)---(n)Project
Analyst(1)---(n)Project


Imagine, I'm on the client side and I want to create a new company, assign it 10 employees (new or some existing) and send this new company to the server. What I expect in this scenario is to serialize the company and all bounding employees to the server side, because I'll save the relations on the database. So far no problem, since the default Java serialization mechanism serializes the whole object graph, exluding the field which are static or transient.

My goal is about the following scenario. Imagine, I loaded a company and its 1000 employees from the server to the client side. Now I only want to rename the company's name (or some other field, that directly belongs to the company) and update this record. This time, I want to send only the company object to the server side and not the whole list of employees (I just update the name, the employees are in this use case irrelevant). My aim also includes the configurability of saying, transfer the company AND the employees but not the Project-Relations, you must stop there.

Do you know any possibility of achieving this in a generic way, without implementing the writeObject, readObject for every single Entity-Object? What would be your suggestions?

I would really appreciate your answers. I'm open to any ideas and am ready to answer your questions in case something is not clear.


Alper
  • 1. Re: Optionally serializing a part of object graph
    EJP Guru
    Currently Being Moderated
    Not possible with Java serialization, or XMLEncoder for that matter. I wouldn't use Serialization for a task like that in the first place: I would use a database.
  • 2. Re: Optionally serializing a part of object graph
    843790 Newbie
    Currently Being Moderated
    Hi, thanks for the quick reply!

    I do have a database already and the objects are stored there in the end. The serialization I mean here takes place on the network, from client to the server.

    Alper
  • 3. Re: Optionally serializing a part of object graph
    jtahlborn Expert
    Currently Being Moderated
    I wrote a system like this, and i'll just say that it was a bear to write and maintain. it kind of turned me off to the idea of making your DAO's and DTO's the same objects. i'm not sure i have a better solution to that problem that doesn't involve a lot of duplicate objects, but anyway.

    the way i handled it was writing custom "clone-like" methods on the objects. i was able to write these in a generic fashion because we were using hibernate directly, which exposes all the entity "metadata". this allows you to reflectively clone an entity object without any per-type logic. then, you can write this "clone-like" behavior to create whatever sub-graphs of the entity graph that you want. you can then send these cloned sub-graphs over the wire. since you are only creating new entity objects (you can share the non-entity data, just like a normal clone), it doesn't add much overhead (considering you are about to send these objects over the wire).
  • 4. Re: Optionally serializing a part of object graph
    jschellSomeoneStoleMyAlias Expert
    Currently Being Moderated
    javapollo wrote:
    Do you know any possibility of achieving this in a generic way, without implementing the writeObject, readObject for every single Entity-Object? What would be your suggestions?
    First step - realize that it is impossible to write a system to generically handle every business scenario.
    Second step - realize that generalization has a downside in increased complexity (and thus increasing maintenance when it comes to debugging, upgrading and even just understanding it.)

    From that one decides on a reasonable middle ground where one uses some generalization for simple cases, such as an entity insert, and specific solutions for more complex business logic and even producing one shots for some business problems. And renaming a company might fall into that last category (unless you are in mergers/acquisitions.)

    Examples of the second sort come about by realizing that when a user wants a list of company names (and perhaps some misc data) then they do NOT need the entire tree that represents a 1000 companies. All they need is the specific data that will be displayed and a id that allows them to request a single company. That concept generalizes to most trees that represent a lot of data (employees, inventory, etc.)

    And myself I am a big fan of DTOs to allow boundary layer communications (and not solely as used for database layers.)
  • 5. Re: Optionally serializing a part of object graph
    843790 Newbie
    Currently Being Moderated
    I am not sure if my idea is good.. :) I would say that u can use XML instead of serializing the objects.. There are many tools like JAXB available that will help you to read the XML and convert to object and persist the objects back to XML. You can use this XML for sending data to ur server..

    A * R
  • 6. Re: Optionally serializing a part of object graph
    EJP Guru
    Currently Being Moderated
    That doesn't solve the problem because it doesn't inhibit sending the entire object graph.