------------------- Java API for WebSocket 1.0 JSR text--------------------

Section 1. Identification

Submitting Member: Oracle

Name of Contact Person: Danny Coward

E-Mail Address: danny.coward@oracle.com

Telephone Number: +1 415 350 1701

Fax Number: +1 408 276 4185

Specification Lead: Danny Coward

E-Mail Address: danny.coward@oracle.com

Telephone Number: +1 415 350 1701

Fax Number: -, +1 408 276 4185

Initial Expert Group Membership:

Supporting this JSR:

IBM
SAP
RedHat

Section 2: Request

#### 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.

This JSR will provide support in the Java EE platform for:-

- Creating WebSocket Java components to handle bi-directional WebSocket conversations
- Initiating and intercepting WebSocket events
- Creation and consumption of WebSocket text and binary messages
- The abililty to define WebSocket protocols and content models for an application
- Configuration and management of WebSocket sessions, like timeouts, retries, cookies, connection pooling
- 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.2 What is the target Java platform? (i.e., desktop, server, personal, embedded, card, etc.)

This specification is targeted for Java EE.

#### 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.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 be 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.

Provide the links for the attached licenses

#### 2.19 Please describe the communications channel you have established for the public to observe Expert Group deliberations, provide feedback, and view archives of all Expert Group communications.

The Expert Group will conduct business on jsr356-experts@websocket-spec.java.net mailing list which is publicly readable.

#### 2.20 What is the URL of the Issue Tracker that the public can read, and how does the public log issues in the Issue Tracker?

A JIRA issue tracker for websocket-spec java.net project will be used for this purpose. The issue tracker URL is http://java.net/jira/browse/WEBSOCKET_SPEC

#### 2.21 Please provide the location of the publicly accessible document archive you have created for the Expert Group.

Expert Group's publicly readable mailing list will be archived at http://java.net/projects/websocket-spec/lists/jsr356-experts/archive

Section 3: Contributions

#### 3.1 Please list any existing documents, specifications, or implementations that describe the technology. Please include links to the documents if they are publicly available.

WebSocket Protocol Definition | http://tools.ietf.org/html/rfc6455
Java Servlet 3.1 | http://jcp.org/en/jsr/detail?id=340
jWebSocket | http://jwebsocket.org/
Grizzly | http://grizzly.java.net/
Jetty | http://download.eclipse.org/jetty/stable-7/apidocs/org/eclipse/jetty/websocket/package-frame.html

#### 3.2 Explanation of how these items might be used as a starting point for the work.