Skip to main content
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] OSGI Remote Services And Whiteboard Pattern
Hi Muammer,

On 5/6/2014 4:37 AM, Muammer Eroğlu wrote:
Hello,

I've just registered to the this mailing list, and I would like to ask something about a crucial problem I faced using ECF. I hope it won't be an out of place question.

I have a desktop application built on top of OSGI bundles and does internal communication with local OSGI services. I'd like to migrate this to a server-client architecture, by putting some of the bundles to the server side, some others to the client side. After doing some research, using ECF and OSGI Remote Services looked like the ideal path, with minimal modification to the original code.

In my application, I'm using the whiteboard pattern for two way communication between bundles. That is, both the service and listener are registered to the service registry. In order to apply this idea to the OSGI Remote Services, which mechanism should I use, and how? As a second thought, is it not a good idea to use whiteboard pattern for Remote Services, and should I revert back to good-old bean type listeners?

IMHO this is a very good question. 

The OSGi whiteboard pattern...a very useful pattern IMHO...has some complexities WRT remote services...and I think these complexities bear some discussion.  First, for those interested in background on the whiteboard pattern please see [1].

One complexity is remote service discovery.  Unlike local OSGi services...where reliable discovery is guaranteed...remote service discovery is 'best effort'.   Further, what's actually meant by 'best effort' is up to the discovery implementation.   For example, 'best effort' for zeroconf is multicast over a LAN...meaning that only services on the same lan (without some extra configuration) will be able to discover each other's services.   But in some circumstances and/or network environments 'best effort' can mean 'not completely reliable'...even if the implementation used is functioning properly.

Another complexity is distributed consensus.   Consider the following:

Three frameworks:   A, B, C
Service:   Service, WhiteboardService.   Assume A is host for Service and consumer of all MyWhiteboardService instances, B and C are hosts for MyWhiteboardService and consumers of Service.

Now...in a local OSGi service registry, the registration of Service and WhiteboardService instances is synchronous...meaning that the discovery of these services by consumers is both timely (immediate) and reliable.   But in the remote services case, the discovery is *not* immediate (because of interprocess communication delay)...and this means that there can be disagreements (at runtime) between A, B, C...on which services...or their proxies...are actually 'present' in the local service registry.   Such disagreements are not due to a programming error in the application logic, or a programming error in the discovery or distribution systems for remote services.  They can occur without any bugs at all simply because in OSGi Remote Services the service instances (host or proxy...and their meta-data) are replicated among multiple processes [2].  And those replications can get out of sync because of (e.g.) clients coming and going, discovery not being totally reliable, etc.

I don't want to talk about this if it's not useful for people...and I'm not sure if this is useful...so I'll stop there.    FWIW...I would *not* conclude that one can't do the whiteboard pattern with remote services...indeed one certainly can (Markus and Wim have created an example app that does this, and it works absolutely fine).   But I think it's suitability has to do at least partially with

a) the remote service use case needs (wrt reliability, dynamics, timing)
b) selections (and/or custom creation) of discovery and/or distribution providers that carefully match the use case needs in terms of capabilities...e.g. LAN vs. WAN, failure properties of remote service hosts/consumers, failure detection/group membership of distribution providers.

Also...just to be clear...the above RS complexities are not ECF-implementation-specific...rather they apply to any implementation of RS/RSA.   IMHO what this implies is that further enhancements can/probably should be made to RS/RSA specification...e.g. to better support the whiteboard pattern specifically (e.g. add some notion of 'group membership' for a dynamic set of participating frameworks).   As a member of the OSGi Enterprise Experts Group I am working in these directions.

Hope this helps.  I would be happy to have others comment...so please do so.

Thanks,

Scott

[1] http://www.osgi.org/wiki/uploads/Links/whiteboard.pdf
[2] Obviously not replicated for all OSGi services, but rather replicated for the subset remote services


I'm using zeroconf and ECF generic providers for now.

Thanks in advance,
Muammer








_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev

Back to the top