| ECF as replacement for RMI [message #597237] |
Tue, 31 January 2006 18:20  |
Eclipse User |
|
|
|
Originally posted by: amit_aka_2000.yahoo.com
Hi ,
We use extensive RMI based communication in our project and also socket
based ( publish - subscribe ) . Since being a real time system, the RMI
behaviour of hanging the VM while in a call is not so desirable for us. We
would like to shift to pure message based communication which can be used
even as a replacement of RMI calls.
Could you let me know if this has been tried before by someone using ECF ?
I understand one of the goals of the ECF is to provide communication
framework for remote service invokation also.
Also as i went through the documents available for evaluation of ECF , i
missed a concept paper on ECF which might describe the semantics of ECF(
for e.g. on ISharedObject .. what is represent ? why is it added as a
remote shared object on the remote container ??) . Could you please point
me to such a paper ?
Best Regards,
Amit
|
|
|
| Re: ECF as replacement for RMI [message #597242 is a reply to message #597237] |
Tue, 31 January 2006 19:49  |
 Scott Lewis
Messages: 1038
Registered: July 2009 |
Senior Member |
|
|
Hi Amit,
Amit Agrawal wrote:
> Hi ,
>
> We use extensive RMI based communication in our project and also socket
> based ( publish - subscribe ) . Since being a real time system, the RMI
> behaviour of hanging the VM while in a call is not so desirable for us.
> We would like to shift to pure message based communication which can be
> used even as a replacement of RMI calls. Could you let me know if this
> has been tried before by someone using ECF ? I understand one of the
> goals of the ECF is to provide communication framework for remote
> service invokation also.
It depends upon what you mean/need WRT your app-level behavior. If you
wish to replace RMI's blocking method calls with non-blocking multipiont
event delivery (and optionally subsequent method invocation on the
receiver) then ECF-based messaging is a very good fit. From your
sentence above "Since being a real-time system..." I would guess that
this you do want to move away from blocking calls and toward
asynchronous messaging.
If your app has implicit or explicit dependencies on blocking calls
(e.g. built-in reliability assumptions) then you can use ECF shared
object messaging to transactionally send messages/create shared object
to 1 or more remotes. See, for example,
org.eclipse.ecf.core.sharedobject.TransactionSharedObject and
If you would like to have your existing code send messages and wait for
responses (RPC built on asynch messaging) you can implement this on the
primitives for transactional messaging above (because the primitives for
transactional messaging work for 1+ receivers instead of just 1 receiver
as in RPC). We may be adding such primitives as well in the near future
(on new datashare API), but haven't yet been able to get to this. It
would be a nice addition, though, for those interested in undertaking this.
>
> Also as i went through the documents available for evaluation of ECF , i
> missed a concept paper on ECF which might describe the semantics of ECF(
> for e.g. on ISharedObject .. what is represent ?
The short answer: Anything with replicated state and/or code. That is,
any model that can/must be replicated among multiple participants to
implement the application's distributed behavior. Examples are editor
contents, files, EMF models, browser contents, etc., etc.
Unfortunately we don't yet have a paper on ECF at this level (to few
hours), but there is some info on the shared object model at:
http://www.eclipse.org/ecf/sharedobjectcontainerdocumentatio n.html
Also, please consider attending my tutorial at EclipseCon...and/or
offering to help with documentation creation.
why is it added as a
> remote shared object on the remote container ??) . Could you please
> point me to such a paper ?
For the time being, the above, this
http://www.eclipse.org/ecf/documentation.html
and source are what's available. I would definately encourage using the
source also (as it's completely available to you/everyone).
Thanks,
Scott
>
> Best Regards,
> Amit
>
|
|
|
Powered by
FUDForum. Page generated in 0.02380 seconds
] 
Search
Help
Register
Login
Home
