[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?



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:

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:

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:

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,

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"

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.



equinox-dev mailing list