[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] A general question around REST
|
Hi Scott.
Many thanks, as usual, for your detailed and valuable response. Yes,
indeed the mixed scenario that you described would be the ideal
situation for me. You had mentioned you were looking into that; are you
planning to wait for the final changes on Bryan's side to happen first?
Looking forward to seeing the mixed scenario working,
Thanks again,
Ali.
On 3/9/2011 4:10 PM, Scott Lewis wrote:
Hello Ali,
A brief/summary explanation: ECF's REST support currently allows
REST-based services to be easily exposed to OSGi clients as OSGi
remote services.
A brief example: Twitter has a REST-based service, that...that uses
json for serialization (of both parameters and return value). Using
ECF's remote services (and the REST client support that extends this
remote services API), it's possible to create a OSGi service (i.e.
defined by a java interface), that exposes part (or all) of the
twitter REST API as an OSGi remote service. There's a code example
in the tests here [1] (this code example is not currently working
because of a change in the Twitter authentication mechanism...that we
have not been able to adjust for yet...my apologies about that).
The creation of OSGi remote services for REST-based services is quite
easy and flexible...there are more excellent code examples of doing
this here [2]. These examples are by Pavel Samolisov.
To summarize: ECF's REST support is currently focused on allowing
people to easily create providers to expose REST-based services (of
whatever kind/implementation) as OSGi remote services. It does *not*
currently define a server-side API for exposing REST-based services
(i.e. defining the server-side of a REST-based service).
This is where the Restlet work, and the Restlet+OSGi work (for
REST-based services) described by Bryan...come in. Restlet and the
work pointed to by Bryan allow one to easily define/expose a Restlet
service (in OSGi or not). Such a service is a servlet, registered
with the OSGi HttpService dynamically by Bryan's Restlet+OSGi
integration code. Once a service is registered, it can be accessed by
whatever client is desired...e.g. a web browser, some client written
in javascript, a client written in java, or an OSGi client written in
java.
Now...I've recently been looking into the feasibility of doing the
following: Given Restlet, and Bryan's Restlet+OSGi work, and the ECF
REST API, and ECF's impl of OSGi remote services it would be very easy
to have a Restlet Application/Router...that was defined by the
programmer for a given service, and used by Bryan's Restlet+OSGi
work...be automatically exposed as *both* a 'normal' REST service
(accessible from browser as well as clients), *and* an OSGi remote
service (with a java interface defining the service contract, and a
*system-created proxy* that implements the actual remote method
invocation via the REST-based calls. For your use case (if I
understand it correctly), this would be valuable, because it would
allow all variety of clients...e.g. browser, clients in other
languages...*and* with the ECF REST remote services it would
allow/support all nice things about OSGi services...e.g. using
ServiceTrackers, using declarative services...as well as all the nice
things about ECF's impl of OSGi remote services and now remote
services admin (e.g. the control/management of the remote service
export and import process, load balancing use cases, enterprise
topology managers, security, service interface versioning, etc., etc).
The stuff described in the above paragraph may seem like a lot...but
with the pieces that already exist (Restlet, OSGi+Restlet integration,
ECF REST API, ECF impl of OSGi remote services/RSA...it's really not
very much...because it's just integrating the various APIs on the REST
server as well as the REST client. I've been in recent communication
with Bryan about doing exactly this...i.e. using the pieces listed
together on an OSGi server (and OSGi clients as well) to expose (via
Restlet+OSGi) a REST-based service to *both* 'normal' clients, as well
as exposing the *same* service (really the same server/service
code...in fact with one service registration) as an OSGi remote
service proxy....using all the same proxy dynamic proxy creation code.
Now...Bryan's work is just getting hardened (is my understanding), and
I think there may have to be some small additions to his work to allow
for the ECF/OSGi remote service export (where...according to the RSA
spec...the remote service host exports an EndpointDescription that has
an 'endpoint id'...e.g. http://myhost.com/path/to/rest-based/service.
But I don't believe that it will be anything very large/significant
to get everything working together.
So given your use case involves exposing REST-based services as both
'normal' http requests/responses as well as OSGi services, I think
that the tecnology mix described above seems like a good fit.
Does this make sense? If not, please let me know where it doesn't and
I will attempt to be clearer.
Scott
P.S. One other comment: Because of the way that the ECF REST-based
client support is written, it's also quite possible (I would say easy)
to create clients for remote services that use SOAP+http for exposing
a remote service. There are examples of doing this here [2] as well.
Further, part of ECF 3.5 is the creation by Pavel of an XML-RPC
provider as well XML-RPC-exposed services into OSGi service clients.
The point being that the ECF REST-based client support is written in
a way that allows the marshalling (i.e. serialization of parameters
and return values) to be easily customized (to json, xml, soap, or
whatever), and the http request/response protocol to easily be
customized as well. I'm not saying this API is perfect yet...and
it's possible it could use some generalization, but so far it's been
able to do a number of things (at least as exemplified by [2]).
[1
]http://git.eclipse.org/c/ecf/org.eclipse.ecf.git/tree/tests/bundles/org.eclipse.ecf.tests.remoteservice.rest/src/org/eclipse/ecf/tests/remoteservice/rest/twitter/TwitterRemoteServiceTest.java
[2] https://github.com/ECF/ECF-Examples
Hi Ali,
I've not looked into how the ECF REST support works, but I can offer
you an interesting solution based on Restlet here:
http://code.google.com/a/eclipselabs.org/p/restlet-integration-with-equinox/
This solution allows you to have your REST services all coded in OSGi
(even supports hot-plug) and any generic HTTP client. I'm sure Scott
will give you a good answer on the ECF end.
Bryan
On Mar 9, 2011, at 1:28 PM, Ali Naddaf wrote:
Hello everyone.
I understand that ECF has a REST provider support. My question is
whether the following use case is covered by ECF, in general, or I
need to look for a different solution: I have a an (Equinox based)
OSGi environment and I would like to for my services (provided by
bundles that I have in my environment) be also exposed externally as
REST web services. So far, I was using something similar to what
Peter had written (webrpc) that would expose public services with
almost no extra work as some sort of rpc calls over http. Anyhow,
for a general consumption of my OSGi services as REST web services
by any external client (i.e. not just another OSGi environment), is
the ECF still a correct solution?
Many thanks,
Ali.
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
_______________________________________________
ecf-dev mailing list
ecf-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/ecf-dev
