Home » Archived » Eclipse Communications Framework (ECF) » [CDO] [ECF] Invoking EMF operations remotely (client - server)
|
| Re: [CDO] [ECF] Invoking EMF operations remotely (client - server) [message #624436 is a reply to message #624435] |
Sat, 29 November 2008 08:10   |
|
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
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| Re: [CDO] [ECF] Invoking EMF operations remotely (client - server) [message #624437 is a reply to message #624436] |
Sat, 29 November 2008 09:22 |
 Anders Forsell
Messages: 127
Registered: July 2009 |
Senior Member |
|
|
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.
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. 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).
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.
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?
Thanks for your help,
---
Anders
"Eike Stepper" <stepper@esc-net.de> skrev i meddelandet
news:ggqte3$917$1@build.eclipse.org...
> 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
|
|
|
| Re: [CDO] [ECF] Invoking EMF operations remotely (client - server) [message #624438 is a reply to message #624437] |
Sat, 29 November 2008 10:14 |
|
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.reque sting(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@esc-net.de> skrev i meddelandet
> news:ggqte3$917$1@build.eclipse.org...
>> 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
>
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
| |
  |
Goto Forum:
Current Time: Thu Apr 25 20:49:05 GMT 2024
Powered by FUDForum. Page generated in 0.03456 seconds |
] 
Search
Help
Register
Login
Home
