I think websockets should be in scope. But not because servlets are
implemented by HTTP servers (and WS starts with HTTP), but rather that
servlets are the core component of application servers.
Servlet containers provide and application scope with classloading,
authentication, authorisation, data sources, resource injection, life
cycle assistance, developer assistance etc. etc. etc. All these things
are just as applicable to WS based webapplications as they are to HTTP
based webapplications.
SIP on the otherhand, is for distinctly different style of
application, sufficiently different that it does deserve it's own JSR.
On 15 September 2011 18:10, Rajiv Mordani <rajiv.mordani_at_oracle.com> wrote:
> Support for upgrading protocol to WebSocket
We could support upgrading in general to an arbitrary protocol
implemented against the async API we have been discussing.
However, i think that protocols and protocols extensions are exactly
the kind of services that a container should be providing to an
application, so I'd much rather see upgrade supported to specific
protocols (like WebSocket... and eventually SPDY etc.).
Note that this kind of de prioritises the need for an async IO API in
servlets. The main reason for that was to support some of the
various comet "hacks" out there. If these are now provided for with a
standard websocket implementations, then why would we need the async
IO API?
> Support for messaging constructs that WebSocket has in the Servlet API
Indeed - although the design of the actual API for sending/receiving
frames and messages probably has a wider scope than just servlets.
So it would be good to get extra input from other groups interested in
java implementations of websockets.
> Container requirement to support data framing - not exposed to the user in the servlet API
Within the websockets WG, it is very strongly expressed that framing
should have no semantic meaning to the application, and thus should be
entirely transparent to the application. On the other hand,
extensions such as MUX and compression have to be framing aware.
Thus I think this suggests that we consider an architecture where
extensions are implemented by the container (and thus can be frame
aware), which applications will only see a messaging API that deals
with complete messages.
> Support for security constraints, authentication and authorization
WS spec now allows standard authentication mechanisms to be applied to
the upgrade requests. The challenge now is to convince the browser
vendors to react to any 401 or 302 responses we might send as a
result.
> Support for exposing the sessions, cookies and other java ee constructs like
> user transaction etc in a websocket application
It should be simple to establish the session ID of the upgrade request
for a WS connection, as browsers should now be sending those cookies
(and maybe adding session to the URI). The challenge is that we need
to prevent the session from expiring if all the following traffic is
WS.
cheers