Join the DZone community and get the full member experience.
Join For FreeECF 3.2 contains an implementation of the new OSGi 4.2 remote services standard. This release is coming out later this week (Feb 19). One
thing that developers may discover when building and testing
distributed applications is that synchronous remote procedure call
(RPC) can have surprising behaviors. In my view, this is because we
reflexively understand that normal/local/in memory method call is
synchronous and fast...i.e. that the calling thread blocks until the
method is complete (and optionally a result is returned), OR the method
fails/throws an exception in languages that have structured exception
handling.
So at best the remote call's I/O behavior will lead to large performance variability (i.e. the remote call will be orders of magnitude slower...and variable based upon network performance), and at worst the caller thread could hang/block indefinitely. This violates our expectations about method invocation.
To address this problem, frequently asynchronous remote method call and/or non-blocking messaging is used...so that the caller can be guaranteed that the calling thread will not block. Note that depending upon the application requirements and expectations, it may be fine that synchronous/blocking RPC is used. OTOH, it may be very important that remote services not block...for user experience, and or overall system performance expectations. It depends upon the use case...and I don't believe there is any one, right answer for all situations.
ECF's implementation of the OSGi 4.2 remote services spec has support for asynchronous remote method call. This support is exposed via our IRemoteService contract, which is made available to remote service consumers (for example code, see tutorial here). This contract exposes two mechanisms for making asynchronous remote method calls
So at best the remote call's I/O behavior will lead to large performance variability (i.e. the remote call will be orders of magnitude slower...and variable based upon network performance), and at worst the caller thread could hang/block indefinitely. This violates our expectations about method invocation.
To address this problem, frequently asynchronous remote method call and/or non-blocking messaging is used...so that the caller can be guaranteed that the calling thread will not block. Note that depending upon the application requirements and expectations, it may be fine that synchronous/blocking RPC is used. OTOH, it may be very important that remote services not block...for user experience, and or overall system performance expectations. It depends upon the use case...and I don't believe there is any one, right answer for all situations.
ECF's implementation of the OSGi 4.2 remote services spec has support for asynchronous remote method call. This support is exposed via our IRemoteService contract, which is made available to remote service consumers (for example code, see tutorial here). This contract exposes two mechanisms for making asynchronous remote method calls
- Asynchronous callback (aka listener) via IRemoteService.callAsync/2
- Futures via IRemoteService.callAsync/1
The
IRemoteService reference associated with a remote service proxy is
accessible via any/all ECF remote services. If not needed, however,
it's completely invisible and so doesn't impose any complexity burden.
Currently,
the OSGi 4.2 remote services spec does not articulate any methods for
asynchronously accessing a remote service, but my understanding is that
this is an area for future standardization.
Topics:
Opinions expressed by DZone contributors are their own.
Comments