[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [ecf-dev] A general question around REST
|
I started playing with Bryan's bundles; it seems that the minimum
execution environment is set to 1.6; is that a requirement for this to
work?
I doubt that EE of 1.6 is really required...but I'm not sure...this
probably has to be answered by Bryan directly. Please bring it up as a
comment on the ECF enhancement [1] also and we'll use that bug to track.
(I'm not sure how the bug tracking is handled for that project currently).
Thanks,
Scott
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=339442
My environment needs to be 1.5 so that would be a show stopper for me.
I will try to modify that and run that to see if it fails anywhere...
Thanks,
Ali.
On 3/9/2011 4:47 PM, Scott Lewis wrote:
Hi Ali,
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?
I've just had casual emails with Bryan about some ideas for how the
Restlet+OSGi bridge could be enhanced to support the creation of OSGi
remote services (using ECF's impl). I've opened a new enhancement
request [1] specifically for this integration. I think that Bryan,
I, and any others that are interested...like Ali...but of course
anyone who's interested can (and hopefully will) participate and
contribute...should use this bug to discuss what
changes/generalizations are needed...and where...and discuss how to
get any desired/necessary changes in place in the relevant part of
things (i.e. Restlet, OSGi/Restlet integration, ECF REST API, remote
services, etc). I think we should also use this bug to get clarity
on use cases...and desired API...so if people have thoughts here
please join [1]. Hopefully Bryan will join the bug and we can have
a technical discussion there about the things we've discussed in
private (Bryan fwiw...feel free to post my emails to the bug comments
if you decide/prefer).
Looking forward to seeing the mixed scenario working,
Me too. It's going to take some cooperative effort in several areas
(e.g. Bryan, me/other ECF contributors/committers, perhaps
Restlet/Jerome), but actually I don't think it will actually take
very much...because most of the pieces here are in place, and working
just fine in their respective domains (e.g. REST/Restlet servers,
OSGi remote services, etc).
Thanks(inadvance) for your interest and participation. :)
Scott
[1] https://bugs.eclipse.org/bugs/show_bug.cgi?id=339442
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
