A few weeks back on Devoxx 08, Jonas Jacobi and John R. Fallows did a talk about 2 future web technologies  that’ll change the way we architect our webapplications.
(in the same manner then AJAX did a few years back).

The technologies are called WebSockets and Server Sent events and are part of the HTML5 specification. (which is now in Editor’s draft and thus not finished)

WebSockets and Server Sent events can enable us to create a full-duplex web application. Eg. a sample application could be a poker game with thousands of viewers connected and that those viewers need to be notified in realtime. Another example could be a continuously updated stock ticker.

Prior to the introduction of WebSockets, bi-directional browser communication was an elusive beast, commonly known as Comet or ReverseAjax and typically achieved with an astonishing assortment of browser hacks. But, with the emerging standards outlined in the HTML 5 specification, developers can now take advantage of a full-duplex communications channel that operates over a single socket.

Real time web

With real time web, we mean that web clients can receive server updates (server initiated communication) and end users receive those updates concurrently.

Long polling with AJAX (XML Http Request) gives us near real time updates, but they are requested from the client and cause increased network traffic. Also these short AJAX requests generally have a small payload and relatively high amount of http headers. (wasted bandwith)

Comet technologies support HTTP Streaming, this setups a persistent http connection which only has to be setup/teardown only once. (especially nice for performance for https traffic)

HTML 5 Overview

HTML 5 not only contains WebSockets and Server Sent events.  It also contains standard features like:

• communication (sockets, cross-site)
• graphics (2D)
• drag n drop
• storage (transient, (offline)    persistent)
• compatibility

Here we focus on two: Server-sent events and WebSockets

Server-sent events

Server-sent events standardizes how we stream data from the server to the client (in fact standardizing comet/reverse ajax).

It introduces a new DOM Element: eventsource. The eventsource element provides a simple interface for allowing servers to dispatch DOM events into documents that expect it.

Here is how to create it:

