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