[OT] Remoting question

[Tom Ziemer <t....@dkfz-heidelberg.de>]

Hi everybody,

This is rather off topic (and a repost from a different list), but this
is bugging me and I am sure, lots of you have faces a similar problem.
Basically it boils down to remoting via web services, RMI, Corba, etc.
and passing objects by value instead of by reference.

Please consider the following scenario: Object Parent and Child are
created on the the client like this:

Parent p = new Parent();
p.setName("Dad");
Child c = new Child();
c.setName("Bert");
p.addChild(c);

// remote call
parentService.save(p);
...

Assuming, that the Parent takes care of saving the Child, there are
several problems:

a) If you send p to the server, your persistence layer will save it for
you and update the id-field, yet this is not visible in the object on
the client, this will force you to have an API like
	 public Parent saveParent(Parent p);
so you have access (via the return value) to the updated object, which
is not really nice, because if you forget to use it, you'll be in trouble.

b) even worse: Looking at the only child Bert: if you update it on the
client, e.g. rename it to "Ernie" (c.setName("Ernie")) this will have no
effect at all, since the object returned by saveParent() will have to no
link to the child object on the client. So you basically have to do
something like:
	p.getChildren().getAt(0).setName("Ernie");

Of course it is possible to use an API like the one I just outlined, yet
 I am pretty sure that it will result in lots of errors.

Any input is appreciated,
regards,
Tom



---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: [OT] Remoting question

[Leon Rosenberg <ro...@googlemail.com>]

Hi,

actually its the problem of the proper architectural design. If you
assume that your client works with objects internally used in the
business layer like in your parent-child example, you are screwed
regardless of hidden updates.

(Btw with CORBA your use-case won't happen, if you design Parent to be
an interface and hence a remote object, but it will be damned slow)

However, if you have a clear ontological separation of component
declaration and component implementation, it should be possible for
the user to understand that the lifetime of 'his' object isn't the
lifetime of the according object in the enterprise.

Example:
ParentVO p = parentService.getParent(id);
ChildVO c = p.getChild("Bert");
c.setName("Ernie");
parentService.update(p);

if you can't force your developers to use this simple pattern you can
turn it the other way around and let the Objects be Proxies.

ParentProxy p = parentService.getParent(p);
ChildProxy c = p.getChild("Bert");
c.setName("Ernie");

c.setName would be something like:
public void setName(String aName){
  parentService.saveProperty(getId(), "name", aName);
  name = aName;
}

public String getName(){
  //of course it need to be synched
  if (name==null)
    retrieveName();
  return name;
}

private void retrieveName(){
  name = parentService.getProperty(getId(), "name");
}

of course you can also use named methods on the server side, but this
will blow your interfaces.

Personally i prefer the first solution, cause its faster and scales
better. I wouldn't also go for Parent.getChild but for
parentService.getChild(parentId, childId) but this depends on your
persistence, network bandwith and how often you need the childs.

regards
Leon

On 8/29/06, Tom Ziemer <t....@dkfz-heidelberg.de> wrote:
> Hi everybody,
>
> This is rather off topic (and a repost from a different list), but this
> is bugging me and I am sure, lots of you have faces a similar problem.
> Basically it boils down to remoting via web services, RMI, Corba, etc.
> and passing objects by value instead of by reference.
>
> Please consider the following scenario: Object Parent and Child are
> created on the the client like this:
>
> Parent p = new Parent();
> p.setName("Dad");
> Child c = new Child();
> c.setName("Bert");
> p.addChild(c);
>
> // remote call
> parentService.save(p);
> ...
>
> Assuming, that the Parent takes care of saving the Child, there are
> several problems:
>
> a) If you send p to the server, your persistence layer will save it for
> you and update the id-field, yet this is not visible in the object on
> the client, this will force you to have an API like
>          public Parent saveParent(Parent p);
> so you have access (via the return value) to the updated object, which
> is not really nice, because if you forget to use it, you'll be in trouble.
>
> b) even worse: Looking at the only child Bert: if you update it on the
> client, e.g. rename it to "Ernie" (c.setName("Ernie")) this will have no
> effect at all, since the object returned by saveParent() will have to no
> link to the child object on the client. So you basically have to do
> something like:
>         p.getChildren().getAt(0).setName("Ernie");
>
> Of course it is possible to use an API like the one I just outlined, yet
>  I am pretty sure that it will result in lots of errors.
>
> Any input is appreciated,
> regards,
> Tom
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
> For additional commands, e-mail: user-help@struts.apache.org
>
>

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org

Re: [OT] Remoting question

[Emmanouil Batsis <Em...@eurodyn.com>]

Tom Ziemer wrote:

>a) If you send p to the server, your persistence layer will save it for
>you and update the id-field, yet this is not visible in the object on
>the client, this will force you to have an API like
>	 public Parent saveParent(Parent p);
>  
>

or

public Long saveParent(Parent p);

which will return only the generated ID back to feed your POJO's setter.

>b) even worse: Looking at the only child Bert: if you update it on the
>client, e.g. rename it to "Ernie" (c.setName("Ernie")) this will have no
>effect at all, since the object returned by saveParent() will have to no
>link to the child object on the client. So you basically have to do
>something like:
>	p.getChildren().getAt(0).setName("Ernie");
>  
>

The usual situation is that you either:

* save the child in it's own context and get back it's identifier as 
suggested above for Parent
* use an assigned identifier for the child
* save the object graph using cascades but in a shoot and forget manner.

hth,

Manos

---------------------------------------------------------------------
To unsubscribe, e-mail: user-unsubscribe@struts.apache.org
For additional commands, e-mail: user-help@struts.apache.org