RE: Re: Evaluating Restlet - few questions

[Adam Mc]

Jerome,

As always, thanks for your response.

>> [1] The Jetty connector is production ready and much lighter than a full 
>> Servlet container.

Great. I have noticed that Restlet runs pretty light, at least compared to 
tomcat (not much experience with Jetty servlet container).  But, the very small 
heap stack I was seeing the RF+Jetty connector was motivation enough for me to 
switch to RF for the time being.  


>> [2] It is still a work in progress. Not sure to get this ready for RF 2.2 at 
>> this point. We need help on the documentation front mostly as most of the 
>> code has already been upgraded to the OAuth 2.0 final RFC.

Sounds really good. In the future I may want to get involved in helping 
documenting Restlet.  There were a few hicups I encountered when making the 
transition from a servlet rest system. More complete docs should help this.


>> [3] Yes, it is possible using the callback mechanism. See this method:
http://restlet.org/l​earn/javadocs/snapsh​ot/jee/api/org/restl​et/resource/ClientRe​source.html#setOnRes​ponse(org.restlet.Un​iform)

This looks great!  Did not seem much in the docs or user guide for this.  When 
things calm down, I will take a look at it and see if I can piece together a 
tutorial.

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=3054176

Re: Evaluating Restlet - few questions

[Jerome Louvel]

Hi Adam,

Thanks for reaching us and your interest in Restlet :)

[1] The Jetty connector is production ready and much lighter than a full
Servlet container.

[2] It is still a work in progress. Not sure to get this ready for RF 2.2
at this point. We need help on the documentation front mostly as most of
the code has already been upgraded to the OAuth 2.0 final RFC.

[3] Yes, it is possible using the callback mechanism. See this method:
http://restlet.org/learn/javadocs/snapshot/jee/api/org/restlet/resource/ClientResource.html#setOnResponse(org.restlet.Uniform)

Best regards,
Jerome
--
http://restlet.org
http://twitter.com/#!/jlouvel




2013/4/8 Adam Mc 

> This is my fist message on the restlet discussion.  First, I just want to
> say thanks to the developers of Restlet.  It seems like a great api and
> framework.  We are evaluating Restlet, and we have a few general questions.
>  I apologize  if the questions are a bit diverse, but I thought I would
> just send them in one message.
>
> [1]  Jetty Connector vs Servlet Container:  We would like to use the Jetty
> connector  as a standalone outside of a servlet container.  Is Restlet
> standalone with Jetty as stable as using a servlet, or is a servlet
> container preferred for production?
>
> [2] The book mentions that Oauth 2.0 is in draft.  Is Oauth 2.0 nearing
> production code?  Not rushing, just wondering?
>
> [3]  Is there any way to handle Ascynhrous Client requests.  Considering
> that our webserver is also a client to other servers, the client needs to
> consume other restful services.  Is there anyway to consume services in a
> non blocking or ascyh manner, so as to not keep the threads blocking.  If
> so, can someone point me into the direction of code example.
>
> Thanks,
>
> -Adam
>
> --
>
> http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=3052727
>

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=3054131

Evaluating Restlet - few questions

[Adam Mc]

This is my fist message on the restlet discussion.  First, I just want to say 
thanks to the developers of Restlet.  It seems like a great api and framework.  
We are evaluating Restlet, and we have a few general questions.  I apologize  
if the questions are a bit diverse, but I thought I would just send them in one 
message.

[1]  Jetty Connector vs Servlet Container:  We would like to use the Jetty 
connector  as a standalone outside of a servlet container.  Is Restlet 
standalone with Jetty as stable as using a servlet, or is a servlet container 
preferred for production?

[2] The book mentions that Oauth 2.0 is in draft.  Is Oauth 2.0 nearing 
production code?  Not rushing, just wondering?

[3]  Is there any way to handle Ascynhrous Client requests.  Considering that 
our webserver is also a client to other servers, the client needs to consume 
other restful services.  Is there anyway to consume services in a non blocking 
or ascyh manner, so as to not keep the threads blocking.  If so, can someone 
point me into the direction of code example.

Thanks,

-Adam

--
http://restlet.tigris.org/ds/viewMessage.do?dsForumId=4447&dsMessageId=3052727

RE: Evaluating Restlet

[Jerome Louvel]

Hi all,

Ok, let's keep track of this task. I've entered:

"Check synchronization needs for lazy inits"
http://restlet.tigris.org/issues/show_bug.cgi?id=480

Best regards,
Jerome  

> -Message d'origine-
> De : Kevin Conaway [mailto:[EMAIL PROTECTED] 
> Envoyé : samedi 5 avril 2008 23:19
> À : discuss@restlet.tigris.org
> Objet : Re: Evaluating Restlet
> 
> A lot of the lazy initializations seem to be basic 
> Collections.  I don't know of many cases where there is a 
> truly expensive object that is lazy initialized.
> 
> In my use cases, Request and Response objects do not have 
> long lifecycles so carrying around a final, empty Collection 
> here and there might be worth it in relation to possible 
> concurrency issues
> 
> 
> On Sat, Apr 5, 2008 at 12:23 PM, Tim Peierls <[EMAIL PROTECTED]> wrote:
> 
> 
>   On Sat, Apr 5, 2008 at 5:07 AM, Jerome Louvel 
> <[EMAIL PROTECTED]> wrote:
>   
> 
>   Thanks for the suggestion about the safe 
> double-check idiom, very cool. As
>   Request/Response have many optional property 
> and as those are very
>   frequently created objects, I think we should 
> ready try to keep lazy
>   initialization in place.
> 
> 
>   OK. At some point it would be great to do some 
> profiling with and without lazy init to see what effect the 
> extra object creation has.
>   
>   Uh-oh, that probably sounded like volunteering ... 
> maybe I better retract that comment! :-)
>   
>
>   
> 
>   However, I don't see cases where the 
> Request/Response objects (and dependent
>   objects) would be access by multiple threads 
> *at the same time*, only by
>   different threads at different times if we do 
> async handling or async NIO
>   writing.
>   
>   Could that assumption save us some additional 
> synchronization work?
>   
> 
> 
>   No. As long as there is a window in which one thread 
> can observe the field with a null value before another thread 
> initializes the field, there is a bug. It might be highly 
> unlikely to cause trouble in practice, but that just makes 
> the bug harder to detect when it finally does trigger.
>   
>   The complexity of the double-check lazy init idiom is 
> daunting (to me, anyway), but you're not obliged to use 
> volatiles. Simple synchronization works, too:
>   
>   @GuardedBy("this") private FieldType field;
>   
>   public synchronized FieldType getField() {
>   if (field == null) 
>   field = initialFieldValue();
>   return field;
>   }
>   
>   @GuardedBy("this") means that *all* access to the field 
> is performed in a synchronized (this) {} block (or a 
> synchronized method). This might be slightly slower than 
> using volatile on some platform/hardware combinations, but 
> it's the *only* way to go if you have a class invariant that 
> involves multiple non-final fields. As I said, I haven't 
> looked hard to see if that is the case with Request, Response, etc.
>   
>   --tim
>   
> 
> 
> 

Re: Evaluating Restlet

[Kevin Conaway]

A lot of the lazy initializations seem to be basic Collections.  I don't
know of many cases where there is a truly expensive object that is lazy
initialized.

In my use cases, Request and Response objects do not have long lifecycles so
carrying around a final, empty Collection here and there might be worth it
in relation to possible concurrency issues

On Sat, Apr 5, 2008 at 12:23 PM, Tim Peierls <[EMAIL PROTECTED]> wrote:

