[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] OSGI Remote Services And Whiteboard Pattern
|
On 5/7/2014 10:21 AM, Markus Alexander Kuppe wrote:
On 07.05.2014 16:55, Scott Lewis wrote:
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.
Hi Scott,
can you say more about this use case?
Sure. It's just been running through my mind, but the idea is this:
What if an discovery provider (i.e. implementing the ECF discovery API)
was implemented that used the same ECF container instance that was also
being used by the distribution provider. This would provide a single
group context for both discovery and distribution....i.e. some set of
group members would be either present in the group or not. Further the
group membership would be known...as is guaranteed by the shared object API.
I haven't yet convinced myself that this would provide enough
benefits...for the whiteboard use case and/or others...to spend the
effort to implement...but I'm thinking about it. It would provide some
stronger guarantees of reliability for discovery...via the failure
detection, but like I said I'm thinking it through.
Right now, it sounds similar to
better failure detection for the shared object provider(s).
The failure detection for the shared object providers is ultimately
dependent upon the reliability of the supporting transport...e.g.
server-based tcp connection (hub and spoke topology) can provide
stronger failure detection than, say multicast. But the idea above
is essentially to use the failure detection from the shared object API
to implement the discovery API. The layering implied is:
Discovery API (and Remote Services API and Distributed
EventAdmin...which already exist as shared objects)
SharedObject API
transport (ECF generic tcp/ssl, JMS, JavaGroups, MQTT, etc)
Another thing that the shared context would provide would be an
association between the discovery metadata (edef) communication, and the
remote services/distribution provider communication (i.e. the actual
marshalling, remote call and response of remote service method calls).
If one process failed/left the group, all group members would 'know'
about this...via failure detection.
Again, I'm currentl just thinking about the utility of it...but you
asked :).
Scott
M.
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
