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

[Muammer Eroğlu <muammer.eroglu@xxxxxxxxx>]

Thanks a lot Scott for your elaborate answer.

It is absolutely true that the dynamic nature of remote services should be considered very carefully, and appropriate measures should be taken. However, IMHO, I think that we also have similar problems with the local OSGI services, perhaps in a smaller scale. That is to say, the local services could also be lazy at initialization, or might be removed from the registry soon after. OSGI experts were always warning about this dynamism, that the service consumer should always be ready for not finding the desired service. Whiteboard pattern is a solution for this, since we are not explicitly keeping listener references, but relying on the registry.

I checked the ChatServer/Client example app for the usage of Whiteboard pattern with remote services. Thanks to Markus and Wim, it is a good example indeed. They applied the idea that all of the clients distribute their listener services, thus, effectively creating a distributed environment. However, for this type of solution, role separation for server and client becomes blurry, leading problems such as the one Markus pointed out in his bug submission.

As a beginner in this field, I'd like you to excuse me if these following questions/theories sound too illogical. Here they are:

- Is it possible for the clients to register their listener services on the server? This way, the server wouldn't have to do any discovery, and keep on the server role. Then again, server should know which listener comes from which machine. This also sounds like a PUB/SUB mechanism.

- If this is too unlikely, is there any way to combine OSGI RS with a PUB/SUB provider using ECF? We could use OSGI RS for server services, and PUB/SUB for listener requirements.

Regards,
Muammer

On Tue, May 6, 2014 at 7:30 PM, Markus Alexander Kuppe <ecf-dev_eclipse.org@xxxxxxxxxxx> wrote:

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

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