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
|