THIS IS A TEST INSTANCE. ALL YOUR CHANGES WILL BE LOST!!!!
Title/Summary: Develop websocket binding for Apache Tuscany
Student: Florian Moga
Student e-mail: moga.flo AT gmail DOT com
Student Major: Computer Science
Student Degree: Undergraduate
Student Graduation: June 2011
Organization: Apache Software Foundation
Assigned Mentor: Ant Elder
Abstract
Apache Tuscany provides a comprehensive infrastructure for SOA development using a service oriented approach. Apache Tuscany implements Service Component Architecture (SCA) which defines a flexible, service-based model for construction, assembly and deployment of network of services. It reduces the effort needed to develop this type of applications by pushing out of the business logic things like protocol handling or interactions between components, which make the components reusable and help the developer to concentrate on their business logic implementation.
WebSocket is a technology providing for bi-directional, full-duplex communications channels, over a single Transmission Control Protocol (TCP) socket. It is designed to be implemented in web browsers and web servers but it can be used by any client or server application. The WebSocket API is being standardized by the W3C and the WebSocket protocol is being standardized by the IETF.
The goal of this project is to enable SCA components to expose services that will allow browser clients to communicate with them as well as to enable inter-component communication via the websocket protocol. The nature of the protocol will offer new potential in the asynchronous communication offered by Tuscany and will align the framework with the HTML5 technologies.
Detailed Description
Tuscany Java SCA is a lightweight runtime that is designed to run standalone or provisioned to different host environments. SCA is a programming model for abstracting business functions as components and using them as building blocks to assemble business solutions. An SCA component offers services and depends on functions that are called references. It also has an implementation associated it with it which is the business logic that can be implemented in any technology.
SCA provides a declarative way to describe how the services in an assembly interact with one another and what quality of services (security, transaction, etc) is applied to the interaction. Since service interaction and quality of service is declarative, solution developers remain focus on business logic and therefore development cycle is simplified and shortened. This also promotes the development of reusable services that can be used in different contexts. Services can interact with one another synchronously or asynchronously and can be implemented in any technology.
Currently, Apache Tuscany has support for various technologies enabling asynchronous communication between components (like JMS or Comet). However, a websocket binding will complement these and further more, will avoid pitfalls specific to these technologies.
For instance, Comet is a web application model in which a long-held HTTP request allows a web server to push data to a browser, without the browser explicitly requesting it. Specific methods of implementing Comet fall into two major categories: streaming and long polling. Streaming is achieved by making a request using a hidden iframe and by not committing the response from the server thus obtaining a persistent connection over HTTP. As events occur, data is sent data through that channel in the form of Javascript <script> tags which are executed inside the iframe as they are received.
Problems with this approach arise when traffic goes through a proxy server. For example, a proxy server may be buffering the response and cause latency. Alternatively, the proxy server may be configured to disconnect HTTP connections that are kept open for a certain amount of time. Also, due to the fact that script tags can be pointed at any URI and JavaScript code in the response will be executed in the current HTML document, a potential security risk is created.
Websockets represent the next evolution of web communications - a full-duplex, bidirectional communications channel that operates through a single socket over the Web. HTML5 websockets provide a true standard that can be used to build scalable, real-time web applications. To establish a websocket connection, the client and server upgrade from the HTTP protocol to the websocket protocol during their initial handshake. Once established, websocket data frames can be sent back and forth between the client and the server in full-duplex mode. Data is sent on the wire in the form of frames that have an associated type. Broadly speaking, there are types for textual data, which is interpreted as UTF-8 text, binary data (whose interpretation is left up to the application), and control frames, which are not intended to carry data for the application, but instead for protocol-level signaling, such as to signal that the connection should be closed.
The data is minimally framed with just two bytes. In addition, since it provides a socket that is native to the browser, it eliminates many of the problems Comet solutions are prone to. Websockets remove the overhead and dramatically reduce complexity. While the WebSocket protocol itself is unaware of proxy servers and firewalls, it features an HTTP-compatible handshake so that HTTP servers can share their default HTTP and HTTPS ports (80 and 443) with a WebSocket gateway or server. Also, the client to server data is masked in order to avoid confusing intermediaries.
Apache Tuscany can have great benefits from supporting a websocket binding. Apart from being able to communicate more effectively in full-duplex mode with HTML5 compliant browsers, it provides a lightweight asynchronous protocol to use for communication between SCA components.
Implementation Details
This project will require the use of a websocket protocol implementation. For this task, I am planning to use the Monsoon project which is an open source Java implementation of the websocket protocol based on the latest IETF draft (v06). It is built on Java NIO, thus giving the ability to build scalable non-blocking websocket endpoints. I am already actively involved in working on this project as I am one of the co-founders. The goal of the project is to provide a comprehensive websocket library in order to facilitate the websocket adoption for a variety of frameworks and toolkits. As new drafts will be released by the IETF, these frameworks and toolkits won't have to take care of all the internal protocol changes and just upgrade to a new version on the project. With that in mind, once a fully functional version is implemented, we're planning to propose Monsoon to the Apache Incubator where we hope it will mature and be useful to various projects in their attempt to support the websocket technology.
Deliverables
Additional Information
Development Schedule
April 20 - May 23
May 24 - July 15
July 16
July 17 - August 16
August 17 - August 19
August 20