Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ecf-dev] OSGI Remote Services And Whiteboard Pattern

Hi Scott,

Thanks again for this informative answer. I'd be very glad if you can direct me to the available resources that I should examine in order to learn how to use the pub/sub mechanism of ECF. I read about the distributed event admin, should I check out its implementation?

I am now planning to develop some test projects for my application, implementing a distributed OSGI RS, and a pub/sub method. Then I will compare both of the solutions, perhaps merge if possible.

Regards
Muammer




On Wed, May 7, 2014 at 5:55 PM, Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
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



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


Back to the top