Jerome Louvel wrote:
> Hi Bill,
>
>> You're gonna have to explain to me or link examples on how a
>> "content-based" api can do streaming and not have to hold
>> large content
>> in memory. Is it JAX-RS's MessageBodyReader/Writer model except with
>> NIO constructs?
>
> Yes, the MessageBodyReader/Writer model is a good start. In the Restlet API,
> we have a Representation class to cover this need:
> http://www.restlet.org/documentation/1.1/api/org/restlet/resource/Representa
> tion.html
>
> It is not necessary to use the NIO constructs. I think it is way too
> low-level for JAX-RS which is supposed to annotate domain beans. BIO streams
> are perfectly sufficient for content-based interfaces.
>
> The main point you miss is about the threading-model. I suggest that the
> JAX-RS annotated bean returns the working thread immediately after
> processing, but without writing any body content itself.
>
> Otherwise, there is no way you can scale beyond one thread per request and
> leverage NIO for writing all the responses to the sockets with a limited
> pool of writer threads.
>
To take *full* advantage of Non-blocking I/O application code needs to
be aware of and do chunking (although there could be a framework to help
with this). I think a better link at what your response model solves is
talked about here:
http://docs.codehaus.org/display/JETTY/Continuations
Really the AJAX polling problem. Unless your JAX-RS service falls into
this particular usecase, your response model isn't really going to solve
many performance issues.
Beyond the BLOB case I talked about before, if you look at servlet
development, people use the raw output stream or print writers to stream
dynamic content. Developers will *still* want to use a raw output
stream especially if they are migrating an existing Servlet-based
restful service to the JAX-RS model. We should not enforce either the
Representation or MessageBodyWriter architecture on simple applications
that just want to stream dynamic data because of one particular AJAXian
(mis)usecase.
That being said, I like your Representation object and allowing the
Resource class the ability to create and pass back this object rather
than having to write and register a MessageBodyWriter separately. So +1
on that.
Still, I do think that most JAX-RS application developers will find
getting access to the Input and OutputStreams very useful. I know I
have already found the need for this in the first two applications I've
prototyped with JAX-RS.
>> What's available to
>> the "content API" a.k.a. MessageBodyReader/Writers, should be
>> available
>> to the component. Sometimes all this abstraction is just
>> complete overkill.
>
> My feeling is that JAX-RS is opposite, that the JAX-RS is already too
> low-level (hence the feeling that it could replace the Servlet API). By
> trying to accommodate 100% of the needs it runs the risk of producing a
> suboptimal design.
>
I don't think getting access to Input/OutputStreams creates a suboptimal
design. Since a JAX-RS endpoint uses annotations rather than a static
interface contract to process requests, its easy to plug in new models
as they become available through the specification or as vendor plugins.
The key is to get the extension SPIs correct.
--
Bill Burke
JBoss, a division of Red Hat
http://bill.burkecentral.com