> On Sat, Apr 5, 2008 at 5:07 AM, Jerome Louvel <[EMAIL PROTECTED]> wrote:
>
> > Thanks for the suggestion about the safe double-check idiom, very cool.
> > As
> > Request/Response have many optional property and as those are very
> > frequently created objects, I think we should ready try to keep lazy
> > initialization in place.
>
>
> OK. At some point it would be great to do some profiling with and without
> lazy init to see what effect the extra object creation has.
>
> Uh-oh, that probably sounded like volunteering ... maybe I better retract
> that comment! :-)
>
>
>
> > However, I don't see cases where the Request/Response objects (and
> > dependent
> > objects) would be access by multiple threads *at the same time*, only by
> > different threads at different times if we do async handling or async
> > NIO
> > writing.
> >
> > Could that assumption save us some additional synchronization work?
> >
>
> No. As long as there is a window in which one thread can observe the field
> with a null value before another thread initializes the field, there is a
> bug. It might be highly unlikely to cause trouble in practice, but that just
> makes the bug harder to detect when it finally does trigger.
>
> The complexity of the double-check lazy init idiom is daunting (to me,
> anyway), but you're not obliged to use volatiles. Simple synchronization
> works, too:
>
> @GuardedBy("this") private FieldType field;
>
> public synchronized FieldType getField() {
> if (field == null)
> field = initialFieldValue();
> return field;
> }
>
> @GuardedBy("this") means that *all* access to the field is performed in a
> synchronized (this) {} block (or a synchronized method). This might be
> slightly slower than using volatile on some platform/hardware combinations,
> but it's the *only* way to go if you have a class invariant that involves
> multiple non-final fields. As I said, I haven't looked hard to see if that
> is the case with Request, Response, etc.
>
> --tim
>

Re: Evaluating Restlet

[Tim Peierls]

On Sat, Apr 5, 2008 at 5:07 AM, Jerome Louvel <[EMAIL PROTECTED]> wrote:

> Thanks for the suggestion about the safe double-check idiom, very cool. As
> Request/Response have many optional property and as those are very
> frequently created objects, I think we should ready try to keep lazy
> initialization in place.


OK. At some point it would be great to do some profiling with and without
lazy init to see what effect the extra object creation has.

Uh-oh, that probably sounded like volunteering ... maybe I better retract
that comment! :-)



> However, I don't see cases where the Request/Response objects (and
> dependent
> objects) would be access by multiple threads *at the same time*, only by
> different threads at different times if we do async handling or async NIO
> writing.
>
> Could that assumption save us some additional synchronization work?
>

No. As long as there is a window in which one thread can observe the field
with a null value before another thread initializes the field, there is a
bug. It might be highly unlikely to cause trouble in practice, but that just
makes the bug harder to detect when it finally does trigger.

The complexity of the double-check lazy init idiom is daunting (to me,
anyway), but you're not obliged to use volatiles. Simple synchronization
works, too:

@GuardedBy("this") private FieldType field;

public synchronized FieldType getField() {
if (field == null)
field = initialFieldValue();
return field;
}

@GuardedBy("this") means that *all* access to the field is performed in a
synchronized (this) {} block (or a synchronized method). This might be
slightly slower than using volatile on some platform/hardware combinations,
but it's the *only* way to go if you have a class invariant that involves
multiple non-final fields. As I said, I haven't looked hard to see if that
is the case with Request, Response, etc.

--tim

RE: Evaluating Restlet

[Jerome Louvel]

Hi Tim,

Thanks for the suggestion about the safe double-check idiom, very cool. As
Request/Response have many optional property and as those are very
frequently created objects, I think we should ready try to keep lazy
initialization in place.

However, I don't see cases where the Request/Response objects (and dependent
objects) would be access by multiple threads *at the same time*, only by
different threads at different times if we do async handling or async NIO
writing. 

Could that assumption save us some additional synchronization work?

Best regards,
Jerome  

