| Re: [ecf-dev] OSGI Remote Services And Whiteboard Pattern |
Hi Muammer,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.
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.
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).
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 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.In a word: yes...it is quite possible to combine OSGi RS with pub/sub (in the form of distributed event admin or not).
- 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.
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
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev