Home » Modeling » EMF » Question on using CDO to implement distributes telemetry capability.
| Question on using CDO to implement distributes telemetry capability. [message #422310] |
Fri, 29 August 2008 13:20  |
 Pierre
Messages: 3
Registered: July 2009 |
Junior Member |
|
|
Hi all,
I am currently experimenting with CDO to see if we could use it to
access and monitor an EMF model of a mobile robot from multiple clients
over a network.
The robot (and all of its sensors) are modeled using EMF. Jobs are
created for the robot and sensors to collect the telemetry using low
level drivers, and the model's values are then updated using these
values. Other systems (i.e. autonomy engines, guidance, etc) registers
as adapters to the robot and sensors EObject in order to be notified
when values are modified and respond accordingly.
In the current setup, the robot, sensors, and other systems are all
running in a single Eclipse application resident on the robot. While
this work, it is not flexible.
Now we want to be able to run some of the systems in a distributed
fashion (for example, having the robot model accessible from a operator
station for data display and control). For all the systems to continue
to work properly in this distributed environment, we would need the
following:
a) Have access to all getter and setters of distributed object in a
"transparent" fashion on the client side.
b) Being notified of changes in the same way Adapter do in a
non-distributes EMF model;
c) Being able to invoke methods on the "local proxy" and have these
methods called on the object on the server (akin to RMI);
It is important to note that we do not need to have the "store"
capability for most of our systems.
In this context, I have the following questions:
1) I have tried to use the "noop" option (to tries to gain performance)
in the cdo-server.xml without success. Using the default model editor
that come with CDO, I get the following exception when I attempt to save
a model:
[ERROR] UnsupportedOperationException
java.lang.UnsupportedOperationException
at
org.eclipse.emf.cdo.internal.server.StoreAccessor.writeFeatu re(StoreAccessor.java:190)
at
org.eclipse.emf.cdo.internal.server.StoreAccessor.writeClass (StoreAccessor.java:179)
at
org.eclipse.emf.cdo.internal.server.StoreAccessor.writePacka ge(StoreAccessor.java:166)
at
org.eclipse.emf.cdo.internal.server.StoreAccessor.writePacka ges(StoreAccessor.java:158)
at
org.eclipse.emf.cdo.internal.server.StoreAccessor.commit(Sto reAccessor.java:113)
at
org.eclipse.emf.cdo.internal.server.Transaction.commit(Trans action.java:181)
at
org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:109 )
at
org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:46)
at org.eclipse.net4j.signal.Signal.runSync(Signal.java:143)
at org.eclipse.net4j.signal.Signal.run(Signal.java:124)
at
java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:885)
at
java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:907)
at java.lang.Thread.run(Thread.java:619)
What am I doing wrong ? Is it possible to run a CDO server without a
"database" support ?
2) I creates two views that access a model managed by a CDO server : One
that updates a few attributes in the model every second, the other that
register an Adapter to the model and prints the Notification received.
While I was expecting a standard EMF Notification on the client side, I
received a CDOInvalidationNotification that do not seem to contain
information about was has changed. However, reading the attributes of
the object returns the updated value. I assume this is the result of a
"lazy" implementation of the getter on the server side (talk to the
server only when the value is requested on the client side). In any
case, is there a way to force the server to "push" new values to the
client or to somewhat have the client side generate EMF type
notification when then server side object is modified ?
Thanks in adavance,
Pierre.
|
|
|
| Re: Question on using CDO to implement distributes telemetry capability. [message #422323 is a reply to message #422310] |
Fri, 29 August 2008 16:20  |
|
Hi Pierre,
Sounds as if you have a very interesting application!
If your robots are capable of doing my housework I'd like to volunteer
as an early adopter ;-)
More comments inline...
Pierre Allard schrieb:
> Hi all,
>
> I am currently experimenting with CDO to see if we could use it to
> access and monitor an EMF model of a mobile robot from multiple
> clients over a network.
>
> The robot (and all of its sensors) are modeled using EMF. Jobs are
> created for the robot and sensors to collect the telemetry using low
> level drivers, and the model's values are then updated using these
> values. Other systems (i.e. autonomy engines, guidance, etc) registers
> as adapters to the robot and sensors EObject in order to be notified
> when values are modified and respond accordingly.
>
> In the current setup, the robot, sensors, and other systems are all
> running in a single Eclipse application resident on the robot. While
> this work, it is not flexible.
>
> Now we want to be able to run some of the systems in a distributed
> fashion (for example, having the robot model accessible from a
> operator station for data display and control). For all the systems to
> continue to work properly in this distributed environment, we would
> need the following:
>
> a) Have access to all getter and setters of distributed object in a
> "transparent" fashion on the client side.
Yes, completely possible, if not even the main purpose.
>
> b) Being notified of changes in the same way Adapter do in a
> non-distributes EMF model;
Was always possible but with a recent addition even simpler and more
EMF'ish:
233490: Change Subscription
https://bugs.eclipse.org/bugs/show_bug.cgi?id=233490
>
> c) Being able to invoke methods on the "local proxy" and have these
> methods called on the object on the server (akin to RMI);
This can turn out top be a problem since on the server side there is no
EMF, particularly no generated custom Java code.
CDO focusses on data handling (i.e. distribution and persistence) not on
distributed processing.
That said, the underlying Net4j signalling platform could be used
directly to add such capabilities.
>
> It is important to note that we do not need to have the "store"
> capability for most of our systems.
>
>
>
> In this context, I have the following questions:
>
> 1) I have tried to use the "noop" option (to tries to gain
> performance) in the cdo-server.xml without success. Using the default
> model editor that come with CDO, I get the following exception when I
> attempt to save a model:
>
> [ERROR] UnsupportedOperationException
> java.lang.UnsupportedOperationException
> at
> org.eclipse.emf.cdo.internal.server.StoreAccessor.writeFeatu re(StoreAccessor.java:190)
>
> at
> org.eclipse.emf.cdo.internal.server.StoreAccessor.writeClass (StoreAccessor.java:179)
>
> at
> org.eclipse.emf.cdo.internal.server.StoreAccessor.writePacka ge(StoreAccessor.java:166)
>
> at
> org.eclipse.emf.cdo.internal.server.StoreAccessor.writePacka ges(StoreAccessor.java:158)
>
> at
> org.eclipse.emf.cdo.internal.server.StoreAccessor.commit(Sto reAccessor.java:113)
>
> at
> org.eclipse.emf.cdo.internal.server.Transaction.commit(Trans action.java:181)
>
> at
> org.eclipse.emf.cdo.internal.server.protocol.CommitTransacti onIndication.indicating(CommitTransactionIndication.java:109 )
>
> at
> org.eclipse.net4j.signal.IndicationWithResponse.execute(Indi cationWithResponse.java:46)
>
> at org.eclipse.net4j.signal.Signal.runSync(Signal.java:143)
> at org.eclipse.net4j.signal.Signal.run(Signal.java:124)
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.runTask(Threa dPoolExecutor.java:885)
>
> at
> java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoo lExecutor.java:907)
>
> at java.lang.Thread.run(Thread.java:619)
>
>
> What am I doing wrong ? Is it possible to run a CDO server without a
> "database" support ?
Yes, I recommend to try the MEMStore instead of the NOOPStore.
The latter was only a non-functional stub to make the compiler happy
during the inital design phase.
>
>
> 2) I creates two views that access a model managed by a CDO server :
> One that updates a few attributes in the model every second, the other
> that register an Adapter to the model and prints the Notification
> received. While I was expecting a standard EMF Notification on the
> client side, I received a CDOInvalidationNotification that do not seem
> to contain information about was has changed. However, reading the
> attributes of the object returns the updated value. I assume this is
> the result of a "lazy" implementation of the getter on the server side
> (talk to the server only when the value is requested on the client
> side). In any case, is there a way to force the server to "push" new
> values to the client or to somewhat have the client side generate EMF
> type notification when then server side object is modified ?
You're right with your interpretation.
And yes, with the Change Subscription this is now possible, too.
Cheers
/Eike
>
> Thanks in adavance,
>
> Pierre.
Cheers
/Eike
----
http://www.esc-net.de
http://thegordian.blogspot.com
http://twitter.com/eikestepper
|
|
|
Goto Forum:
Current Time: Tue Apr 23 15:19:53 GMT 2024
Powered by FUDForum. Page generated in 0.02826 seconds |
] 
Search
Help
Register
Login
Home