var es = document.createElement(”eventsource”);
es.addEventSource(”http://www.javablog.be”);

(where the event source is an URL).

WebSockets

WebSockets provide a full duplex TCP connection to communicate between the browser and the server. It traverses firewalls and routers and allows authorized cross domain communication.

An example is provided below:

var myWebSocket = new WebSocket(”ws://www.websocket.org”);

The WebSocket(url) constructor takes one argument, url, which specifies the URL to which to connect. When a WebSocket object is created, the User Agent must parse this argument and verify that the URL parses without failure and has a <scheme> component whose value is either “ws” or “wss”. Only then the user agent must asynchronously establish a Web Socket connection to url.

myWebSocket.postMessage(”Hello”);

=> text based data transmission using the connection.

myWebSocket.onopen = function(evt) { }

=> The open  event is fired when the Web Socket connection is established.

myWebSocket.onmessage = function(evt) { }

=> The message event is fired when when data is received for a connection.

myWebSocket.onclose = function(evt) { }

=> The close event is fired when the connection is closed

myWebSocket.disconnect();

=> close the conncetion

Browser support

Opera already has Server sent events, for Mozilla/Firefox there is patch available (bug 338583)
WebSockets is not yet available natively in browsers.

But fortunately for current browsers Kaazing.com provides an emulation Javascript library. (IE5.5+, Firefox 1.5, Chrome 0.2+, Safari 3.1+, Opera9+)
The Javascript only emulates the parts which are not yet implemented in a certain browser.
It can be any of the following layers: ByteSocket, Websockets, Server sent events, Cross site XML HTTP Request, XML Http Request IFrame postMessage

This is a post from JavaBlog.be

Devoxx 08: HTML 5 WebSockets and Server Sent Events

The first part of the talk showed us the new features planned for Servlet 3.0.

What follows is based on the Public Review draft.
So be sure to check if the following still applies to the final Servlet 3.0 version.

Modularization of the web.xml settings

Right now the web.xml is one big configuration file. In Servlet 3.0 it’s possible to modularize it into multiple files.
These files are called “web-fragment.xml” files and they are merged together on application initialization.
Because these fragments can conflict with each other, the specification has specified rules for conflict resolution. (we could take a deeper look at this in a future blog post).

Martin also said that fragment ordering is not defined; this eg. could mean that a filter you want to be executed first may have to be repeated in multiple fragments.

Annotation support in your servlets

A few annotations were added that you can use in your servlets:

@WebServlet

This annotation is used to define a Servlet component in a web application. The urlPatterns or the value attribute on the annotation MUST be present. (value is for 1 URL mapping, urlPatterns for multiple URL mappings)
Classes annotated with @WebServlet class MUST extend javax.servlet.http.HttpServlet class except when applied on a JAX-RS / JAX-WS endpoint.

Example:

@WebServlet(name=”MyServlet”, urlPatterns={”/foo”, “/bar”})
public class SampleUsingAnnotationAttributes extends HttpServlet{
public void doGet(HttpServletRequest req, HttpServletResponse res) {
}
}

Other optional attributes for the @WebServlet annotation are: supportAsync and asyncTimeout

@ServletFilter

This annotation is used to define a Filter in a web application. Classes annotated with @ServletFilter MUST implement javax.servlet.Filter

@InitParam

This annotation is used to specify Init Parameters for a servlet or a filter

@WebServletContextListener

The WebServletContextListener annotation is used to annotate a context listener to get events for various operations on the particular web application context.
Classes annotated with @WebServletContextListener MUST implement javax.servlet.ServletContextListener

Asynchronous requests

Sometimes a filter and/or servlet is unable to complete the processing of a request without waiting for a resource or event before generating a response. For example, a servlet may need to wait for an available JDBC connection, for a response from a remote web service, for a JMS message, or for an application event, before
proceeding to generate a response. Waiting within the servlet is an inefficient operation as it is a blocking operation that consumes a thread and other limited resources. Frequently a slow resource such as a database may have many threads blocked waiting for access and can cause thread starvation and poor quality of service  for an entire web container.

Servlet 3.0 introduces the ability for asynchronous processing of requests so that the thread may return to the container and perform other tasks.

When asyncSupported is set to true in the filter/servlets annotation the application can start asynchronous
processing in a separate thread by calling the HttpServletRequest.startAsync method passing it a
reference to the request and response objects.

After I’ve played with the asynchronous requests I’ll post some code samples to Java Blog to explain how exactly it works.

This is a post from JavaBlog.be

Devoxx 08: Major Servlet 3.0 features

One of the most important new features will be the modularization of Java SE7. Modularization is needed because both Java and the JDK have become quite big. This for example gives issues when trying to run it on smaller (mobile) devices. Cutting the JDK into modules will avoid loading unnecessary classes, which on their turn result in shorter start-up times for applications. To print a simple string “Hello world”, Java needs over 300 classes in the current version!.

A list of the other new features can be found here!

This is a post from JavaBlog.be

Devoxx 08: what’s new in Java 7?

Scrum roles

Scrum defines three different roles: the Product Owner, the Team and the Scrum master.

Product owner

The product owner, who’s responsible for the project, has the following tasks:

• he defines the product vision and features
• he plans releases (release dates & contents of a release)
• he prioritizes the needed features in a release according to business/market value
• he’s able to change features and priority of the tasks before the start of every iteration (not during the iteration)
• at the end of a release he accepts or rejects the work results
• he’s responsible for the return on investment of the product.

Team

The team is responsible for the success of every iteration done in a release. Ideally the team consists out of 5 to 9 members. Different profiles are needed: developers, testers, QA guys, infrastructure guys, …

What does the team needs todo?

• they need to select the iteration goal and specify work results
• they have the right to do everything within the boundaries of the project guidelines to reach the iteration goal
• they organize themselves and their work
• they demo the work results to the product owner and stakeholders

Scrum master

The scrum master makes sure that the SCRUM process is followed and understood.
Besides that he also:

• helps the dev team to improve its productivity by facilitating creativety and empowerment
• helps the team improve engineering practices & tools so each increment of functionality is potentially shippable
• helps the customer directly drive the functionality developped
• enables close cooperation between all roles

Scrum process

The full scope of the project is put into a Product Backlog; the list of features to be implemented. This product backlog is input for the Sprint planning meeting.

The sprint backlog defines the scope of one iteration and is derived from the product backlog. It’s defined during the Sprint planning meeting. In this meeting the product owner presents to the team a prioritized product backlog. The team gives estimates of the stories selected for this sprint.

Stories are compared to each other and relative points are given based on the complexity of the stories. (higher points => more complexity). The Product owner and Team negotiate the Sprint goal and the team commits to develop a set of features. Based on these stories the team plans out smaller subtasks.

During the sprint the scope is fixed. It’s the task of the scrum master to protect the team from scope changes. (only the team itself is allowed to change the scope of the sprint!)

Generally a sprint takes 2 to 4 weeks. During the sprint, there is a daily scrum meeting; a short standup meeting where every team member will talk about what he’s busy until next meeting, what he did yesterday and any problems he encountered.

The sprint produces an increment of potentially shippable functionality containing analysis, design, coding, testing and docs.

During the Sprint a burndown chart is created: it displays the amount of work done & work remaining across time. (start with max. number of story points at day 1; then substract story points when a story is fully finished during the sprint time). This allows you to see the progress rate and estimated completion date. One can also see if the team is faster/slower then the “steady pace”. (purple line)

Burn down chart

When the Sprint is finished; there is a sprint review meeting (a demo to the stakeholders) and a sprint retrospective meeting (a lessons learned meeting)

During the Sprint review meeting the team gives a demo to the product owner with the output of the iteration. Ideally this should be done in a pre-prod or production environment.

Present only what is “really” done (clean, refactored, unit-tsted, built, acceptance-tested); otherwise you’ll give a false impression that more is done then what’s reality.

A Sprint retrospective is a kind of Lessons learned meeting: continous improvement by collecting what went well & what went wrong during the Sprint.

You can also revise the development process to make it more effective & enjoable for the next sprint. (eg. processes, practices, communication, environment, artefacts, tools,…)

A release consists of one or more sprints. The contents of a release are based on the continuously updated product backlog. It’s the product owners responsibality to fill in the release, taking into account the actual team velocity. (eg. this team can do 25 points per sprint).

Release planning can be done Time driven (if your release should be ready on a fixed deadline) or feature driven. (select the highest priority items first).

Scrum from theory to practice

You may have difficulty going from theory to practice due to any of the following reasons:

• transitioning to an agile culture
• finding a product owner
• lack of communication between people
• cross organizational boundaries

Scrum doesn’t pretend to solve those issues in your organization, but will make them visible a lot earlier in the project.

An ideal product owner should be able to:

• coordinate the various user requirements
• articulate the vision of the project
• make scope decisions
• be a project sponsor: negotiates & manages the budget
• define priorities and releases
• allocate time for collaboration with the team

For cross department communication, try to get domain/technical experts assigned on the project full-time (can also be part-time if full time is not possible).

This is a post from JavaBlog.be

Devoxx 08: Scrum in practice

Devoxx 08: Xtreme Programming

Comet: Never more!

The title of this talk is a little bit mysterious if you don’t know what Comet is about, but the content is looking very interesting.

The first part of the talk will be about HTML5 WebSockets and Server Side Events. WebSockets will enable full-duplex HTTP communication, and bring an end to the “click and wait” paradigm traditionally associated with the Web.

Attendees will also learn how WebSockets can be used to deliver information from a set of TCP-based backend services, such as Apache ActiveMQ and Jabber to a variety of clients (e.g. Java, Silverlight, and Flash) other than JavaScript.

The second half of this university session will be about deploying and scaling “real-time” Web Applications. Eg. the server and network architecture, performance requirements and scalability of a bi-directional Web application will be discussed.

Check out Jonas Jacobi’s blog for more info!

Filthy Rich Clients: beyond Java

Interested in the new Google Android phone? Then you certainly should not miss this univerity session by Romain Guy.

Romain Guy, who’s now working on the UI design of the Android phones as a Google engineer, always manages to impress the crowd with cool demos and knows what it takes to design a intuitive user-interface.
(which is more important than most programmers think!)

Chet Haase, who works on animation and UI components for the Flex SDK team at Adobe Systems, will likewise describe how to achieve beautiful Filthy Rich Client applications for Flex.

This is a post from JavaBlog.be

Top picks for Devoxx 2008 University day 2