Skip to main content

[jsr356-experts] Re: Some ideas on Web Sockets in the web container and in Java EE

  • From: Joe Walnes < >
  • To:
  • Subject: [jsr356-experts] Re: Some ideas on Web Sockets in the web container and in Java EE
  • Date: Tue, 14 Aug 2012 06:41:40 -0500

+1 to that.

On Tue, Aug 14, 2012 at 2:47 AM, Greg Wilkins < " target="_blank"> > wrote:

I should also say that the solution to this problem that we are going towards in the Jetty API is to NOT make the ServletRequest available to the application when it is accepting the websocket connection.  Instead we make a cutdown WebSocketHandshakeRequest available, which can wrap either a real ServletRequest or be created from a MUX channel open.

cheers



On 14 August 2012 17:45, Greg Wilkins < " target="_blank"> > wrote:

Danny,

I'd also like to add Multiplexing support, because MUX is definitely coming to websocket sooner or later.

The issue with mux is that unlike the original handshake, there is no real HTTP request available when a new channel is opened on a muxed websocket connection.
The MUX protocol will provide all the headers as-if the HTTP handshake had been sent, but it is unclear until we see browser implementations if this will really be all-the-headers? eg including cookies and auth?

The problem we have to avoid is allowing any state from the servlet/EE context of the original handshake/connection leak into a newly opened channel, as the MUX may be done by a proxy and may be mixing channels from different users on different browsers.      Creating the correct EE context for MUX connections is probably going to need a lot of container involvement.

cheers





On 10 August 2012 09:59, Danny Coward < " target="_blank"> > wrote:
Hi folks,

One of the larger items remaining to work on is how the Web Socket API integrates-with/works-when-deployed-in web containers and in the Java EE platform.

So I wanted to get out a few simple ideas to stimulate discussion on that topic.

1) Integration with web security
- it should be possible to declare a web socket's security context: an endpoint's required authentication scheme, the user-roles that can access it, whether transport encryption must be on on/off.
- developers should have access to the security context at runtime (current API does some, not all of this).

2) Web Socket sessions and Http Sessions
- see my last email on 'Multithreading Options' for four suggested scenarios on that. I'm sure there are more.

3) Using EE components to create Web Sockets
- it should be possible to create a web socket endpoint using a stateless session or singleton EJB, or using a CDI managed bean

4) Here are some useful objects to inject into web socket applications:-
a) into web socket endpoints
- HttpSession
- ServletContext
- ServerContainer (see WebSocketAPI v003)
- EndpointConfiguration (see WebSocketAPI v003)
- list of active Sessions (see WebSocketAPI v003)

b) into a MessageHandler
- current Session (see WebSocketAPI v003)
- Remote (see WebSocketAPI v003)

5) Packaging model
- should be able to deploy websocket application classes into a WAR
- they should live in the usual spot WEB-INF/classes and/or WEB-INF/lib

I'd welcome other ideas or comment on all of these !

- Danny











--
Danny Coward
Java EE
Oracle Corporation



--
Greg Wilkins < " target="_blank"> >
http://www.webtide.com
Developer advice and support from the Jetty & CometD experts.



--
Greg Wilkins < " target="_blank"> >
http://www.webtide.com
Developer advice and support from the Jetty & CometD experts.



[jsr356-experts] Some ideas on Web Sockets in the web container and in Java EE

Danny Coward 08/09/2012

[jsr356-experts] Re: Some ideas on Web Sockets in the web container and in Java EE

Greg Wilkins 08/14/2012

[jsr356-experts] Re: Some ideas on Web Sockets in the web container and in Java EE

Greg Wilkins 08/14/2012

[jsr356-experts] Re: Some ideas on Web Sockets in the web container and in Java EE

Joe Walnes 08/14/2012
 
 
Close
loading
Please Confirm
Close