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
_______________________________________________
ice-dev mailing list
ice-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe from this list, visit
https://dev.eclipse.org/mailman/listinfo/ice-dev