Again, we should step back from the technical view and look at the problem
from the application view: JAX-RS is not enforcing Servlets as an underlying
technology layer. Hence, an application author wanting to support REST and
WebSockets has the problem of failover. From this point of view, the
solution is that a JAX-RS engine must be able to internally perform the
upgrade. It is pretty valid to offload that that to the Servlet layer if
there is one. But from the view of an application vendor, the more
interesting point is the definition that the JAX-RS API will allow to
TRIGGER that upgrade -- independent of the underlying conainer technology.
With "the same application" I mean a scenario where a JAX-RS resource is
fulfilling the "GET" request which triggers the protocol upgrade. That
resource might for example receive events from an uplink server by SSE,
translates or combines these events, and then publishes the result to
clients. It is up to the clients to decide whether they do REST polling
(JAX-RS), or WebSockets, or SSE, to receive these events. An application
vendor provides exactly one server, at one endpoint, and that endpoint must
be able to work with polling, WebSockets and SSE, as in the real world, a
service must be flexible and must not prevent client app vendors from their
choice of technology.
Regards
-Markus
From: Santiago Pericas-Geertsen [mailto:Santiago.PericasGeertsen_at_oracle.com]
Sent: Donnerstag, 11. Dezember 2014 20:21
To: jsr370-experts_at_jax-rs-spec.java.net
Subject: Re: [jax-rs-spec users] Welcome to the JAX-RS 2.1 EG
On Dec 11, 2014, at 1:38 PM, Markus KARG <markus_at_headcrashing.eu> wrote:
You misunderstood the proposal. Nobody wants to provide an alternative
WebSocket API. The proposal is that WebSocket API can be used _together_
with JAX-RS API in the same application, just as I described in my
scenarion: Upgrading a JAX-RS HTTP connection to a WebSocket API session.
I think this is clearer now. You're talking specifically about the "upgrade
mechanism". Well, upgrading protocols (WS or others) is a pretty low-level
operation and thus, IMO, is something that belongs in the Servlet API [1]. I
think it will a tough sell to duplicate this in JAX-RS.
When you say "the same application", you probably mean the handler
endpoint? Of course, I can use WS and JAX-RS and Servlets in the same
application.
-- Santiago
[1]
http://docs.oracle.com/javaee/7/api/javax/servlet/http/HttpUpgradeHandler.ht
ml
From: Marek Potociar [mailto:marek.potociar_at_oracle.com]
Sent: Donnerstag, 11. Dezember 2014 17:59
To: jsr370-experts_at_jax-rs-spec.java.net
Subject: Re: [jax-rs-spec users] Re: Welcome to the JAX-RS 2.1 EG
On 11 Dec 2014, at 17:55, Sergey Beryozkin < <mailto:sberyozkin_at_talend.com>
sberyozkin_at_talend.com> wrote:
On 11/12/14 16:43, Marek Potociar wrote:
On 10 Dec 2014, at 23:54, Markus KARG < <mailto:markus_at_headcrashing.eu>
markus_at_headcrashing.eu> wrote:
* The list names SSE but not WebSockets. Is this to be understood as
really
SSE only, hence definitively no WebSocket support?
There's another JSR for WS.
What if somebody wants to write a JAX-RS application which shall open a
WebSocket as a reaction to an HTTP method, and which has to forward events
on that WebSocket received by JAX-RS Client API? If we allow SSE, then
people will ask how to do something like that with WebSocket and need a
one-stop blueprint shop. I doubt people would understand that JAX-RS spec
explains how to do such a scenario with SSE, but says nothing about
WebSocket, while WebSocket spec says nothing about JAX-RS in turn. That's
why I'm asking.
To those people, my answer would be that SSE is a special case of media type
working on top of HTTP request-response model. There is no further magic
behind it and as such it can fit quite neatly into JAX-RS programming model.
In WebSocket, there is no HTTP and no request/response relationship, which
is why Java EE provides a separate API for WebSocket.
Personally I'm not convinced that we need to bring WebSocket into the
picture at all. SSE may look similar to WebSocket at first glance, but it is
quite different really. IMO, WebSocket do not belong to JAX-RS spec, neither
as a topic and nor as an example.
People do use it though for doing interactive Web UI applications. I don't
have the statistics of how widely it is used but it is probably more
deployed than SSE, at this moment of time.
It might be reasonable to do some work, may be in the future, to let JAX-RS
developers to participate in such activities too,
Opening an ice-box JIRA is a good compromise IMHO :-), no specific targets
but can be tracked
Frankly, I do not see us introducing another WebSocket API in Java EE. We
would need to present a lot stronger arguments to Java EE platform spec
leads rather than "JAX-RS users use WebSocket a lot in their applications".
Let's focus on areas where we can be realistically successful instead.
Cheers,
Marek
Thanks, Sergey
Cheers,
Marek
If that is true, then it
might at least good to add an example to the specification how to use
WebSockets with JAX-RS and describe why there is no need for explicit
WebSocket support due to that.
I don't know if this belongs in our spec, but maybe a best practice document
or something like that. Are you volunteering? ;-)
As long as you tell me how JAX-RS and Java WebSocket API can be used
together I'll provide the code sample and some explanative lines if you
like. I have no clue about the Java WebSockets API as I always thought it
shouldn't be an standalone API but has to be part of JAX-RS... ;-)
* Why is it JSR 370's responsibility to evaluate MVC requirements when there
is a separate MVC JSR? What is expected from the JSR 370 EG which cannot be
done by the MVC EG?
_If_ MVC decides to build on top of JAX-RS (TBD), then we _may_ need to
evaluate requirements coming from them.
Understood. So it's their turn initially.
Regards
-Markus
--
Sergey Beryozkin
Talend Community Coders
<http://coders.talend.com/> http://coders.talend.com/
Blog: <http://sberyozkin.blogspot.com/> http://sberyozkin.blogspot.com