[
Date Prev][
Date Next][
Thread Prev][
Thread Next][
Date Index][
Thread Index]
[
List Home]
|
Re: [equinox-dev] Re: [GSoC] Restlet integration with Equinox
|
Hi Jerome,
Thanks kindly for the summary...it's excellent.
My main follow-up question about '1' is: given Equinox/OSGi as it
exists now and the Restlet API/framework as it exists now...what is
actually left to do to realize/complete 1?
That is, as I understand it (and please forgive and correct if I'm
wrong), the Restlet framework is essentially a set of java classes,
distributed as a jar library, that depends upon the servlet API
(presumably there are Restlet classes that implement Servlet and/or
extend HttpServlet) and therefore is intended to run in the context of a
servlet container (e.g. Jetty).
If this is right, then I can think of a couple of things that
would/could be part of 1: e.g.
a) 'bundlizing' the Restlet API ...i.e. doing to the Restlet API what
the Orbit project does with other (e.g. Apache, etc) java-based
libraries...i.e. turning them into OSGi bundles
b) changing the Restlet use of the servlet API to use the OSGi
HttpService (for dynamic creation/removal of servlets within an OSGi
runtime)
Is this a correct interpretation of what work on '1' would actually
consist of? Or are there additional things that I'm not
getting/understanding?
If these are the main things, then I would see the accomplishment of
these things (i.e. 1) as a prerequisite/aid to accomplishing 2. Just
for context...to accomplish '2' what is required is the creation of ECF
remote service provider bundle(s). This provider would use the Restlet
API to support registering (making available) a Restlet-based remote
service (as you say in your summary...implementing the OSGI remote
services specification...via a Restlet-enabled http server). I think
it's a happy situation, though, that to create such an ECF remote
services provider, it's going to be helpful to do 1a and 1b...in fact
doing those two things (1a and 1b) will make creating such a provider
rather easy...as we have now a fair amount of support for implementing
either rest-based and/or non-rest-based remote service providers.
Further, given the way ECF's impl of OSGi remote services works, such a
provider would immediately and without further work be fully OSGi spec
compliant. This is true because ECF's impl of OSGi remote services spec
can use *any/all* providers that implement the abstract ECF remote
services API (in org.eclipse.ecf.remoteservice bundle). So any/all
Restlet-based providers would be fully OSGi-spec compliant simply by
implementing the ECF remote services API).
But I would like to verify or disconfirm my interpretation of '1' as
consisting of 'a' and 'b' above...as it may not be right. Are there
other things there that I'm not understanding?
Thanks,
Scott
Jerome Louvel wrote:
Hi all,
Sorry for the late reply, I'm on vaccations... well sort of :)
Let me try to summarize the situation. It seems to me that we have two
starting points:
1) The Restlet community which has expressed a recurrent need for OSGi
in order to offer a more dynamic Restlet runtime. This project was
summarized over time on this wiki page:
http://wiki.restlet.org/developers/172-restlet/124-restlet.html
2) The ECF community which sees the value of Restlet as a way to
implement and support the "remote declarative OSGi services" features.
This project was summarized recently on this wiki page:
http://wiki.restlet.org/developers/172-restlet/350-restlet.html
The goal of 1) is to leverage all/most features of the Restlet
Framework (Restlet API + engine + extensions) and, in addition, to
leverage OSGi/Equinox core features to bring support for dynamic
Restlet applications deployment/replacement and versionning.
The goal of 2) is to leverage all/most features of OSGi (Core +
declarative remote services) and, in addition, to leverage the Restlet
Framework to provide better REST coverage on the server-side (and
maybe on the client-side as well).
It is important to note that the Restlet API has its own containment
model, with concepts of component, connector, virtual host,
application and resource as illustrated here:
http://wiki.restlet.org/docs_2.0/13-restlet/21-restlet/318-restlet/321-restlet.html
From 1) point of view, it wouldn't be acceptable for the Restlet
community to be constrained to systematically use OSGi declarative
remote services API to build their dynamic Restlet applications.
However, many users would love to leverage some core OSGi/Equinox
features to add more dynamicity to their Restlet applications -> First
GSoC project proposition.
From 2) point of view, it wouldn't be acceptable for the Equinox/ECF
community to be constrained to systematically use the Restlet API to
build or consume RESTful web services either. However, some users
might like to leverage some Restlet advanced features (like content
negotiation, conditional method processing, rich Java API mapping to
HTTP semantics, etc.) in their distributed OSGi applications -> Second
GSoc project proposition.
Regarding Jetty, it can be used with Restlet in two ways. First, as a
regular Servlet container as pointed out by Scott, or as a standalone
Restlet connector (bypassing the Servlet layers) to directly use the
Restlet layers, providing a lighter solution. Note that while Restlet
applications can be deployed into Servlet containers if needed, many
users prefer standalone deployment of Restlet applications in Restlet
components, using Restlet connectors (such as Jetty).
I hope this helped to clarified :)
Best regards,
Jerome
PS: I've put in copy the various persons interested in this
Equinox/Restlet GSoC project(s) as I'm not sure how many follow this
list. Sorry for any duplicate email.
Le 29/03/2010 19:33, Scott Lewis a écrit :
Hi Jerome,
Jerome Louvel wrote:
Hi Scott, Rajeev and all,
Thanks for your interest Rajeev in this GSoC project.
Scott, it seems that the integration of Restlet with ECF could give
you with fully-featured server-side REST support. This would also be a
nice use case for the GSoC "Restlet integration with Equinox" project.
I agree.
I've recently created a wiki page for this project. Maybe we could
propose another GSoC project for this specific topic?
"ECF integration"
http://wiki.restlet.org/developers/172-restlet/350-restlet.html
I think that would be a great idea. One point of
information/interest...there are already several ECF committers and
contributors that would probably also be interested in this 'second
step'...i.e. of using Restlet API on Equinox/OSGi server to implement an
ECF remote services host provider. Actually, Bryan Hunt is one such ECF
contributor, and he may be interested in this sort of use case as well.
Thanks,
Scott
_______________________________________________
equinox-dev mailing list
equinox-dev@xxxxxxxxxxx
https://dev.eclipse.org/mailman/listinfo/equinox-dev