> -Message d'origine-
> De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la 
> part de Tim Peierls
> Envoyé : jeudi 3 avril 2008 13:55
> À : discuss@restlet.tigris.org
> Objet : Re: Evaluating Restlet
> 
> I finally took a quick look at Request and Response. The 
> thing to remember about volatiles is that there is no 
> practical way to enforce atomicity with volatiles alone. So 
> lazy initialization checks like this:
> 
> public Conditions getConditions() {
> if (this.conditions == null)
> this.conditions = new Conditions();
> return this.conditions;
> }
> 
> aren't safe. Multiple threads calling getConditions() at 
> around the same time might each get a different Conditions instance.
> 
> Adding synchronization would fix this. You can even use the 
> safe version of the double-check idiom for lazy 
> initialization of instance fields, recommended by Josh Bloch:
> 
> public Conditions getConditions() {
> Conditions c = this.conditions;
> if (c == null) {
> synchronized (this) {
> c = this.conditions;
> if (c == null)
> this.conditions = c = new Conditions();
> }
> }
> return c;
> }
> 
> Note that this pattern must be used exactly as above to be 
> worthwhile. (And the conditions field must still be volatile, 
> or you're back to the broken double-check idiom!)
> 
> Best of all would be to avoid lazy initialization entirely. 
> Are any of those initializations expensive?
> 
> But fixing or removing lazy initialization is only sufficient 
> if there are no class invariants that involve two volatile 
> fields simultaneously. I haven't looked hard enough to see if 
> that is the case. If it is, then you need to synchronize 
> access to the those fields whenever the invariant might 
> temporarily be invalidated.
> 
> --tim
> 
> 
> On Tue, Apr 1, 2008 at 3:42 AM, Jerome Louvel 
> <[EMAIL PROTECTED]> wrote:
> 
> 
>   Tim Peierls wrote:
>   
> 
>   I hate to sound like a broken record, but the 
> Restlet Request and Response classes are not thread-safe, so 
> Restlet cannot yet take *full* advantage of NIO to break out 
> of the thread-per-request paradigm. (There is movement on 
> this front, however, as Rob Heittman pointed out earlier in 
> this thread.)
>   
> 
>   I would like to mention that I've completed the work to 
> make Request, Response, Representation and all related 
> classes in API, NRE and extensions thread safe.
>   
> 
>   It was mostly a matter of adding the right modifier, 
> either 'volatile' or 'final' as there is rarely a need for 
> strong synchronization in those classes. Most of the time 
> they are accessed by one thread at a time.
>   
>   However, I wouldn't mind having expert eyes looking at 
> the result and making sure everything is ready to support 
> advanced handling, IO and threading scenarios!
>   
>   Best regards,
>   Jerome
>   
>   
> 
> 
> 

Re: Evaluating Restlet

[Tim Peierls]

I finally took a quick look at Request and Response. The thing to remember
about volatiles is that there is no practical way to enforce atomicity with
volatiles alone. So lazy initialization checks like this:

public Conditions getConditions() {
if (this.conditions == null)
this.conditions = new Conditions();
return this.conditions;
}

aren't safe. Multiple threads calling getConditions() at around the same
time might each get a different Conditions instance.

Adding synchronization would fix this. You can even use the safe version of
the double-check idiom for lazy initialization of instance fields,
recommended by Josh Bloch:

public Conditions getConditions() {
Conditions c = this.conditions;
if (c == null) {
synchronized (this) {
c = this.conditions;
if (c == null)
 this.conditions = c = new Conditions();
}
}
return c;
}

Note that this pattern must be used exactly as above to be worthwhile. (And
the conditions field must still be volatile, or you're back to the broken
double-check idiom!)

Best of all would be to avoid lazy initialization entirely. Are any of those
initializations expensive?

But fixing or removing lazy initialization is only sufficient if there are
no class invariants that involve two volatile fields simultaneously. I
haven't looked hard enough to see if that is the case. If it is, then you
need to synchronize access to the those fields whenever the invariant might
temporarily be invalidated.

--tim


On Tue, Apr 1, 2008 at 3:42 AM, Jerome Louvel <[EMAIL PROTECTED]> wrote:

> Tim Peierls wrote:
>
> > I hate to sound like a broken record, but the Restlet Request and
> > Response classes are not thread-safe, so Restlet cannot yet take *full*
> > advantage of NIO to break out of the thread-per-request paradigm. (There is
> > movement on this front, however, as Rob Heittman pointed out earlier in this
> > thread.)
> >
> I would like to mention that I've completed the work to make Request,
> Response, Representation and all related classes in API, NRE and extensions
> thread safe.
>
> It was mostly a matter of adding the right modifier, either 'volatile' or
> 'final' as there is rarely a need for strong synchronization in those
> classes. Most of the time they are accessed by one thread at a time.
>
> However, I wouldn't mind having expert eyes looking at the result and
> making sure everything is ready to support advanced handling, IO and
> threading scenarios!
>
> Best regards,
> Jerome
>
>

Re: Evaluating Restlet

[Jerome Louvel]

Hi all,

Tim Peierls wrote:
I hate to sound like a broken record, but the Restlet Request 
and Response classes are not thread-safe, so Restlet cannot 
yet take *full* advantage of NIO to break out of the 
thread-per-request paradigm. (There is movement on this 
front, however, as Rob Heittman pointed out earlier in this thread.)


I would like to mention that I've completed the work to make Request, 
Response, Representation and all related classes in API, NRE and 
extensions thread safe.


It was mostly a matter of adding the right modifier, either 'volatile' 
or 'final' as there is rarely a need for strong synchronization in those 
classes. Most of the time they are accessed by one thread at a time.


However, I wouldn't mind having expert eyes looking at the result and 
making sure everything is ready to support advanced handling, IO and 
threading scenarios!


Best regards,
Jerome

RE: Evaluating Restlet

[Jerome Louvel]

Hi Jaime,

Thanks, I've added the link as a new comment. Feel free to comment
issues/RFEs directly if you want to.

Best regards,
Jerome  

> -Message d'origine-
> De : jbarciela jbarciela [mailto:[EMAIL PROTECTED] 
> Envoyé : mercredi 6 février 2008 21:34
> À : discuss@restlet.tigris.org
> Objet : Re: Evaluating Restlet
> 
> a possible addition to that list (probably you know the link but I
> didn't see it in the list), is Tomcat 6's approach, they named the
> interface "CometProcessor"
> 
> http://tomcat.apache.org/tomcat-6.0-doc/aio.html
> 
> hope it helps
> Jaime
> 
> 
> On Feb 5, 2008 6:01 PM, Rob Heittman 
> <[EMAIL PROTECTED]> wrote:
> >
> > Exactly ...
> >
> > In my case, I'm working on Restlet API support in Google 
> Web Toolkit using
> > XmlHttpRequest as the "Client".  As this is idiomatically 
> an asynchronous
> > facility -- regardless of whether your response is short 
> lived (AJAX style)
> > or long lived (Comet style), the API needs ways of handling 
> clients that
> > behave asynchronously, which it presently lacks.  Several 
> interesting
> > connectors like Jetty have also introduced neat new 
> facilities driven by the
> > desire to make the Comet style more manageable on the 
> server side, so it's
> > not just about the client side.
> >
> > Have a look at this RFE and its references:
> > http://restlet.tigris.org/issues/show_bug.cgi?id=143   ...  
>  you guessed
> > right, it started with an observation about the Comet style.
> >
> > - Rob
> >
> >
> >
> > On 2/5/08, jbarciela jbarciela <[EMAIL PROTECTED]> wrote:
> > > When you say "callbacks", what do you have in mind? 
> Something like Comet?
> > >
> > > Cheers
> > > Jaime
> > >
> >
> >

Re: Evaluating Restlet

[jbarciela jbarciela]

a possible addition to that list (probably you know the link but I
didn't see it in the list), is Tomcat 6's approach, they named the
interface "CometProcessor"

http://tomcat.apache.org/tomcat-6.0-doc/aio.html

hope it helps
Jaime


On Feb 5, 2008 6:01 PM, Rob Heittman <[EMAIL PROTECTED]> wrote:
>
> Exactly ...
>
> In my case, I'm working on Restlet API support in Google Web Toolkit using
> XmlHttpRequest as the "Client".  As this is idiomatically an asynchronous
> facility -- regardless of whether your response is short lived (AJAX style)
> or long lived (Comet style), the API needs ways of handling clients that
> behave asynchronously, which it presently lacks.  Several interesting
> connectors like Jetty have also introduced neat new facilities driven by the
> desire to make the Comet style more manageable on the server side, so it's
> not just about the client side.
>
> Have a look at this RFE and its references:
> http://restlet.tigris.org/issues/show_bug.cgi?id=143   ...   you guessed
> right, it started with an observation about the Comet style.
>
> - Rob
>
>
>
> On 2/5/08, jbarciela jbarciela <[EMAIL PROTECTED]> wrote:
> > When you say "callbacks", what do you have in mind? Something like Comet?
> >
> > Cheers
> > Jaime
> >
>
>

Re: Evaluating Restlet

[Rob Heittman]

You are certainly NOT alone in that feeling.  There are some entertaining
flame wars about the topic (on other lists and blogs) if you search for
'em.  The approach does seem to work surprisingly well to solve certain
problems.  It also breaks badly on certain network configurations, and
places unexpectedly high loads on others.

I would say that if an application can be designed without reliance on the
Comet style, it probably should be -- for broadest compatibility and
greatest simplicity.

Still, people have brought sane use cases forward on the list -- e.g.
pushing discrete updates from sensors to an HTTP-based client over a private
network -- where the style would be a great fit, and it would be awesome if
the Restlet API were flexible enough to support it cleanly when needed.

- R


On 2/6/08, Kyrre Kristiansen <[EMAIL PROTECTED]> wrote:
>
> I know this is probably the best place for this, but
> am I the only one that thinks Comet is pushing the
> limits of HTTP too far (no pun intended)?

Re: Evaluating Restlet

[Kyrre Kristiansen]

Hello, everyone. 

I know this is probably the best place for this, but
am I the only one that thinks Comet is pushing the
limits of HTTP too far (no pun intended)? As far as I
can read from the RFC, a client may create a
long-lived connection, issue several requests, but the
server MUST respond to these requests in the order
they're sendt. I'm not trying to give the Comet crew
(that's a cool name, btw) a bad name, but I get the
feeling that doing this type of things in HTTP/1.1 is
against the constraints imposed on the protocol. I'd
absolutely love to get callback-type functionality in
HTTP, but I'm just bothered by the nagging feeling
that it should be done either as a different protocol
or a new version  of the HTTP protocol, since this
type of protocol leverage gives a new set of
challenges that should be seriously looked into. After
all, a lot of the success of HTTP is in its ability to
be simple, but extremely powerful.

Just some thoughts I had to get out somewhere...

Regards,
Kyrre

--- Rob Heittman <[EMAIL PROTECTED]> wrote:

> The thing I'm working on simply involves an
> alternative to
> handle(request,response) that allows the response to
> be delivered to a
> callback object, possibly and probably in another
> thread.  This is
> principally valuable for AJAX style code and
> critical path for the GWT
> support I'm working on.  To a certain degree, we
> actually want a model here
> that looks and feels very familiar to GWT users who
> have worked with GWT-RPC
> and would like to try a RESTful alternative.
> 
> The idea of being able to "pin" a thread is probably
> more applicable to the
> issue of a long-lived request/response cycle (e.g.
> Comet style), and
> probably more valuable across the board, but less
> critical path to what I'm
> doing.
> 
> Both of these asynchronous needs are under active
> research and development,
> and the implementation is probably interrelated
> (synchronous processing can
> probably be expressed in terms of a single callback
> which can probably be
> expressed in terms of chunked asynchronous
> processing) ... the RFE gives
> some code examples for how this might be true.
> 
> Right now I am looking at the penalties and costs of
> thread-safe Request and
> Response objects across the board, a need which must
> be sorted out before
> any of the other async stuff can be safely
> investigated.
> 
> 
> On 2/6/08, António Mota <[EMAIL PROTECTED]> wrote:
> >
> > Hmm, let me try to understand, is there a effort
> going on to include in
> > Restlet some kind of "notification" to
> asynchronous clients based on
> > xmlhhttprequest callbacks and/or Comet-style
> "push" techniques?
> >
> >
> >
> >
> > On 06/02/2008, jbarciela jbarciela
> <[EMAIL PROTECTED]> wrote:
> > >
> > > > Have a look at this RFE and its references:
> > > >
> http://restlet.tigris.org/issues/show_bug.cgi?id=143
>   ...
> > >
> > > Ah, that's a wonderful wonderful compilation of
> articles, so far I've
> > > only read about Jetty's continuations, thanks
> for the link
> > >
> > > > you guessed right
> > >
> > > I have my moments
> > >
> > > Cheers
> > > Jaime
> > >
> >
> >
> >
> > --
> > --
> > Melhores cumprimentos / Beir beannacht / Best
> regards
> >
> > António Manuel dos Santos Mota
> >
> > mobile: +353(0)877718363
> > mail: [EMAIL PROTECTED]
> > skype: amsmota
> > msn: [EMAIL PROTECTED]
> > linkedin: www.linkedin.com/in/amsmota
> >
> 



Kyrre Kristiansen


  ___
Support the World Aids Awareness campaign this month with Yahoo! For Good 
http://uk.promotions.yahoo.com/forgood/

Re: Evaluating Restlet

[Rob Heittman]

The thing I'm working on simply involves an alternative to
handle(request,response) that allows the response to be delivered to a
callback object, possibly and probably in another thread.  This is
principally valuable for AJAX style code and critical path for the GWT
support I'm working on.  To a certain degree, we actually want a model here
that looks and feels very familiar to GWT users who have worked with GWT-RPC
and would like to try a RESTful alternative.

The idea of being able to "pin" a thread is probably more applicable to the
issue of a long-lived request/response cycle (e.g. Comet style), and
probably more valuable across the board, but less critical path to what I'm
doing.

Both of these asynchronous needs are under active research and development,
and the implementation is probably interrelated (synchronous processing can
probably be expressed in terms of a single callback which can probably be
expressed in terms of chunked asynchronous processing) ... the RFE gives
some code examples for how this might be true.

Right now I am looking at the penalties and costs of thread-safe Request and
Response objects across the board, a need which must be sorted out before
any of the other async stuff can be safely investigated.


On 2/6/08, António Mota <[EMAIL PROTECTED]> wrote:
>
> Hmm, let me try to understand, is there a effort going on to include in
> Restlet some kind of "notification" to asynchronous clients based on
> xmlhhttprequest callbacks and/or Comet-style "push" techniques?
>
>
>
>
> On 06/02/2008, jbarciela jbarciela <[EMAIL PROTECTED]> wrote:
> >
> > > Have a look at this RFE and its references:
> > > http://restlet.tigris.org/issues/show_bug.cgi?id=143   ...
> >
> > Ah, that's a wonderful wonderful compilation of articles, so far I've
> > only read about Jetty's continuations, thanks for the link
> >
> > > you guessed right
> >
> > I have my moments
> >
> > Cheers
> > Jaime
> >
>
>
>
> --
> --
> Melhores cumprimentos / Beir beannacht / Best regards
>
> António Manuel dos Santos Mota
>
> mobile: +353(0)877718363
> mail: [EMAIL PROTECTED]
> skype: amsmota
> msn: [EMAIL PROTECTED]
> linkedin: www.linkedin.com/in/amsmota
>

Re: Evaluating Restlet

[António Mota]

Hmm, let me try to understand, is there a effort going on to include in
Restlet some kind of "notification" to asynchronous clients based on
xmlhhttprequest callbacks and/or Comet-style "push" techniques?




On 06/02/2008, jbarciela jbarciela <[EMAIL PROTECTED]> wrote:
>
> > Have a look at this RFE and its references:
> > http://restlet.tigris.org/issues/show_bug.cgi?id=143   ...
>
> Ah, that's a wonderful wonderful compilation of articles, so far I've
> only read about Jetty's continuations, thanks for the link
>
> > you guessed right
>
> I have my moments
>
> Cheers
> Jaime
>



-- 
-- 
Melhores cumprimentos / Beir beannacht / Best regards

António Manuel dos Santos Mota

mobile: +353(0)877718363
mail: [EMAIL PROTECTED]
skype: amsmota
msn: [EMAIL PROTECTED]
linkedin: www.linkedin.com/in/amsmota

Re: Evaluating Restlet

[jbarciela jbarciela]

> Have a look at this RFE and its references:
> http://restlet.tigris.org/issues/show_bug.cgi?id=143   ...

Ah, that's a wonderful wonderful compilation of articles, so far I've
only read about Jetty's continuations, thanks for the link

> you guessed right

I have my moments

Cheers
Jaime

Re: Evaluating Restlet

[jbarciela jbarciela]

Thanks for your answer Jerome.
The introductory paper was what triggered the question in my mind -- I
guess I need to read "Java Concurrency in Practice".
Cheers
Jaime


On Feb 5, 2008 3:38 AM, Jerome Louvel <[EMAIL PROTECTED]> wrote:
>
> Hi Jaime,
>
> > Since the "Restlet vs Servlet" topic was touched, please let me
> > include a related concern that I'm sure n00bs like me will share
> >
> > Jerome, in that FAQ you mention (this one I assume
> > http://www.restlet.org/about/faq), in question #3 it says:
> >
> > "Finally, the Restlet API is I/O agnostic as its core Representation
> > interface can work equally well with BIO streams (java.io package) and
> > NIO channels (java.nio package)."
>
> Yes, I wrote that :-)
>
> > Now, are you saying there that there is something conceptual that
> > prevents Servlets to use NIO? (apart from possible implementation
> > details in particular servers like Tomcat)
> > If that's true, then how should we interpret statements like "Jetty
> > can use NIO" or "Glassfish can use NIO" ?
>
> The Servlet API directly exposes the request inputstream and the response
> outputstream for consumption and writing by the Servlet developer. This
> means that it would be quite difficult for the API to cleanly allow the
> developer to have the choice to work with NIO channels instead, at least
> without breaking the backward compatibility.
>
> Now that doesn't mean that Servlet containers can't leverage NIO to improve
> their performance (scalability and throughput). They can indeed use the
> non-blocking IO at the socket level, request parsing and response
> formatting. This way, the number of concurrent connections can be decoupled
> from the number of processing threads.
>
> However, they can't leverage NIO from the socket to the Servlet as the
> Servlet API has no provision for NIO as explained above. This is where the
> Restlet API makes the difference, by introducing the Representation class
> based on the idea of contentlets suggested by Greg Wilkins (Jetty).
>
> BTW, you can read more context info in the introduction paper:
> http://www.restlet.org/about/introduction
>
> > Please notice that I don't intend to start a confrontation of the "I
> > say they say" kind, only looking for enlihgtment
>
> Thanks for keeping the discussion constructive. There is in fact no need for
> confrontation: we leverage the Servlet API in our adapter extension and
> Jetty as a standalone connector.
>
> Best regards,
> Jerome
>
>

Re: Evaluating Restlet

[Rob Heittman]

Exactly ...

In my case, I'm working on Restlet API support in Google Web Toolkit using
XmlHttpRequest as the "Client".  As this is idiomatically an asynchronous
facility -- regardless of whether your response is short lived (AJAX style)
or long lived (Comet style), the API needs ways of handling clients that
behave asynchronously, which it presently lacks.  Several interesting
connectors like Jetty have also introduced neat new facilities driven by the
desire to make the Comet style more manageable on the server side, so it's
not just about the client side.

Have a look at this RFE and its references:
http://restlet.tigris.org/issues/show_bug.cgi?id=143   ...   you guessed
right, it started with an observation about the Comet style.

- Rob


On 2/5/08, jbarciela jbarciela <[EMAIL PROTECTED]> wrote:
>
> When you say "callbacks", what do you have in mind? Something like Comet?
>
> Cheers
> Jaime
>

Re: Evaluating Restlet

[jbarciela jbarciela]

Hey, isn't semantic inadmissibility the basis for thought crimes and
fundamentalism?
:)

I want to thank you Rob for the detailed answer, I get your point
about the higher abstraction level giving you more freedom from the
implementation. That's definitively a good thing.

When you say "callbacks", what do you have in mind? Something like Comet?

Cheers
Jaime



On Feb 5, 2008 3:37 AM, Rob Heittman <[EMAIL PROTECTED]> wrote:
>
> As a third party kibitzer ... I feel like saying "Restlet vs. Servlet" at
> all is a bit semantically inadmissible.  It's not an "or" operation.  You
> can run Restlet with, without, in, outside, talking to, or being talked to
> by Servlet.  The scope of the javax.servlet API is intentionally narrower;
> all it does is model REST-style Uniform message passing
> (service(request,response)) for the purpose of writing server code.
>
> The Restlet framework adds a whole new abstraction layer specifically for
> modeling REST applications.  With this, much or most application work can be
> done with higher-level Representations that are separated nicely from the
> service(request, response) paradigm.  Both client and server can interact
> with the same Representation objects -- and indeed the same Uniform message
> layer -- whether or not any Servlets are involved in the process.
>
> On the "I/O agnostic" topic specifically, this separation of concerns
> becomes very interesting now as we explore things like asynchronous
> processing in the Restlet API.  We can add mechanisms for things like
> callbacks -- things not even remotely modeled in the Servlet API -- that
> affect the message passing aspects in dramatic ways, without
> Representations, or in many cases even Resources, having to be aware of the
> change.
>
> NIO can make an HTTP connector more scalable at dispatching calls to
> Servlets -- obviously both Restlet and Servlet run on top of Jetty, MINA,
> and Grizzly NIO connectors, to name a few -- but the Servlet API does not do
> anything particularly interesting to expose non-blocking/asynchronous design
> advantages.  If it did/when it does, Servlet authors will need to do
> refactoring to take advantage of it.  With a more separated API like
> Restlet, it is easier for major design revolutions to take place in the I/O
> layer -- pluggably and optionally -- while the bulk of the application
> remains stable.
>
> At my company, before we discovered Restlet, we wrote a lot of this SoC
> ourselves -- trivial Servlets that interacted with Resource and
> Representation objects -- but our code was pretty much tied to J2EE
> containers, because there was just too much plumbing in Servlet that we
> didn't want to re-create in a more abstract way.  After porting this all to
> Restlet, we find ourselves able to run the same applications online,
> offline, with or without a J2EE container, and have a nascent ability to do
> so in transcoded environments like GWT.  I feel sometimes like we need to
> get Duke out of retirement to hop around and say "Write Once, Run Anywhere
> ..."  That is really how it feels.
>
> - R
>
>
>
> On 2/5/08, jbarciela jbarciela <[EMAIL PROTECTED]> wrote:
> > Now, are you saying there that there is something conceptual that
> > prevents Servlets to use NIO? (apart from possible implementation
> > details in particular servers like Tomcat)
> > If that's true, then how should we interpret statements like "Jetty
> > can use NIO" or "Glassfish can use NIO" ?
> >
> > Please notice that I don't intend to start a confrontation of the "I
> > say they say" kind, only looking for enlihgtment
> >
>
>

RE: Evaluating Restlet

[Jerome Louvel]

Hi Tim,

Very good point. Now that I've read the "Java Concurrency in Practice" book
(excellent BTW!), I fully realize how this point is crucial.

Let's tackle it with the on-going Grizzly HTTP and GWT efforts. I've added
your comment here:

"Complete Grizzly connector"
http://restlet.tigris.org/issues/show_bug.cgi?id=341

Best regards,
Jerome  

> -Message d'origine-
> De : [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] De la 
> part de Tim Peierls
> Envoyé : mardi 5 février 2008 13:51
> À : discuss@restlet.tigris.org
> Objet : Re: Evaluating Restlet
> 
> On Feb 5, 2008 3:38 AM, Jerome Louvel <[EMAIL PROTECTED]> wrote:
> 
> 
>   However, they can't leverage NIO from the socket to the 
> Servlet as the
>   Servlet API has no provision for NIO as explained 
> above. This is where the
>   Restlet API makes the difference, by introducing the 
> Representation class
>   based on the idea of contentlets suggested by Greg 
> Wilkins (Jetty).
>   
> 
> 
> I hate to sound like a broken record, but the Restlet Request 
> and Response classes are not thread-safe, so Restlet cannot 
> yet take *full* advantage of NIO to break out of the 
> thread-per-request paradigm. (There is movement on this 
> front, however, as Rob Heittman pointed out earlier in this thread.)
> 
> --tim
> 
> 

Re: Evaluating Restlet

[Tim Peierls]

On Feb 5, 2008 3:38 AM, Jerome Louvel <[EMAIL PROTECTED]> wrote:

> However, they can't leverage NIO from the socket to the Servlet as the
> Servlet API has no provision for NIO as explained above. This is where the
> Restlet API makes the difference, by introducing the Representation class
> based on the idea of contentlets suggested by Greg Wilkins (Jetty).
>

I hate to sound like a broken record, but the Restlet Request and Response
classes are not thread-safe, so Restlet cannot yet take *full* advantage of
NIO to break out of the thread-per-request paradigm. (There is movement on
this front, however, as Rob Heittman pointed out earlier in this thread.)

--tim

RE: Evaluating Restlet

[Jerome Louvel]

Hi Jaime,

> Since the "Restlet vs Servlet" topic was touched, please let me
> include a related concern that I'm sure n00bs like me will share
> 
> Jerome, in that FAQ you mention (this one I assume
> http://www.restlet.org/about/faq), in question #3 it says:
> 
> "Finally, the Restlet API is I/O agnostic as its core Representation
> interface can work equally well with BIO streams (java.io package) and
> NIO channels (java.nio package)."

Yes, I wrote that :-)
 
> Now, are you saying there that there is something conceptual that
> prevents Servlets to use NIO? (apart from possible implementation
> details in particular servers like Tomcat)
> If that's true, then how should we interpret statements like "Jetty
> can use NIO" or "Glassfish can use NIO" ?

The Servlet API directly exposes the request inputstream and the response
outputstream for consumption and writing by the Servlet developer. This
means that it would be quite difficult for the API to cleanly allow the
developer to have the choice to work with NIO channels instead, at least
without breaking the backward compatibility.

Now that doesn't mean that Servlet containers can't leverage NIO to improve
their performance (scalability and throughput). They can indeed use the
non-blocking IO at the socket level, request parsing and response
formatting. This way, the number of concurrent connections can be decoupled
from the number of processing threads.

However, they can't leverage NIO from the socket to the Servlet as the
Servlet API has no provision for NIO as explained above. This is where the
Restlet API makes the difference, by introducing the Representation class
based on the idea of contentlets suggested by Greg Wilkins (Jetty).

BTW, you can read more context info in the introduction paper:
http://www.restlet.org/about/introduction
 
> Please notice that I don't intend to start a confrontation of the "I
> say they say" kind, only looking for enlihgtment

Thanks for keeping the discussion constructive. There is in fact no need for
confrontation: we leverage the Servlet API in our adapter extension and
Jetty as a standalone connector. 

Best regards,
Jerome  

Re: Evaluating Restlet

[Rob Heittman]

As a third party kibitzer ... I feel like saying "Restlet vs. Servlet" at
all is a bit semantically inadmissible.  It's not an "or" operation.  You
can run Restlet with, without, in, outside, talking to, or being talked to
by Servlet.  The scope of the javax.servlet API is intentionally narrower;
all it does is model REST-style Uniform message passing
(service(request,response)) for the purpose of writing server code.

The Restlet framework adds a whole new abstraction layer specifically for
modeling REST applications.  With this, much or most application work can be
done with higher-level Representations that are separated nicely from the
service(request, response) paradigm.  Both client and server can interact
with the same Representation objects -- and indeed the same Uniform message
layer -- whether or not any Servlets are involved in the process.

On the "I/O agnostic" topic specifically, this separation of concerns
becomes very interesting now as we explore things like asynchronous
processing in the Restlet API.  We can add mechanisms for things like
callbacks -- things not even remotely modeled in the Servlet API -- that
affect the message passing aspects in dramatic ways, without
Representations, or in many cases even Resources, having to be aware of the
change.

NIO can make an HTTP connector more scalable at dispatching calls to
Servlets -- obviously both Restlet and Servlet run on top of Jetty, MINA,
and Grizzly NIO connectors, to name a few -- but the Servlet API does not do
anything particularly interesting to expose non-blocking/asynchronous design
advantages.  If it did/when it does, Servlet authors will need to do
refactoring to take advantage of it.  With a more separated API like
Restlet, it is easier for major design revolutions to take place in the I/O
layer -- pluggably and optionally -- while the bulk of the application
remains stable.

At my company, before we discovered Restlet, we wrote a lot of this SoC
ourselves -- trivial Servlets that interacted with Resource and
Representation objects -- but our code was pretty much tied to J2EE
containers, because there was just too much plumbing in Servlet that we
didn't want to re-create in a more abstract way.  After porting this all to
Restlet, we find ourselves able to run the same applications online,
offline, with or without a J2EE container, and have a nascent ability to do
so in transcoded environments like GWT.  I feel sometimes like we need to
get Duke out of retirement to hop around and say "Write Once, Run Anywhere
..."  That is really how it feels.

- R

On 2/5/08, jbarciela jbarciela <[EMAIL PROTECTED]> wrote:
>
> Now, are you saying there that there is something conceptual that
> prevents Servlets to use NIO? (apart from possible implementation
> details in particular servers like Tomcat)
> If that's true, then how should we interpret statements like "Jetty
> can use NIO" or "Glassfish can use NIO" ?
>
> Please notice that I don't intend to start a confrontation of the "I
> say they say" kind, only looking for enlihgtment
>

Re: Evaluating Restlet

[jbarciela jbarciela]

Since the "Restlet vs Servlet" topic was touched, please let me
include a related concern that I'm sure n00bs like me will share

Jerome, in that FAQ you mention (this one I assume
http://www.restlet.org/about/faq), in question #3 it says:

"Finally, the Restlet API is I/O agnostic as its core Representation
interface can work equally well with BIO streams (java.io package) and
NIO channels (java.nio package)."

Now, are you saying there that there is something conceptual that
prevents Servlets to use NIO? (apart from possible implementation
details in particular servers like Tomcat)
If that's true, then how should we interpret statements like "Jetty
can use NIO" or "Glassfish can use NIO" ?

Please notice that I don't intend to start a confrontation of the "I
say they say" kind, only looking for enlihgtment

Peace
Jaime


On Jan 31, 2008 5:34 AM, Jerome Louvel <[EMAIL PROTECTED]> wrote:
>
> Hi Antonio,
>
> Thanks for your interest and patience. If you have a look at the list
> archives you can see how fast and well the community replies to questions.
> Please remember that people reply here on a voluntary basis, for free.
>
> If you need a more reactive assistance, you can check out our professional
> support plans:
> http://www.noelios.com/services/
>
> There are already many resources available, please make sure you check them
> all:
>   - web site and FAQ (http://www.restlet.org)
>  - mailing archives (http://www.restlet.org/community/lists)
>  - issue tracker (http://restlet.tigris.org/servlets/ProjectIssues)
>   - wiki (http://wiki.restlet.org)
>  - blog (http://blog.noelios.com) with entried on JAX-RS / JSR-311
>
> Also, did you check the FAQ links in the response I sent to your question in
> the REST discussion list? Do you understand better now the value of Restlet
> compared to Servlet?
>
>
> > So, for instance, can I do the "translation" I was talking about with
> Restlet instead of servlet + spring DataBinders?
>
> Could you describe your use case? Spring can be integrated with Restlets in
> many ways so I guess this is feasible. But there might be better
> alternatives.
>
>
> > Is there some special way to manage queues?
>
>  Could you be more precise? How would you like Restlet to help you here? We
> don't have a JMS connector yet for example, but it could be easily added.
>
> > logging?
>
> We have a built-in access logging service you can leverage. See the
> Javadocs, org.restlet.service package.
>
> > monitoring?
>
> Nothing specific here even though we consider JMX support for a future
> version. See:
> http://restlet.tigris.org/issues/show_bug.cgi?id=17
>
> I would also like to add a RESTful HTTP alternative in the future.
>
>
> > What's the level of integration of Restlet with SpringIntegration (and/or
> Cammel), if any? And while i'm at it, and with OSGi?
>
> Restlet in an open framework that can integrate with any other project/API
> to back your Resources.
>
> For OSGi, check out the upcoming talk at EclipseCon 2008 on "" made by the
> NASA Jet Propulsion Lab:
>  http://www.eclipsecon.org/2008/index.php?page=sub/&id=462
>
>
> > What's the relation between Restlets and JSR-311? Are the Restlet team
> committed to conform to it?
>
> Check out our blog and the list archive. If you need complementary details,
> let us know:
>  http://blog.noelios.com/2007/04/25/restlet-api-and-jsr-311-api/
> http://blog.noelios.com/2007/02/14/new-jsr-to-define-a-high-level-rest-api-for-java/
>
> Important point, we are committed to supporting JAX-RS in Restlet (see
> Stephan effort and remember that JAX-RS is an API still in design). Restlet
> framework s also much larger than this upcoming standard. The core Restlet
> API is class oriented, both server and client side while JAX-RS is
> annotation oriented and server side only. Restlet API is also a fully
> alternative to Servlet API, with provision to support NIO, protocol
> abstraction, and many more... It is also a stable and proven solution with
> many references in production.
>
> Best regards,
> Jerome
>
> 2008/1/31, António Mota <[EMAIL PROTECTED]>:
>
> > Hi, thanks for your reply. And what about the level of support from the
> project guys? Are there more resources besides this mailing list?
> >
> > From what I see from the levels of responses it's not that great...
> >
> > Another thing, what's the level of maturity of your jax-rs implementation?
> Do you think is ready for use in production environments? I understand that
> the specification itself it's not "mature", but would you use it in "real
> world" applications?
> >
> > Cheers.
> >
> >
> >
> >
> > On 30/01/2008, Stephan Koops <[EMAIL PROTECTED]> wrote:
> > >
> > > Hello António,
> > >
> > > here answers to some of your questions. The others may comment more.
> > >
> > > What's the relation between Restlets and JSR-311? Are the Restlet team
> committed to conform to it? I'm just implementing the JSR-311 specification
> for my master thesis. You can take a look in the trunk of the subversi

RE: Evaluating Restlet

[Jerome Louvel]

Hi Antonio,

If you design your ESB to be truly RESTful, then any HTTP client can connect
to your public API, without requiring any dependency beside HTTP and the
documents exchanged (XML?). That is the purpose of the Restlet framework,
leverage existing standard like HTTP, XML, JSON instead of imposing code
level dependencies.

Best regards,
Jerome  

> -Message d'origine-
> De : António Mota [mailto:[EMAIL PROTECTED] 
> Envoyé : vendredi 1 février 2008 18:17
> À : discuss@restlet.tigris.org
> Objet : Re: Evaluating Restlet
> 
> Well, I think it means "code against interfaces" so the 
> underlying implementations can be changed. My boss wants that 
> the public API i'm going to write have no external 
> dependencies to third party apps so eventual clients can 
> write only against our API specification. 
> 
> At least that's was what I understood...
> 
> 
> 
> 
> On 31/01/2008, Rob Heittman <[EMAIL PROTECTED]> wrote:
> 
> 
>   I'm not sure I understand the concern.  (I do find that 
> management concerns may not always be understandable)  It may 
> depend on how he is defining "dependency."
>   
>   If by "no dependencies" he means that you must write an 
> application that runs inside a J2EE container and cannot 
> include any other code  --  no JARs or classes not created by 
> you, then indeed you are shut out of using Restlet, or any 
> other reusable code not already supplied as part of J2EE.  
> This is not something you can fix.  You can stop evaluating 
> existing solutions and start writing ...
>   
>   If he means something like "no external dependencies" 
> -- no software that must be configured outside and in 
> addition to your web application -- then this is not a 
> problem with Restlet.  You can incorporate the appropriate 
> Restlet JARs in the WEB-INF/lib directory of your web 
> application, and it will deploy in any J2EE Servlet container 
> without the container operator having to do anything special 
> or even know what Restlet is.
>   
>   - R
>   
>   
>   
>   
>   On 1/31/08, António Mota <[EMAIL PROTECTED]> wrote:
> 
>   Hi again:
>   
>   Thanks all for your responses. The main concern 
> now is that my boss don't want to use nothing that has 
> dependencies besides J2EE. From his point of view, the use of 
> Restlet will imply a dependency to it, right?
>   
> 
> 
> 
> 
> 
> -- 
> -- 
> Melhores cumprimentos / Beir beannacht / Best regards
> 
> António Manuel dos Santos Mota
> 
> mobile: +353(0)877718363
> mail: [EMAIL PROTECTED]
> skype: amsmota
> msn: [EMAIL PROTECTED]
> linkedin: www.linkedin.com/in/amsmota 
> 

Re: Evaluating Restlet

[António Mota]

Well, I think it means "code against interfaces" so the underlying
implementations can be changed. My boss wants that the public API i'm going
to write have no external dependencies to third party apps so eventual
clients can write only against our API specification.

At least that's was what I understood...



On 31/01/2008, Rob Heittman <[EMAIL PROTECTED]> wrote:
>
>
> I'm not sure I understand the concern.  (I do find that management
> concerns may not always be understandable)  It may depend on how he is
> defining "dependency."
>
> If by "no dependencies" he means that you must write an application that
> runs inside a J2EE container and cannot include any other code  --  no JARs
> or classes not created by you, then indeed you are shut out of using
> Restlet, or any other reusable code not already supplied as part of J2EE.
> This is not something you can fix.  You can stop evaluating existing
> solutions and start writing ...
>
> If he means something like "no external dependencies" -- no software that
> must be configured outside and in addition to your web application -- then
> this is not a problem with Restlet.  You can incorporate the appropriate
> Restlet JARs in the WEB-INF/lib directory of your web application, and it
> will deploy in any J2EE Servlet container without the container operator
> having to do anything special or even know what Restlet is.
>
> - R
>
>
> On 1/31/08, António Mota <[EMAIL PROTECTED]> wrote:
> >
> > Hi again:
> >
> > Thanks all for your responses. The main concern now is that my boss
> > don't want to use nothing that has dependencies besides J2EE. From his point
> > of view, the use of Restlet will imply a dependency to it, right?
> >
>
>


-- 
-- 
Melhores cumprimentos / Beir beannacht / Best regards

António Manuel dos Santos Mota

mobile: +353(0)877718363
mail: [EMAIL PROTECTED]
skype: amsmota
msn: [EMAIL PROTECTED]
linkedin: www.linkedin.com/in/amsmota

Re: Evaluating Restlet

[Stephan Koops]

Hello António,
Another thing, what's the level of maturity of your jax-rs 
implementation? Do you think is ready for use in production 
environments? I understand that the specification itself it's not 
"mature", but would you use it in "real world" applications?
the JAX-RS iplementation is just under development. I have to hand out 
my master thesis to the university in July this year, so I think you can 
not use it earlier for production. In this moment it is also not ready 
for any using. Because I have no experience how long it would take to 
use it for production, so I can't tell, when it will be really ready.


And - as Jerome wrote - the specifiction isn't ready, so there can't be 
any production ready implementation yet.


regards
 Stephan

Re: Evaluating Restlet

[Rob Heittman]

I'm not sure I understand the concern.  (I do find that management concerns
may not always be understandable)  It may depend on how he is defining
"dependency."

If by "no dependencies" he means that you must write an application that
runs inside a J2EE container and cannot include any other code  --  no JARs
or classes not created by you, then indeed you are shut out of using
Restlet, or any other reusable code not already supplied as part of J2EE.
This is not something you can fix.  You can stop evaluating existing
solutions and start writing ...

If he means something like "no external dependencies" -- no software that
must be configured outside and in addition to your web application -- then
this is not a problem with Restlet.  You can incorporate the appropriate
Restlet JARs in the WEB-INF/lib directory of your web application, and it
will deploy in any J2EE Servlet container without the container operator
having to do anything special or even know what Restlet is.

- R


On 1/31/08, António Mota <[EMAIL PROTECTED]> wrote:
>
> Hi again:
>
> Thanks all for your responses. The main concern now is that my boss don't
> want to use nothing that has dependencies besides J2EE. From his point of
> view, the use of Restlet will imply a dependency to it, right?
>

Re: Evaluating Restlet

[António Mota]

Hi again:

Thanks all for your responses. The main concern now is that my boss don't
want to use nothing that has dependencies besides J2EE. From his point of
view, the use of Restlet will imply a dependency to it, right?


Cheers.





On 31/01/2008, Jonathan Hall <[EMAIL PROTECTED]> wrote:
>
> Hi António,
>
> I have to chip in say this is the quickest and most helpful public dev
> mailing list I've been subscribed to. Which isnt amazingly helpful since
> you don't know how many I've subscribed too ;).
> But it is good!
>
> Jon
>
> Mota wrote:
> > Hi, thanks for your reply. And what about the level of support from
> > the project guys? Are there more resources besides this mailing list?
> >
> > From what I see from the levels of responses it's not that great...
> >
> > Another thing, what's the level of maturity of your jax-rs
> > implementation? Do you think is ready for use in production
> > environments? I understand that the specification itself it's not
> > "mature", but would you use it in "real world" applications?
> >
> > Cheers.
> >
> >
> > On 30/01/2008, *Stephan Koops* <[EMAIL PROTECTED]
> > > wrote:
> >
> > Hello António,
> >
> > here answers to some of your questions. The others may comment more.
> >> What's the relation between Restlets and JSR-311? Are the Restlet
> >> team committed to conform to it?
> > I'm just implementing the JSR-311 specification for my master
> > thesis. You can take a look in the trunk of the subversion
> > repository (URL: http://restlet.tigris.org/svn/restlet, see also
> >
> http://wiki.restlet.org/docs_1.1/g1/13-restlet/50-restlet/47-restlet.html
> ).
> > You will find the JSR-311 implementation in the project
> > org.restlet.ext.jaxrs_1.0. There are some JUnit tests available in
> > the project org.restlet.test, in the package
> > org.restlet.test.jaxrs and it's sub packages. There you can see a
> > what the current state of development is.
> > Feel free to ask questions about it.
> >
> > Jerome Louvel (the founder of the Restlet API) is a member of the
> > JSR311 expert group.
> >> After that, same thing to some other kind of connectors, like FTP
> >> and maybe others.
> > There are some Restlet connectors. I don't know that there is a
> > FTP connector, but *I think* it is not very complicated to
> > implement one. I'm sure you will get support from the community,
> > if you need to implement such connector.
> >> Is there some special way to manage queues? logging? monitoring?
> > Restlet uses the default java.util.logging mechansim.
> >
> > regards
> >Stephan Koops
> >
> >
> >
> >
> > --
> > --
> > Melhores cumprimentos / Beir beannacht / Best regards
> >
> > António Manuel dos Santos Mota
> >
> > mobile: +353(0)877718363
> > mail: [EMAIL PROTECTED] 
> > skype: amsmota
> > msn: [EMAIL PROTECTED] 
> > linkedin: www.linkedin.com/in/amsmota
> > 
>
>


-- 
-- 
Melhores cumprimentos / Beir beannacht / Best regards

António Manuel dos Santos Mota

mobile: +353(0)877718363
mail: [EMAIL PROTECTED]
skype: amsmota
msn: [EMAIL PROTECTED]
linkedin: www.linkedin.com/in/amsmota

Re: Evaluating Restlet

[Jonathan Hall]

Hi António,

I have to chip in say this is the quickest and most helpful public dev 
mailing list I've been subscribed to. Which isnt amazingly helpful since 
you don't know how many I've subscribed too ;).

But it is good!

Jon

Mota wrote:
Hi, thanks for your reply. And what about the level of support from 
the project guys? Are there more resources besides this mailing list?


From what I see from the levels of responses it's not that great...

Another thing, what's the level of maturity of your jax-rs 
implementation? Do you think is ready for use in production 
environments? I understand that the specification itself it's not 
"mature", but would you use it in "real world" applications?


Cheers.


On 30/01/2008, *Stephan Koops* <[EMAIL PROTECTED] 
> wrote:


Hello António,

here answers to some of your questions. The others may comment more.

What's the relation between Restlets and JSR-311? Are the Restlet
team committed to conform to it? 

I'm just implementing the JSR-311 specification for my master
thesis. You can take a look in the trunk of the subversion
repository (URL: http://restlet.tigris.org/svn/restlet, see also
http://wiki.restlet.org/docs_1.1/g1/13-restlet/50-restlet/47-restlet.html).
You will find the JSR-311 implementation in the project
org.restlet.ext.jaxrs_1.0. There are some JUnit tests available in
the project org.restlet.test, in the package
org.restlet.test.jaxrs and it's sub packages. There you can see a
what the current state of development is.
Feel free to ask questions about it.

Jerome Louvel (the founder of the Restlet API) is a member of the
JSR311 expert group.

After that, same thing to some other kind of connectors, like FTP
and maybe others.

There are some Restlet connectors. I don't know that there is a
FTP connector, but *I think* it is not very complicated to
implement one. I'm sure you will get support from the community,
if you need to implement such connector.

Is there some special way to manage queues? logging? monitoring?

Restlet uses the default java.util.logging mechansim.

regards
   Stephan Koops




--
--
Melhores cumprimentos / Beir beannacht / Best regards

António Manuel dos Santos Mota

mobile: +353(0)877718363
mail: [EMAIL PROTECTED] 
skype: amsmota
msn: [EMAIL PROTECTED] 
linkedin: www.linkedin.com/in/amsmota 
 

Re: Evaluating Restlet

[Jerome Louvel]

Hi Antonio,

Thanks for your interest and patience. If you have a look at the list
archives you can see how fast and well the community replies to questions.
Please remember that people reply here on a voluntary basis, for free.

If you need a more reactive assistance, you can check out our professional
support plans:
http://www.noelios.com/services/

There are already many resources available, please make sure you check them
all:
 - web site and FAQ (http://www.restlet.org)
 - mailing archives (http://www.restlet.org/community/lists)
 - issue tracker (http://restlet.tigris.org/servlets/ProjectIssues)
 - wiki (http://wiki.restlet.org)
 - blog (http://blog.noelios.com) with entried on JAX-RS / JSR-311

Also, did you check the FAQ links in the response I sent to your question in
the REST discussion list? Do you understand better now the value of Restlet
compared to Servlet?

> So, for instance, can I do the "translation" I was talking about with
Restlet instead of servlet + spring DataBinders?

Could you describe your use case? Spring can be integrated with Restlets in
many ways so I guess this is feasible. But there might be better
alternatives.

> Is there some special way to manage queues?

Could you be more precise? How would you like Restlet to help you here? We
don't have a JMS connector yet for example, but it could be easily added.

> logging?

We have a built-in access logging service you can leverage. See the
Javadocs, org.restlet.service package.

> monitoring?

Nothing specific here even though we consider JMX support for a future
version. See:
http://restlet.tigris.org/issues/show_bug.cgi?id=17

I would also like to add a RESTful HTTP alternative in the future.

> What's the level of integration of Restlet with SpringIntegration (and/or
Cammel), if any? And while i'm at it, and with OSGi?

Restlet in an open framework that can integrate with any other project/API
to back your Resources.

For OSGi, check out the upcoming talk at EclipseCon 2008 on "" made by the
NASA Jet Propulsion Lab:
http://www.eclipsecon.org/2008/index.php?page=sub/&id=462

> What's the relation between Restlets and JSR-311? Are the Restlet team
committed to conform to it?

Check out our blog and the list archive. If you need complementary details,
let us know:
http://blog.noelios.com/2007/04/25/restlet-api-and-jsr-311-api/
http://blog.noelios.com/2007/02/14/new-jsr-to-define-a-high-level-rest-api-for-java/

Important point, we are committed to supporting JAX-RS in Restlet (see
Stephan effort and remember that JAX-RS is an API still in design). Restlet
framework s also much larger than this upcoming standard. The core Restlet
API is class oriented, both server and client side while JAX-RS is
annotation oriented and server side only. Restlet API is also a fully
alternative to Servlet API, with provision to support NIO, protocol
abstraction, and many more... It is also a stable and proven solution with
many references in production.

Best regards,
Jerome

2008/1/31, António Mota <[EMAIL PROTECTED]>:
>
> Hi, thanks for your reply. And what about the level of support from the
> project guys? Are there more resources besides this mailing list?
>
> From what I see from the levels of responses it's not that great...
>
> Another thing, what's the level of maturity of your jax-rs implementation?
> Do you think is ready for use in production environments? I understand that
> the specification itself it's not "mature", but would you use it in "real
> world" applications?
>
> Cheers.
>
>
> On 30/01/2008, Stephan Koops <[EMAIL PROTECTED]> wrote:
> >
> >  Hello António,
> >
> > here answers to some of your questions. The others may comment more.
> >
> > What's the relation between Restlets and JSR-311? Are the Restlet team
> > committed to conform to it?
> >
> > I'm just implementing the JSR-311 specification for my master thesis.
> > You can take a look in the trunk of the subversion repository (URL:
> > http://restlet.tigris.org/svn/restlet, see also
> > http://wiki.restlet.org/docs_1.1/g1/13-restlet/50-restlet/47-restlet.html).
> > You will find the JSR-311 implementation in the project
> > org.restlet.ext.jaxrs_1.0. There are some JUnit tests available in the
> > project org.restlet.test, in the package org.restlet.test.jaxrs and it's
> > sub packages. There you can see a what the current state of development is.
> > Feel free to ask questions about it.
> >
> > Jerome Louvel (the founder of the Restlet API) is a member of the JSR311
> > expert group.
> >
> > After that, same thing to some other kind of connectors, like FTP and
> > maybe others.
> >
> > There are some Restlet connectors. I don't know that there is a FTP
> > connector, but *I think* it is not very complicated to implement one.
> > I'm sure you will get support from the community, if you need to implement
> > such connector.
> >
> > Is there some special way to manage queues? logging? monitoring?
> >
> > Restlet uses the default java.util.logging mechansim.
> >
> > regard

Re: Evaluating Restlet

[António Mota]

Hi, thanks for your reply. And what about the level of support from the
project guys? Are there more resources besides this mailing list?

>From what I see from the levels of responses it's not that great...

Another thing, what's the level of maturity of your jax-rs implementation?
Do you think is ready for use in production environments? I understand that
the specification itself it's not "mature", but would you use it in "real
world" applications?

Cheers.


On 30/01/2008, Stephan Koops <[EMAIL PROTECTED]> wrote:
>
>  Hello António,
>
> here answers to some of your questions. The others may comment more.
>
> What's the relation between Restlets and JSR-311? Are the Restlet team
> committed to conform to it?
>
> I'm just implementing the JSR-311 specification for my master thesis. You
> can take a look in the trunk of the subversion repository (URL:
> http://restlet.tigris.org/svn/restlet, see also
> http://wiki.restlet.org/docs_1.1/g1/13-restlet/50-restlet/47-restlet.html).
> You will find the JSR-311 implementation in the project
> org.restlet.ext.jaxrs_1.0. There are some JUnit tests available in the
> project org.restlet.test, in the package org.restlet.test.jaxrs and it's
> sub packages. There you can see a what the current state of development is.
> Feel free to ask questions about it.
>
> Jerome Louvel (the founder of the Restlet API) is a member of the JSR311
> expert group.
>
> After that, same thing to some other kind of connectors, like FTP and
> maybe others.
>
> There are some Restlet connectors. I don't know that there is a FTP
> connector, but *I think* it is not very complicated to implement one. I'm
> sure you will get support from the community, if you need to implement such
> connector.
>
> Is there some special way to manage queues? logging? monitoring?
>
> Restlet uses the default java.util.logging mechansim.
>
> regards
>Stephan Koops
>



-- 
-- 
Melhores cumprimentos / Beir beannacht / Best regards

António Manuel dos Santos Mota

mobile: +353(0)877718363
mail: [EMAIL PROTECTED]
skype: amsmota
msn: [EMAIL PROTECTED]
linkedin: www.linkedin.com/in/amsmota

Re: Evaluating Restlet

[Stephan Koops]

Hello António,

here answers to some of your questions. The others may comment more.
What's the relation between Restlets and JSR-311? Are the Restlet team 
committed to conform to it? 
I'm just implementing the JSR-311 specification for my master thesis. 
You can take a look in the trunk of the subversion repository (URL: 
http://restlet.tigris.org/svn/restlet, see also 
http://wiki.restlet.org/docs_1.1/g1/13-restlet/50-restlet/47-restlet.html). 
You will find the JSR-311 implementation in the project 
org.restlet.ext.jaxrs_1.0. There are some JUnit tests available in the 
project org.restlet.test, in the package org.restlet.test.jaxrs and it's 
sub packages. There you can see a what the current state of development is.

Feel free to ask questions about it.

Jerome Louvel (the founder of the Restlet API) is a member of the JSR311 
expert group.
After that, same thing to some other kind of connectors, like FTP and 
maybe others.
There are some Restlet connectors. I don't know that there is a FTP 
connector, but *I think* it is not very complicated to implement one. 
I'm sure you will get support from the community, if you need to 
implement such connector.

Is there some special way to manage queues? logging? monitoring?

Restlet uses the default java.util.logging mechansim.

regards
  Stephan Koops

Evaluating Restlet

[António Mota]

Hello:

I'm new here, and I'm evaluating Restlet to use in a solution we are going
to implement. To cut a long story short, here's a description what I'm up
to.

For 2 or 3 weeks we're going to focus on a HTTP implement with Resources
(servlets or restlets) as the entry point of each service, each Resource
will be responsible for managing 3 queues (in, out, err), probably JMS
queues, and software component(s) (maybe using a facade) conditionally
consuming the inQ.

Next, we'll try to implement some kind of "connector" for user agents that
uses mail, probably using some kind of command pattern so that original
messages (HTTP, mail, etc...) will be "translated" to one single "type"
before arriving to the queues. We'll probably be using Spring DataBinder for
that, and then SpringIntegration between the Queues and the sw component(s).

After that, same thing to some other kind of connectors, like FTP and maybe
others.

I'm trying to evaluate if Restlets are a good fit for this structure,
instead of plain-old servlets. My boss doesn't want to use Restlets because
practically it will only handle the request and we can do that with servlets
so no need for another dependency.

So, for instance, can I do the "translation" I was talking about with
Restlet instead of servlet + spring DataBinders?

Is there some special way to manage queues? logging? monitoring?

What's the level of integration of Restlet with SpringIntegration (and/or
Cammel), if any? And while i'm at it, and with OSGi?

What's the relation between Restlets and JSR-311? Are the Restlet team
committed to conform to it?

Thanks all for your assistance.