As required by the Java Specification Participation Agreement (JSPA), the TCK will be licensed at no charge without support to qualified not-for-profit. The Compatibility Testing Scholarship Program will verify such qualification. Support may also be provided at no charge with approval of the scholarship board. For more information, please refer to:http://www.oracle.com/technetwork/java/index-137188.html

2.1 Please describe the proposed Specification:

This JSR will define a standard API for creating WebSocket
applications.

There is a wide range of web applications that rely on timely
updates from a central server like stock tickers, live maps, chat
applications, collaborative online tools and multiplayer web-based
games. WebSocket offers solution to the problems of latency,
scalability and performance associated with HTTP based solutions
like polling, long-polling and HTTP-streaming. There is a lot of
interest in the Java developer community in creating web
applications for the Java platform that utilize WebSocket. Given
that the definition of WebSocket protocol is a proposed standard,
and that the major web browsers either support, or plan to support
it in their next major release, the time is right for a standard
Java API for WebSocket.

Specification of how WebSocket application will work within
the Java EE security model

This functionality will be a mix of APIs together with Java
annotations to make for a flexible and easy to use programming
model, as is found in other Java APIs in the Java EE platform.

The primary scenario is for that applications created using this
technology be server based. That is to say, this technology will be
for Java EE developers creating WebSocket applications in
bi-directional commutation with browser clients. This is exemplified
by a chat application, consisting of a web page, executing a client
script that connects to a server application. The server application
accepts new chat participants using the web sockets handshake,
accepts incoming chat messages, broadcasts updates of the currently
participating users to all clients in session, mediates
client-to-client chat sessions.

A secondary scenario, is that this API will aid Java-clients of
WebSocket applications residing on a server. This scenario is
illustrated by a Java-based chat client participating in the chat
example above.

This JSR will explore a separable client-API for WebSocket that will
run standalone on Java SE (specifically including API support for
initiating WebSocket communication) as part of its first release, or
may defer this to a later release.

2.3 The Executive Committees would like to ensure JSR submitters think about how their proposed technology relates to all of the Java platform editions. Please provide details here for which platform editions are being targeted by this JSR, and how this JSR has considered the relationship with the other platform editions.

This specification targets the Java EE 7 Platform. It will be based on the corresponding release of the Java SE platform.

2.4 Should this JSR be voted on by both Executive Committees?

No. Just the SE/EE Executive Committee.

2.5 What need of the Java community will be addressed by the proposed specification?

The Java community has already seen the need to use WebSocket from Java applications, as can be seen from the list of projects that already provide a way to do so. The Java community is best served by one standard API for using WebSocket in an application.

2.6 Why isn't this need met by existing specifications?

Though WebSocket applications could be created by low level I/O APIs in Java SE, this approach is cumbersome and difficult. There is no standard Java API that is high enough level to make the creation of WebSocket applications simple.

2.7 Please give a short description of the underlying technology or technologies:

Since WebSocket is TCP based, and uses an HTTP 'handshake' to initiate and terminate a WebSocket session, this project will likely build on existing networking and HTTP-based APIs where appropriate. This JSR will work closely with the Java Servlet 3.1 expert group who are exploring the integration of the intial handshake into the Java Servlet model.

2.8 Is there a proposed package name for the API Specification? (i.e., javapi.something, org.something, etc.)

Possibly: javax.net.websocket.* or under java.net.websocket.

2.9 Does the proposed specification have any dependencies on specific operating systems, CPUs, or I/O devices that you know of?

No.

2.10 Are there any security issues that cannot be addressed by the current security model?

No.

2.11 Are there any internationalization or localization issues?

This JSR will use the I18N support in Java SE.

2.12 Are there any existing specifications that might be rendered obsolete, deprecated, or in need of revision as a result of this work?

No.

2.13 Please describe the anticipated schedule for the development of this
specification.

We hope to deliver the final specification, reference
implementation, and TCK in the Q1 of 2013. A rough schedule would
be:

Apr 2012

Expert group formed

Q3 2012

Early Draft review

Q4 2012

Public Review

Q1 2013

Final release

2.14 Please describe the anticipated working model for the Expert Group working on developing this
specification.

The primary means of communication will be email, with conference calls and face-to-face meetings scheduled as needed. We will solicit feedback from the community and leverage the open source development model.

2.15 Provide detailed answers to the transparency checklist, making sure to
include URLs as appropriate:

websocket-spec java.net project site will be used to track all
issues and disseminate information on the progress of the JSR. The
Expert Group will conduct business on a publicly readable alias. A
private alias will be used only for EG administrative matters, as
needed.

- Is the schedule for the JSR publicly available, current, and
updated regularly?

The schedule will be available on the project page for the JSR.

- Can the public read and/or write to a wiki for the JSR?

We'll use a public mailing list for comments.

- Is there a publicly accessible discussion board for the JSR
that you read and respond to regularly?

We'll track such discussions and respond to them on the public
comment mailing list.

- Have you spoken at conferences and events about the JSR
recently?

No

- Are you using open-source processes for the development of the
RI and/or the TCK?

Yes, the RI will be developed as a java.net project.

- What are the Terms of Use required to use the collaboration
tools you have prepared to use with the Expert Group, so that
prospective EG members can judge whether they are compatible with
the JSPA?

The terms will be available on the project page for the JSR.

- Does the Community tab for my JSR have links to and information
about all public communication mechanisms and sites for the
development of my JSR?

Yes, it will point to the project page for the JSR.

2.16 Please describe how the RI and TCK will de delivered, i.e. as part of a profile or platform edition, or stand-alone, or both. Include version information for the profile or platform in your answer.

The RI will be delivered standalone and possibly bundled with
some future release of Glassfish. The TCK will be delivered both
standalone and as part of a suitable future release of the Java EE
TCK. See the business terms for details.

2.17 Please state the rationale if previous versions are available stand-alone and you are now proposing in 2.13 to only deliver RI and TCK as part of a profile or platform edition (See sections 1.1.5 and 1.1.6 of the JCP 2 document).

N/A

2.18 Please provide a description of the business terms for the Specification, RI and TCK that will apply when this JSR is final.