Re: [ice-dev] Enabling ConnectCoreAction

[Scott Lewis <slewis@xxxxxxxxxxxxx>]

On 12/12/2016 12:18 PM, Billings, Jay Jay wrote:

​Scott, Ram,

To follow up on point 1 below, I agree that the current structure is not ideal. We'll have to change it and I'm looking at some related refactoring over the holiday. With respect to point 2 below, ideally a user would have a collection of clients, one of which is local. The idea here is that there will always be some base capability provided by the local client, but vendors - like RNET - may provide custom servers that the local client can connect to for more services.

Hi Jay,

Yeah...I understand.   One way to structure this would be to have one or more Core impls that can be used for local usage and/or remote usage, exported only on the server, and then allow consumers to know about/use multiple ICore instances (some local, some remote).   With remote services this is no problem at all...for example I know of an existing ECF commercial consumer that has an 'offline' client, where the service is locally provided, but allows 'online' instances where the service instance is an RSA-imported proxy.

For support of this...there are OSGi-specified service properties that allows service consumers to distinguish between 'regular' OSGi services and remote services.   Using DS Reference target, for example, will allow you to determine at injection time whether any/all the ICore service instances is 'regular' or 'remote'.  Specifically, any remote service has this service property set to non-null:   service.imported.

I'll be happy to help with any of this as needed.   IMHO a lot of the benefit of remote services is being able to use the OSGi dynamics support, versioning, service interface contract/impl + distribution separation that comes from OSGi services.

Scott