|
Hi Ram,
On 12/13/2016 9:33 AM, Ramachandran K. Narayanan wrote:
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
By calling importService(ed) you are testing/making the
connection. What importService does (with the ecf generic
provider) is
a) establish a connection if none exists
b) communicates with the host/server about what services are
available
c) creates and registers a proxy for the (in your case) ICore remote
service
The registration of the ICore proxy will result in any/all consumers
of the ICore service having access to the proxy. This will work
with any/all normal mechanisms for consuming a local OSGi
service...e.g. ServiceTracker and DS. Note that the ICore proxy
should usually be considered dynamic (in DS sense), since it can 'go
away' at any time (e.g. the connection gets broken).
There is a fair amount that occurs 'under the RSA covers', of
course, and ECF's impl of RSA allows one to (e.g.) hook into the a,
b, c above if necessary, but if importService returns a valid
ImportRegistration (no exception) then the a, b, c above was
accomplished successfully.
and should I necessarily inject via DS?
It's not at all a requirement, no. The ICore proxy created by
RSA/ECF 'looks' just like a local instance of the ICore service
(there are some differences, of course, and the consumer can get
information about and respond to those differences if desired). But
as per the Remote Services spec, the ICore proxy is a full local
instance of the ICore service...it just so happens that the method
calls occur remotely.
In RSCore, does the bindCore function test the connection?
Effectively it does, since by the proxy being injected via
RSCore.bindCore(ICore core) the a, b, c above was accomplished and
the ICore proxy is ready to use.
Also, I find that when I'm testing a new remote service, I'll put
test code directly in the bind method...e.g. to make sure that an
actual remote call using the service can be made.
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.
It's only necessary that the ImportRegistration (or it's
ImportReference) be stored if you want to explicitly unregister the
remote service via ImportRegistration.close(). If you don't
need/want to close it yourself (or rather have your user initiate
the close) then it's not really necessary to hold onto the
ImportRegistration or it's contents.
ImportRegistration/ImportReference are specified in RSA and are
intentionally very similar to the OSGi
ServiceRegistration/ServiceReference structure.
There's also meta-data in the ImportReference, but again it's not
required that you care about that. As per spec, the RSA impl holds
onto these for you.
Hopefully this helps. If not, please LMK.
Scott
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 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
_______________________________________________
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
|
