Angelo,
On 6/9/2012 5:08 AM, Angelo zerr wrote:
<stuff delted>
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. And even more welcome to
contribute as well. 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).
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).
Scott
[A]http://wiki.eclipse.org/Remote_Services_Admin See Remote Service
Admin Discovery
[B] http://wiki.eclipse.org/ECF/Asynchronous_Remote_Services
So IMHO there are three key added values
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.
Regards Angelo
Scott
[1] http://www.restlet.org
[2] http://en.wikipedia.org/wiki/Java_API_for_RESTful_Web_Services#JAX-RS_2.0
[3] http://wiki.eclipse.org/ECF#OSGi_Remote_Services
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
s not to speak about cxf dosgi. I'm really sorry that I have not
explained that very well-(
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
|