Many thank's to have token time to explain me how it works. Today I would like to launch the org.eclipse.ecf.examples.remoteservice.restlet.hello.consumer, but for me it doesn't work-( (osgi container starts the bundles but nothing is displayed on the console).
I have setted breakpoints in the method which add the service in the HelloConsumerApplication, but it is never called-(
So my problem comes from "a) Creates a local proxy for the remote service", and I'm searching where is the code which computes the base URL of the Rest server to consume it (on other words http://localhost:8080/hello ).
I would like just tell you my first impression that I have had
with ecf+restlet and tell you what I don't like (like extend
ServerResource in the service impl) to try to improve
ecf+restlet (perhaps me, if I can?)
Sure...of course you are welcome to give any impressions and/or
desires about what you would like.
cool:)
And even more welcome to
contribute as well.
sure
I would be interested in why ServerResource
isn't/can't for your use case (it's not the only way to use
Restlet...is my understanding from the Restlet folks...but it's
quite general and very easy for many use cases).
If you can read my articles it should be cool, because you will see what I want to do. But as I know you have not time, I will try to explain here what I want to do. I think my services to expose with remoting is a little complex but I have done that with success with cxf dosgi and I would like study if it's possible with ecf restlet. Here my UserService :
--------------------------------------------------------- public interface UserService { Page<User> findAll(Pageable pageable); } ---------------------------------------------------------
This service is complex because :
1) It uses complex type in the method parameter (Pageable) and result method (Page) 2) Page and Pageable are interfaces and not Pojo. 3) Page and Pageable belongs to "Spring Data" framework, so you cannot modify it (to add some annotations or extend some classes).
I must study restlet to see if it's possible. With JAX-RS+JAXB it's possible.
My goal is to have several configuration with my eclipser cp application:
1) Fat client: this confuguration means that rcp client consumes directly the implementation of the UserService retrieved from the OSGi registry services. As you can see here this implementation needs not to extend ServerResource (very shame to add in this config reslet bundles)
2) Client/Server: this config means that rcp client consumes the rest client which consumes the rest server (here the impl of Userviceisnot hosted with rcp but in other OSGi container (server side)
So for 1), I would like avoid extending ServerResource in my impl off UserService.
With CXF DOSGi you must just annotate the Uservice interface and that's all.As it's annotations you can import jax-rs packages in the Services API bundles and set it as optionnal. So for Fat client config, you need NOT add jax-rs bundle.
Here a list of features that remoting must support (supported by cxf dosgi with jax-rs) :
1) more transparent like use only annotations (avoid developping some other classes). 2) support complex object in the param of the sevice (not only String but pojo).
3) support interface(eg: Page, Pageable) in the param of service. 4) configure the baseURL of the server on client side (eg: you deploy the host side in a server A and B, you can configure the base URL of server A to use it)
I think it should be very cool if ecf support JAX-RS (with cxf, jersey, etc?).
Hope you will understand my need.
Regards Angelo
For the moment I don't undestand howto the consumer
org.eclipse.ecf.examples.remoteservice.restlet.hello.consumer
works? Where is declared the server URL?
Here's a bit of an explanation. What happens is that through the
discovery mechanism, the server URL...and other meta-data about the
remote services...is communicated to the consumer process. When a
remote service is discovered, the ECF RSA implementation
a) Creates a local proxy for the remote service (in this case the
service interface is IHelloResource...that's the OSGi service
interface)
b) Registers a local (consumer-side) OSGi service
When b is done (all 'under the covers' of the Remote Service Admin),
any clients that are using i) service trackers; ii) declarative
services...etc...will be notified about the IHelloResource remote
service...and can then use the normal OSGi mechanisms for getting
the IHelloResource instance...and then calling the given methods.
The cool thing about the Restlet provider...IMHO...is that behind
the IHelloResource proxy is all of the appropriate Restlet code for
doing the 'get' or 'put' or whatever is declared in the annotations
on IHelloResource. This makes it completely unnecessary for any
client/consumer-side Restlet code to be created at all...the ECF RSA
impl and the Restlet provider creates the proxy (taking into account
version information for IHelloResource...if there is any), and
simply makes the proxy available in the consumers OSGi service
registry (as described above).
The ServiceTracker for the IHelloResource on the consumer side is in
org.eclipse.ecf.examples.internal.remoteservice.restlet.hello.consumer.HelloConsumerApplication.
You can see there that all it's doing is getting any IHelloResource
services registered and calling the methods ('sayHello' in this
case).
IMHO there are several things about OSGi remote services (and RSA)
that create added value over the jax-rs/Restlet impl alone:
1) The remote service discovery is done automatically and in a
standardized (RSA) meta-data format. RSA specification defines
something called an EndpointDescription [A]. ECF's discovery API is
used here...and allows us and others to use a variety of discovery
protocols (e.g. file-based discovery, zookeeper, zeroconf, dnssd,
slp, others). In other words...discovery of the remote service
'just happens'...if that's what you want.
2) The RSA impl (along with the ECF Reslet-based provider) creates
and registers the proxy for you...as described above. This may not
sound like a lot, but it's actually fairly challenging to do
correctly in an OSGi environment...because of OSGi's modular,
multi-classloader structure, as well as the support for versioning.
What I mean by 'support for versioning' is...lets say you have more
than one version of IHelloResource that your server/servers make
available via ECF Restlet provider. If you've specified the version
information in the server's manifest...for the bundle that contains
the IHelloResource package, then this version information will be
communicated (in a standard way) to the consumer, and the ECF RSA
impl will create a proxy of the approriate/correct version (or
refuse to create the proxy...if not of the same version). I know
this sounds somewhat esoteric, but when it comes to handling
versioning in distributed systems (a common problem)...I think it's
quite unique.
3) Because of 2, the consumer/client doesn't have to worry about
writing any code to consume/use a service. All it has to do is get
a locally-registered IHelloResource and start calling it's methods.
Compared to other rest-based approaches, that's seems pretty easy to
me (and it allows both code based...e.g. ServiceTracker...and/or
declarative...e.g. ds and/or Spring) approaches to getting and using
the service.
4) ECF's impl has built-in support for asynchronous (non-blocking)
access to the remote service (e.g. sayHello() without
blocking)...via the asynchronous proxy [B]. This is not
standardized...but rather is unique to ECF...because currently OSGi
has no specification for asynchronous access to OSGi services.
5) If OSGi is not used on the consumer (e.g. _javascript_ clients,
etc) then they won't have the discovery, proxy creation, versioning,
etc...but they can still use the appropriate http 'get' calls
directly (in whatever manner they wish)...and the server will
respond to those calls as well. In the end...after all...it's just
an http service and so can be accessed via web browser, _javascript_,
other langs, etc.
Hopefully this helps. I intend to do further work on both the
Restlet examples and the Restlet provider (partially because now the
OSGi integration work done by Bryan Hunt some time ago is now a part
of Restlet itself...making it easier to deploy/install the necessary
parts of the ECF Restlet provider).
When I start the launch "Restlet Hello Consumer.launch",
there is nothing displayed on my console. Could you please
explain how it works please?
Many thank's
WRT using JAX-RS annotation feel free to see [1] as another
instance of an JAX-RS implementation. Note also several
other implementations listed at [2].
ECF's focus is the modular implementation of OSGi remote
services [3]...with a variety of underlying distribution
systems is desired (..i.e. providers: Rest, SOAP, r-OSGI...or
*any* other protocol). It would be possible, even, to create
an ECF distribution/remote services provider from CXF.
Yes I understood the goal of ECF. I would like written some
articles about ECF+Restlet (like I have done with CXF DOSGi),
but before I must understand how it works.
Many thank's for your help.
