[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] Exposing an osgi service as remote service vi ecf.rest.client provider
|
Hi Atanas,
On 6/29/2011 8:43 AM, Атанас Тодоров wrote:
Hi All,
I want to use ecf.rest.client provider for transport communication.
I was able to convert an osgi service as a restlet and expose it as an
osgi remote service using
http://code.google.com/a/eclipselabs.org/p/restlet-integration-with-equinox/
project.
This sounds great! Have you used the latest iteration of that code?
Would you be willing to consider contributing a new provider...based
upon a) restlet; b) the restlet integration; c) the rest API, d) you
work? It would be quite nice...I think... to have a remote services
provider that leverages a, b, c, d to expose as an OSGi remote service
(and therefore could easily and automatically use the OSGi RSA standard,
as well as any of the ECF discovery providers...which implement the OSG
RSA endpoint description discovery).
I do not explicitly set "service.exported.interfaces" and
"service.exported.configs" properties.Is there any need to set these
as it is described in the iwiki.?
The answer to this question depends upon the following statement (and
the answer to my follow up question).
With the ECF api i was able to create a remote call and then take the
result back.
So which ECF api are you referring to? If you are referring to the ECF
remote services API (i.e. in org.eclipse.ecf.remoteservices.* packages),
then the answer to the above question is 'no'. If you are referring to
the ECF implementation of the OSGi remote services API, then then answer
to the above question is 'yes'.
The reason for this is that the OSGI remote services API is layered on
top of the ECF impl of OSGi remote services. A simple diagram looks like
this:
OSGi remote services API (registerService with
service.exported.interfaces service property set)
| (impl in org.eclipse.ecf.osgi.remoteserviceadmin and
org.eclipse.ecf.osgi.services.distribution)
V
ECF Remote Services API
|
V
ECF Remote Service *provider* (e.g. r-osgi...impl)
There's a more extensive explanation and graphic presenting this
structure on this page:
http://wiki.eclipse.org/OSGi_4.2_Remote_Services_and_ECF
So if you are using the ECF Remote Services API *directly* (which you
certainly can do), then it skips the functionality provided by the OSGi
remote services implementation...having to do with interacting with the
local OSGi service registry.
If, OTOH, you are using the OSGi registerService call with the standard
service properties set, then you should not have to call the ECF remote
services API directly (it's done for you by the RSA implementation), and
you should also be able to interact with the remote service proxy as if
it's a local/OSGi service.
However,
I exected that remote service be transparent or what i mean is : be
able to see it in the client osgi environment as thought it is local
service.
I also expected when running the host osgi with the bundle containng
the exposed remote service to see 2 instances of that service as it is
for r-osgi.
In the ECF 'BasicTopologyManager' (which is in class:
org.eclipse.ecf.internal.osgi.services.distribution.BasicTopologyManager),
there is an option to allow or disallow loopback references (that's
whether to allow a proxy to a remote service that is also in the service
registry of the *same framework*). By default, this is set to
'false'...which means that the proxy is *not* allowed/created in the
same framework as the service host.
You can easily change this, however, by setting this system property:
org.eclipse.ecf.osgi.services.discovery.allowLoopbackReference
e.g.
eclipse -vmargs
-Dorg.eclipse.ecf.osgi.services.discovery.allowLoopbackReference=true
We do this in the automated tests for remote services...so that the host
and consumer parts of the remote service tests can be run within the
same framework.
Note that the BasicTopologyManager is not intended to be the 'only'
topology manager...and in fact the RSA spec and ECF's implementation
allows the creation of other topology managers. I've been thinking about
what kinds of improvements and generalizations the BasicTopologyManager
could have (e.g. instead of system properties for configuration is could
have programmatic API, or declarative services, or xml, or configuration
admin, or extensions/extension points, etc). And...there
can/could/should be more/other topology managers to use for different
environments (e.g. server, clients, of different types, etc).
I will be very grateful for any comments for any of my questions.
Hopefully this is helpful. If you would like to discuss with me the
contribution of some of the work to the ECF project and community,
please contact me directly at slewis at composent.com. We would be most
welcoming of the contribution!!
Thanks,
Scott
