Re: [ecf-dev] OSGI Remote Services And Whiteboard Pattern

[Markus Alexander Kuppe <ecf-dev_eclipse.org@xxxxxxxxxxx>]

On 06.05.2014 18:12, Scott Lewis wrote:
> 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.

Hi,

you might also be interested in bug #423703 [1].

M.

[1] https://bugs.eclipse.org/423703