Leads, Bill, Experts,
I am convinced that both, WebSockets and SSE, need to be supported by the
Java EE 8 platform to keep up with the pace of technological change in the
web domain. But it is a good question what is the best way to ensure this.
This posting proposes another way to define SSE support for Java so far not
discussed IMHO.
_Abstract_
I hereby propose that the JAX-RS Expert Group (JSR 339) for inclusion into
Java EE 8 shall define three separate specification documents as a
replacement for "SSE-enhanced JAX-RS 2.x": (I) "Java API For HTTP "
(covering all purely HTTP-technical aspects serviced currently by
javax.ws.rs.*), (II) "Java API for SSE" as a use case of (I) hence
effectively and technically being an OPTIONAL JAX-RS extension library,
(III) "Java API for RESTful Web Services" as the main use case of (I) and
effectively and technically being a MANDATORY JAX-RS extension library.
_Justification_
Having read Santiago's proposal (SSE-in-EE8.pdf) I think the paper misses
one aspect. In the past, Java EE APIs had been defined to standardize the
use of existing product groups. For example, JTA standardized the way to
talk to TX monitors, JMS standardized the way to talk to MOM, JDBC
standardized the way to talk to RDBMS, JPA standardized the way to talk to
ORM products, and so on. And it was the Servlet APIs particular job to
standardize how HHTP servers can invoke Java bypassing CGI.
But then came Java EE 6 (JAX-RS) and Java EE 7 (WebSockets), which had *not*
been built to standardize the access to existing products, but to provide
Java based *implementations* of existing *use cases* (JAX-RS) and
*technologies*. There was nothing (and still is nothing) like product group
called "REST Servers" or "WebSockets Servers" on the market which needed to
be wrapped by Java. REST could be done with Servlet API. So JAX-RS was part
of the application layer, not of the technology layer. Clearly, JAX-RS was a
great benefit (which is why I serve in this EG), but from day one it was
clear that it introduced ambiguity as it was covering the same technology
that Servlet API already covered (I always said, "JAX-RS is ServletsNG" and
hoped Servlets would have been obsoleted by JAX-RS). WebSockets API on the
other hand is a Java wrapper around a *technology*, not an existing
*product*. It more or less is a thin layer around Socket API. And it is
doubtful why for SMTP and AMQP there are no own "technological APIs", but
these have been simply covered by classic *product group* APIs (Java Mail
API, JMS)? In my understanding, actually WebSockets API must not exist OR it
must be an add-on ontop of Servlet API (hence an endpoint can be created by
ANY Web Server) OR there is a general asychronous messaging API which covers
JMS and WebSockets (and AMQP and SMTP). Due to THAT ambiguity, we today face
Bill and Santiago's question: "Where to put SSE?"!
I do not doubt any technical fact of Santiago's paper, but I think it simply
looks at SSE from a wrong angle as it is API-centric: It does not start at
existing *products*, but solely tries to find that API which has the best
*technical fit*. I'd like to suggest we also think about the best
*intentional fit*: Which API was made for what and which of that categories
does SSE match?
Servlet API: The intention of the Servlet API is to handle TCP connections,
unfortunately (see below) with special support for HTTP requests. As SSE
IMHO is simply a *use case* of HTTP, it should definitively not be needed to
add any particular SSE things to Servlet API -- unless I missed something
and SSE cannot be done by simply implementing a Servlet. So a clear NO for
Servlet API.
WebSockets: From the sole point of technical equivalence, as TCP-based HTTP
is natively supported by Servlet API, and as WebSockets is TCP-based and
HTTP-initiated, I wonder why WebSockets ever became a standalone Java API
while there still is no standalone Java API for HTTP! Rants aside, as I
actually would really love to see HTTP support getting dropped from Servlet
API (see below), adding WebSockets to Servlet API certainly would have
foiled disambiguity and I certainly am happy that it became its own API. To
keep this clear shape of that API, it MUST NOT be enhanced by SSE.
WebSockets and SSE have nothing in common. The first is a standalone
TCP-based *protocol*, the latter is a *use case* of HTTP. While both can be
used to implement the same application scenario (server push) it must be
clear that server push is a *use case* but WebSockets is a *technology* API
not a *use case* API. It might look appealing, but it would simply be wrong
by intent. So a clear NO for WebSockets API.
JAX-RS: It would have been good if Servlet API's HTTP support would have
been obsoleted by JAX-RS 1.0 already, as for me JAX-RS actually is NOT a
REST API but in fact "the" Java HTTP API (I'd like to perkily claim that
most JAX-RS users do not implement "clean" REST but simply love the APIs
simplicitly and power compared to Servlets -- just as I do)! Understanding
JAX-RS as "Java API for HTTP" if there really shall be a Java API for SSE,
then I clearly vote for JAX-RS -- and solely JAX-RS. BUT: We must clearly
say that doing that will drop the word "REST" from that API finally as SSE
is everythig but RESTful (fullstop)! And I doubt we or anybody in the Java
EE umbrelly spec wants that. So I want to do another proposal. see below.
SSE API: SSE is a "non-technology" and "non-product". It is a *use case*. I
do not think that it is a good idea to write a spec for a *use case*. Clear
NO for that.
"Java API for HTTP based use cases": SSE is a *use case* and besides SSE
there might be lots of others. One example is WebDAV (the main driver for my
EG participation as you might remember). Or ATOM. WebDAV and ATOM have
successfully been implemented ontop of JAX-RS in the past, without any need
to change the JAX-RS API or name them in the specification explicitly. The
question is: Why do that for SSE? I think the most clean way to provide
developers support for SSE (and WebDAV and ATOM and any other HTTP *use
case*) is to write a "Java API for http based use cases" (ok, we need a
better name). That API will clarify the following facts: (1) HTTP is obsolet
in Servlets API; all future HTTP use has to be done by this new API. (2) The
technical implementation of this API is the interfaces and classes currently
found in javax.ws.rs.* (hence, we simply rename the JAX-RS API to
effectively become the new HTTP API). (3) Examples for uses of this new HTTP
API are WebDAV, ATOM, SSE -- and REST. (4) JAX-RS is getting stripped from
anything which simply deals with HTTP as a pure transport layer, hence
becoming a very thin layer ontop of the new HTTP API with a spec only
talking about how to map RESTful ideas on that technology defined in
javax.ws.rs.*.
This might sound crazy, but it is the most clean way, it makes JAX-RS 3.0
totally RESTful as it is getting stripped from the HTTP boilerplate (simply
linking to the new HTTP API as ist foundation layer) and it allows to add
SSE to javax.ws.rs.* (the sole and optimal place to put it from a technical
viewpoint) WITHOUT harming the REST acronym in any way.
_Conclusion_
To sum up, SSE is intentionally and technically best implemented ontop of
javax.ws.rs.*, but I'd like to split the outcome of the JSR 339 EG into
three separate PDFs to provide clean separation of concerns in the spec and
in the API:
* The first one defines the Java API for HTTP based technology
(javax.ws.rs.*, i. e. which was what most of JAX-RS 2.x code dealt with
before -- like the annotations, the exception handling, the of JAXB,
configuration, HTTP client, and so on).
* The second on defines the Java API for SSE as an OPTIONAL library. In the
technical sense this becomes a JAX-RS 2.x extension, just like ATOM and
WebDAV are already.
* The third one defines the Java API for RESTful Web Services as a MANDATORY
library. In the technical sense this becomes a JAX-RS 2.x extension which
mostly is empty. It solely contains that parts of JAX-RS which are
definitively not common HTTP but really REST.
We simply split the PDFs, JavaDocs and JARs. This way JAX-RS still is
RESTful, the way for more extensions is open and predefined, and SSE is its
own specification without the overhead of another JSR!
Regards
Markus
From: Santiago Pericas-Geertsen [mailto:Santiago.PericasGeertsen_at_oracle.com]
Sent: Donnerstag, 22. Mai 2014 15:35
To: jsr339-experts_at_jax-rs-spec.java.net
Subject: [jsr339-experts] Fwd: [javaee-spec users] [jsr342-experts]
Server-Sent Events in Java EE 8
Dear Experts,
I'm forwarding a message from Bill Shannon in relation to SSE in EE 8.
Please take a look as this may have an impact on our future work.
-- Santiago
Begin forwarded message:
From: Bill Shannon <bill.shannon_at_oracle.com>
Subject: [javaee-spec users] [jsr342-experts] Server-Sent Events in Java EE
8
Date: May 21, 2014 at 8:14:46 PM EDT
To: jsr342-experts_at_javaee-spec.java.net
Reply-To: jsr342-experts_at_javaee-spec.java.net
One of the items we'd like to add support for in Java EE 8 is
Server-Sent Events. We've considered several options for how
to add this support and concluded that JAX-RS seems like the best
choice. Santiago (JAX-RS spec lead) has written up the options
and our conclusion here:
https://java.net/projects/javaee-spec/downloads/download/SSE-in-EE8.pdf
Please let us know if you have any concerns with including SSE
support in JAX-RS. Otherwise, expect to see this proposed in the
next JAX-RS JSR, to be submitted this summer.
Thanks.
Bill