On 10 Mar 2014, at 22:06, Sergey Beryozkin <sberyozkin_at_talend.com> wrote:
> On 10/03/14 20:42, Markus KARG wrote:
>> I think adding support for SSE to JAX-RS would allow to standardize an
>> API for a common type of application development problem: How to keep
>> the client updated to server side changes?
>>
>> Example: Chat system.
>>
>> Common solution in JAX-RS 2.0: Any type of periodic GET (a.k.a polling
>> et al), like
>>
>> @GET public java.util.List<CharComment> getChatComments() {
>>
>> return /* …all_chat_comments… */;
>>
>> }
>>
>> Possible solution with SSE: Get content of thread so far using initial
>> GET, then wait for more thread postings using SSE (inversion of control
>> regarding poll-vs-push).
>>
>> But clearly, I do not like the way Jersey proposes it. The API looks not
>> very RESTful, it more looks like "Servlet++".
>>
>> Instead, if we decide to support SSE, we should concentrate on REST and
>> only add that parts of API that still are RESTful and fit nicely into
>> JAX-RS as it is designed currently.
>>
>> My proposal would be that the API should look like this:
>>
>> @GET *_at_WebSocket* public *java.util.Stream<*ChatComment*>*
>> getChatComments() {
>>
>> return this.mySourceStream.filter(…).map(…);
>>
>> }
>
> I think I really like it:
> - use a dedicated annotation, the enabler, instead of overloading Produces
> - Typed stream support; I was thinking yesterday more about introdocing a typed StreamOutput variant. Jersey uses EventOutputStream clearly usable in scope of SSE only, something like what Markus suggests, that can be used with and without SSE, with different data types, will do well
In Jersey, the SSE EventOutput extends ChunkedOutput<OutboundEvent> ...
Marek
>
> Sergey
>
>>
>> This is aligned with Java EE 8's base platform which is Java SE 8,
>> providingjava.util.Stream<T>as an endless pipeline of <T>events send by
>> server. I assume anybody aware of the new Stream API will recognize what
>> a method with such a signature will do: Provide not only a single
>> ChatComment, but actually an endless stream. It is just a simple
>> extension to what a GET does, actually only shifting the time when that
>> GET ends -- defined by the client application. The @WebSocket annotation
>> implies @SSEmuch in the same way as @GETimplies @HttpMethod, opening a
>> way to extend from WebSockets to more SSE technologies (even @COMETor
>> other legacy solutions). If JAX-RS provides support for SSE, then
>> WebSockets is a MUST, since it seems to be the most "native" SSE
>> extension to HTTP GET. My proposal obviously implies that there is some
>> source stream injected which serves as the origin of the SSE events, and
>> that the JAX-RS engine is utilizing ManagedExecutorServer (Java EE) or
>> some unmanaged ExecutorService (Java SE). As an alternative, in Java EE
>> environments, the source can be attached to CDI events, hence CDI's
>> event dispatcher drives this chain.
>>
>> As you see, my proposal is much less defined around technical
>> implementation, but much more around developer's readability and
>> simplicity of the API. Also it is at-most aligned to Java 8. But
>> certainly, it does not open doors for any fancy thing one could imagine
>> with SSE channels in mind, but solely is defined to solve one clear
>> RESTful problem: How to keep the client updated after an initial GET.
>> And I think, that is the sole SSE item which has to be covered in a
>> future RESTful API. Everything else, in my understanding, is not
>> RESTful, hence is not necessarily to be covered by JAX-RS.
>>
>> Regards
>>
>> Markus
>>
>> *From:*Marek Potociar [mailto:marek.potociar_at_oracle.com]
>> *Sent:* Mittwoch, 5. März 2014 16:39
>> *To:* jsr339-experts_at_jax-rs-spec.java.net
>> *Subject:* [jsr339-experts] Adding SSE support to JAX-RS 2.1?
>>
>> Hello experts,
>>
>> As you may know, the first steps towards starting work on Java EE 8 has
>> been made already. Among the most important ones was the Java EE 8
>> Community Survey. As the survey results
>> <https://java.net/downloads/javaee-spec/JavaEE8_Community_Survey_Results.pdf> indicate,
>> there is a very strong support in Java EE community for coming with a
>> standard API for supporting Server-Sent Events in Java EE 8. Clearly,
>> one way or the other, SSE support will be added in Java EE 8 platform.
>>
>> There are multiple options how to achieve this and one of these options
>> being considered is to extend JAX-RS API to provide better support for
>> SSE. Before we make a final decision, I'd like to get your feedback on
>> whether or not you think that extending JAX-RS API with SSE support is a
>> good idea.
>>
>> To get the idea how such JAX-RS API support could look like, please
>> check Jersey User Guide section that describes how client and server SSE
>> support is currently implemented in Jersey 2.x:
>>
>> https://jersey.java.net/documentation/latest/sse.html#overview
>>
>> I am looking forward to your feedback.
>>
>> Thank you,
>>
>> Marek