| Re: [ecf-dev] My first steap with ECF with Restlet |
|
Angelo, On 6/9/2012 5:08 AM, Angelo zerr wrote: <stuff delted>
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).
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
|