Logo Questions Linux Laravel Mysql Ubuntu Git Menu
 

Jetty WebSocket api vs the standard JSR 356 API

Jetty 9 supports both it's own Jetty Websocket API as well as the standard JSR 356 API, for what I assume are historical reasons (Jetty's API precedes the final JSR 356).

I've looked over the basic documentation of both APIs, as well as some examples. Both APIs seem fairly complete and rather similar. However, I need to choose one over the other for a new project I'm writing, and I'd like to avoid using an API that might be deprecated in the future or might turn out to be less feature-rich.

So are there any important differences between the two except for the obvious fact that one is standardized?

like image 921
Malt Avatar asked Sep 10 '14 16:09

Malt


People also ask

What is JSR 356 WebSocket?

JSR 356 is a part of the upcoming Java EE 7 standard; hence, all Java EE 7–compliant application servers will have an implementation of the WebSocket protocol that adheres to the JSR 356 standard. Once they are established, WebSocket client and server peers are symmetrical.

Is there an API for WebSockets?

A new article, now up on otn/java, by Java Champion Johan Vos, titled “JSR 356, Java API for WebSocket,” shows developers how to integrate WebSockets into their applications.

How to program a WebSocket server with the jetty API?

Programming a WebSocket server with the Jetty API is not much different: Create a POJO class. Annotate this class with @WebSocket annotation. Implement the methods that handle the OnWebSocketConnect, OnWebSocketClose, OnWebSocketMessage and OnWebSocketError events.

What is JSR 356 and why is it important?

This is a huge benefit, because it prevents a vendor-lock and allows for more choices and freedom of libraries and application servers. JSR 356 is a part of the upcoming Java EE 7 standard; hence, all Java EE 7–compliant application servers will have an implementation of the WebSocket protocol that adheres to the JSR 356 standard.


1 Answers

Implementor of both on Jetty here :)

The Jetty WebSocket API came first, and the JSR-356 API is built on top of it.

The JSR-356 API does a few things that the Jetty WebSocket API does not, such as

  • Decoder's for automatic Bin/Text to Object conversion
  • Encoder's for automatic Object to Bin/Text conversion
  • Path Param handling (aka automatic URI Template to method param mapping)

However, the Jetty WebSocket API can do things the JSR-356 API cannot.

  • WebSocketCreator logic for arbitrary creation of the WebSocket endpoint, with access to the HttpServletRequest
  • Better control of timeouts
  • Finer buffer / memory configurations
  • You can manage WebSocket Extensions
  • Supports Reg-ex based Path mappings for endpoints
  • Access to raw Frame events
  • WebSocket client supports HTTP proxies (JSR-356 standalone client has no configuration options for proxies)
  • WebSocket client supports better connect logic with timeouts
  • WebSocket client supports SSL/TLS (JSR-356 standalone client has no configuration options for SSL/TLS)
  • Access to the both InetAddress endpoint information from the active WebSocket Session object
  • Access to UpgradeRequest from active WebSocket Session object
  • Better support for stateless endpoints
  • Read events support suspend/resume logic to allow application some basic tcp backpressure / flow control
  • Filter based or Servlet based configuration (the JSR-356 approach requires upgrade to occur before all other servlet and filter processing)

Hope this helps, if you want more details, please use the jetty-users mailing list, as this sort of question is really inappropriate for stackoverflow.

like image 91
Joakim Erdfelt Avatar answered Oct 19 '22 10:10

Joakim Erdfelt