[
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/7/2014 2:13 AM, Muammer Eroğlu wrote:
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.
Yeah. In my view the underlying problems here are timing...as well as
likelihood of partial failure...and so they are possible in local OSGi
services. Just much more likely in the distributed case...because of
network-imposed delays and failure-cases.
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.
The answer is yes...it is possible for clients to register their
listener services on a server...in the case of a pub/sub group (aka topic).
The ECF generic, JMS, MQTT, JavaGroups providers all have this
pub/sub/group capability. This is used to implement our distributed
event admin [1]...which is an early attempt to use/reuse the OSGi
EventAdmin service to represent access to a pub/sub group. But it does
use the ECF shared object API (implemented by the providers above) to
provide access to pub/sub communication patterns...with group membership
mgmt/failure detection. We also have an async channel API (called
datashare) that exposes named messaging channels.
The way that RS, EventAdmin, and datashare are implemented...for the ECF
generic, JMS, etc providers...is as instances of shared objects. My main
reason for bringing this up here is to point out that this allows them
both to co-exist within a single distributed pub/sub group (aka ECF
'container'). This makes it quite natural for them to provide both RS
and pub/sub functionality within a single runtime group context.
- 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.
In a word: yes...it is quite possible to combine OSGi RS with pub/sub
(in the form of distributed event admin or not).
Just to be clear about this...all of this ECF functionality (pub/sub,
event admin, shared object api) is currently 'extra spec'...i.e. not
part of OSGi R5 (or R6 for that matter). It's indeed an important part
of ECF...and has been all along...as the genesis of the project (at
least my involvement) was/is based upon pub/sub/group messaging patterns.
For me, one thought that this discussion has triggered is that it might
ultimately be useful to create/introduce a discovery provider that's
implemented via the shared object API. One thing this could provide
would be to provide reliable discovery *within the context of a
particular pub/sub/distributed group*. This might provide some value for
the general whiteboard use case.
But just to sum up: yes...it's is quite possible (even natural) to use
ECF's pub/sub APIs and mechanisms...along with RS. I sort of expect this
to be an area for future OSGi specification...because as you say the
OSGi whiteboard pattern is a very useful pattern. But currently, this is
where specification/standardization currently falls somewhat short, IMHO.
I'm happy to provide technical details about ECF's pub/sub nature as
desired...I just wanted to make the separation clear in this
discussion...between what ECF's functionality can provide, and what the
OSGi RS/RSA specification currently standardizes.
Thanks,
Scott
[1] https://wiki.eclipse.org/Distributed_EventAdmin_Service
