Today’s data climate is fast-paced and it’s not slowing down. Here’s why your current integration solution is not enough. Brought to you in partnership with Liaison Technologies.
SSE (Server-Sent Event)
is a standard mechanism used to push, over HTTP, server notifications
to clients. SSE is often compared to WebSocket as they are both
supported in HTML 5 and they both provide the server a way to push
information to their clients but they are different too! See here for some of the pros and cons of using one or the other.
For REST application, SSE can be quite complementary as it offers
an effective solution for a one-way publish-subscribe model, i.e. a
REST client can 'subscribe' and get SSE based notifications from a REST
endpoint. As a matter of fact, Jersey (JAX-RS Reference Implementation)
already support SSE since quite some time (see the Jersey documentation
for more details).
There might also be some cases where one might want to use SSE
directly from the Servlet API. Sending SSE notifications using the
Servlet API is relatively straight forward. To give you an idea, check here
for 2 SSE examples based on the Servlet 3.1 API.
We are thinking about adding SSE support in Java EE 8
but the question is where as there are several options, in the platform, where SSE could potentially be supported:
- the Servlet API
- the WebSocket API
- or even having a dedicated SSE API, and thus a dedicated JSR too!
Santiago Pericas-Geertsen (JAX-RS Co-Spec Lead) conducted an
initial investigation around that question. You can find the arguments
for the different options and Santiago's findings here
So at this stage JAX-RS seems to be a good choice to support SSE
in Java EE. This will obviously be discussed in the respective JCP
Expert Groups but what is your opinion on this question?
Is iPaaS solving the right problems? Not knowing the fundamental difference between iPaaS and iPaaS+ could cost you down the road. Brought to you in partnership with Liaison Technologies.