Highlights
- Implementation of OSGi 4.2 Remote Services standard
- Support for REST providers
- Support for SOAP providers
- Remote Services Examples and Docs and recent blogging about the tech for this release
Friday, February 19, 2010
ECF 3.2 Now Available
ECF 3.2 is now available here. The emphasis/theme for this release is support for Service-Oriented Architecture (SOA), specifically through support of the OSGi 4.2 Remote Services standard.
Highlights
Highlights
Tuesday, February 16, 2010
OSGi Remote Services and Sync vs. Async
ECF 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
The IRemoteService reference associated with a remote service proxy is accessible via any/all ECF remote services. If not needed, however, it's 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.
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
- Asynchronous callback 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 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.
Thursday, February 04, 2010
Goodness through OSGi Standards
ECF recently announced full support for OSGi 4.2's remote services standard with our upcoming 3.2 release.
Today, I learned that a community member has successfully used Spring dm, along with ECF's remote services implementation to do declaratively-specified remote services. They have agreed to contribute the example to ECF, and so expect to see it as part of ECF soon.
People have also used ECF remote services with OSGi declarative services.
And, of course, one can use remote services programmatically as well.
Among other things, this allows a wide variety of existing tooling to be used to construct, use, and debug remote services...all made possible by having an open standard for distributing an OSGi service.
Today, I learned that a community member has successfully used Spring dm, along with ECF's remote services implementation to do declaratively-specified remote services. They have agreed to contribute the example to ECF, and so expect to see it as part of ECF soon.
People have also used ECF remote services with OSGi declarative services.
And, of course, one can use remote services programmatically as well.
Among other things, this allows a wide variety of existing tooling to be used to construct, use, and debug remote services...all made possible by having an open standard for distributing an OSGi service.
Subscribe to:
Posts (Atom)