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

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



Back to the top