[news.eclipse.technology.ecf] Re: [CDO] [ECF] Invoking EMF operations re

[Eike Stepper <stepper@xxxxxxxxxx>]

Anders,

I'm sorry to say that the whole story about operation invocation of 
remote objects in CDO is associated with a bunch of technical and 
conceptual problems:

1) Usually you implement the logic (bodies) of such operations by adding 
hand-written code to the generated Java classes of your model concepts. 
At the CDO client side, where your models are deployed, there is no easy 
way to replace that code by the RMI code (marshalling, sending, 
receiving, unmarshalling).

2) While problem 1) is about symmetry of the deployed model code, this 
point might be a shock for you. CDO does not have EMF at the server 
side. Well, you could add it to your server installation, but CDO works 
differently. EObjects are nice for clients to deal with because of their 
standardized and flexible API. But they are hard to serialize in 
isolation, garbage-collect in isolation and so on. That's why CDO 
converts from EObject between CDORevision at the highest client side 
layer (CDOView). Starting below this layer (CDOSession, network, 
repository, backend) we only have CDORevisions and these focus on the 
data aspects of the model, not the business logic, i.e. they don't have 
the concept of CDOOperations.

3) Imagine: At the time you might be calling a local method stub which 
causes a remote invocation of some associated logic, the dirty objects 
you're locally calling the ethod on are not yet on the server side! They 
are transfered to the server at the very end of a transaction (commit) 
to the server. So how would you define the state of the object graph 
which the remote call should operate on?

4) What about side effects of remote logic in the context of a failing 
transaction?

5) Question: Would you agree that from a functional point of view there 
is nearly no difference between remotely invoking a method or doing it 
locally? It seems more related with non-functional aspects like 
scalability and security, right?

There might even be more concerns. Just in case we are able to solve all 
these technical and conceptual issues, I would suggest to use Net4j as a 
transport medium for mashalled parameters and return values, since it is 
being used for "normal" CDO transport anyway. But I'm seeing this hint 
as hypothetical at least. What do you think?

Cheers
/Eike

----
http://thegordian.blogspot.com







Anders Forsell schrieb:
> Hello,
>
> I am trying to figure out a solution for invoking an operation on a 
> remote EObject in a client-server fashion.
> I am using CDO to connect the client and server to the same model, 
> then I would like the implementation of an EObject operation on the 
> client side to call the corresponding EObject operation but on the 
> server side.
> My current idea is to use ECF remote services for the remote 
> invocation. What I need to do from the client implementation is to 
> send a request to the server to publish a remote service that will 
> expose the correct EObject. Then I fetch the remote service from the 
> client and invoke the operation asynchronously or synchronously using 
> the features of ECF R-OSGi.
>
> How do I uniquely identify the CDO object from the client so that the 
> server side can load it? Can I use the CDOID? I can assume that the 
> client and server is looking at the latest version of the same model.
>
> Has anyone a better idea for doing this?
>
> Thanks,
>
> ---
> Anders