Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [ice-dev] Enabling ConnectCoreAction

Hello Scott,

I am trying to verify the connection to the remote core, i.e. ensure it is valid and I think I would need help with testing the connection.

1) Currently, the connection is through the EDEF file. How would I test the connection and should I necessarily inject via DS? In RSCore, does the bindCore function test the connection?

2) Also, my ConnectCoreHandler.execute() returns null, similar to other handler classes. I assume that the client would need to store a reference to the Core object to which it is discovering via EDEF. Would I get it through reg.getImportedService().getImportReference()? Here, reg is the ImportRegistration object.

Thanks,
Ram




On Mon, Dec 12, 2016 at 4:43 PM Ramachandran K. Narayanan <knarayanan@xxxxxxxxxxxxx> wrote:
Hello Scott,

Thanks a lot for taking a look. After including the distribution bundle, I get no error. I will look at using the imported ICore interface so I can verify its usage and understand the changes proposed in the structure as well.

Thanks,
Ram



On Mon, Dec 12, 2016 at 4:10 PM Scott Lewis <slewis@xxxxxxxxxxxxx> wrote:
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
--
Ramachandran K. Narayanan
(Ram)
Software Engineer
RNET Technologies Inc.
240 W.Elmwood Drive, Suite 2010
Dayton, OH 45459-4248
--
Ramachandran K. Narayanan
(Ram)
Software Engineer
RNET Technologies Inc.
240 W.Elmwood Drive, Suite 2010
Dayton, OH 45459-4248

Back to the top