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

[Eike Stepper <stepper@xxxxxxxxxx>]

Anders,

Comments below...



Anders Forsell schrieb:
> Eike,
>
> I am not sure if I made myself clear on the problem I am trying to solve.
> With "server" I really mean another CDO client connected to the same 
> model repository.
Ah, I really mis-understood that!

> Assuming that the two clients are looking at the same model version 
> from the repository, the result of a command operating on the state 
> would then be the same for the two clients. 
Hmm, I'm not sure if this is generally true. I could imagine it, if 
*all* of the following pre-conditions are true:

1) Neither of the two clients uses a transaction that is dirty at the 
time of the command execution.
2) The command does not rely on side effects in a particular VM.
3) All results of possible model modifications *in* the command are only 
needed/used after a commit operation.

> The reason I want another client to perform the operation is that the 
> first client is "thin" and has much less computing power than the 
> other (I was referring the client with more computing power as 
> "server", but let's call it the "fat" CDO client instead).
If these clients are thin in the sense of a web browser, have you 
already considered to use CDO only in the web container? You could embed 
the repository and multiple CDO client facilities (sessions, 
transactions, ...) into such containers...

> The result of the command would, in addition to a success/failure 
> return value, be reflected in a change of state that would be 
> committed to the CDO repository and then eventually to the thin client 
> when it updates the model revision. A failure of the command would 
> typically leave the state unchaged (rollback of the transaction).
>
> With some preassumptions, such as the two clients need to look at the 
> same model version, I think this is doable and I would like to 
> prototype it.
I think it's feasible. Have you already had a look at the Net4j way to 
communicate with the server? Since with CDO you have already a Net4j 
connection (ITCPConnector?) it would be easy to provide an additional 
application protocol that is multiplexed through a separate IChannel of 
the same connection...

> Back to the question in my original post, which needs to be 
> implemented for the prototype:
> - Can I use the CDOID from the thin client to transfer to the "fat" 
> client so that it can lookup the same object? If not, I guess I can 
> using EMF URI Fragments I can resolve it?
I think both approaches should work. I suggest to wrap the streams 
you're using to serialize the CDOIDs (and other things) into a 
CDODataOutput and -Input. See 
org.eclipse.emf.internal.cdo.protocol.CDOClientRequest.requesting(ExtendedDataOutputStream) 
for an example. Then you can just call stream.readCDOID() or 
stream.writeCDOID.

I hope this gets you one step further. Let me know if you need more info ;-)

Cheers
/Eike

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


> Thanks for your help,
>
> ---
> Anders
>
> "Eike Stepper" <stepper@xxxxxxxxxx> skrev i meddelandet 
> news:ggqte3$917$1@xxxxxxxxxxxxxxxxxxxx
> > 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