You are currently browsing the monthly archive for April 2009.

The world of dynamic web applications offers various ways for a client and server to interact. Two approaches are particularly well suited for situations when information on the server changes frequently. These approaches are: HTTP Streaming, and Client Polling (JavaScript Polling).

In HTTP streaming, the client/server connection is left open for an extended period of time so that data is streamed from the server to the client. This approach is also known as server-side push, reverse Ajax, or comet. As information changes on the server, updates are pushed to the client.

With Client Polling, the browser periodically issues an XMLHttpRequest call to obtain new information from the server. For example, a client can send an XMLHttpRequest to the server every five seconds to get new information. This approach is also known as periodic refresh.

Look at this, Using a Javascript-Centric View Tier. Demo: here.

Or you want to try the reusable component, Poller – YUI3 Component

Reference:
JavaScript Timing Events

Last time I posted Using server push in general. This post I focus on Java server-side implementation.

First We talk about AJAX Push. Ajax Push enables real-time collaborative features, because everyone can be instantly aware of each others actions. The underlying mechanism for Ajax Push is HTTP protocol inversion (also known as long polling). This technique involves holding a connection open from the browser client to the server with a blocking request, and then fulfilling that request when some state change in the application triggers an update to the presentation. For more, see here.

How do we use it at Java web server? basically the server needs to implement so called Asynchronous Request Processing. What happens in synchronous HTTP where the server is blocking on incoming and outgoing I/O is that you end up having a thread consumed per client connection. This eats up memory and valuable thread resources. Therefore, each server has their way to handle those problem.

1. Apache Tomcat 6 Comet Processor and JBoss 4.2.3
Asynchronous HTTP Request Processing

2. Sun Glassfish Grizzly Plugin
Grizzly part III: Asynchronous Request Processing (ARP)

Reference:
Asynchronous Ajax for Revolutionary Web Applications

Update: 2009-06-02
Developing with Comet and Java

My friend said “Look, the HTTP response from Goolge is strange!”.

Google’s Web site responds:

HTTP/1.1 200 OK
Server: GWS/2.0
Date: Tue, 21 May 2002 12:34:56 GMT
Transfer-Encoding: chunked
Content-Encoding: gzip
Content-Type: text/html
Cache-control: private
Set-Cookie: PREF=ID=58c005a7065c0996:TM=1021283456:LM=1021283456:S=OLJcXi3RhSE;
domain=.google.com; path=/; expires=Sun, 17-Jan-2038 19:14:07 GMT

(Web content compressed with gzip)

I told him “Have you experience the web page slow? then try to use HTTP compression”.
Of interest in this response is that the Web content is of a format that cannot be printed, binary. Because my browser specified in its request that it accepts gzip (GNU zip) encoding, Google chose to encode the response with gzip. This is a popular compression algorithm that allows for a quicker transfer due to the smaller size of the HTTP response. Again this is very common skill but it’s useful.

Reference:
1. Using HTTP Compression

2. HTTP Compression Speeds up the Web

3. Compress data streams in Java with GZIP and Zip

4. Compressing web content with GZip and Filter

5. Speed up your Web pages

1. JFreeChar

2. Open Flash Chart

3. AmCharts – flash view

4. Ejschart – Pure Javascript chart tool

5. JS Charts – Free Javascript Chart Generator

update: 04-14-2009
You can choose between web generators, flash, javascript libraries, Silverlight or PHP classes.
25 great free resources for making charts

Before Rich Internet Application (RIA) comes to web application, we have to deal with the HTTP rule to handle flow within pages. My friend doesn’t know the problem why page control is so difficult. I think it is great to review those scenarios.

1. HTTP is stateless and synchronous. When user is adding stuff into shopping cart, you need to do session tracking. Because page and page needs to share user’s state.

Beginning HTTPSession from novice to professional.

2. When user submits the shopping form, and send to server, you need to know how to do with success, fail, or redirect from server. The user experience doesn’t have nervous to your response. Here is some useful tips.

Redirect After Post
GET after POST
How to redirect a web page, the smart way
Use standard redirects: don’t break the back button!
Redirect in response to POST transaction

3. When your pages have to keep server-side navigation history of visited Web pages and visited named sequences of Web pages, also known as Web flows. Web flows is more complicate, so I usually recommend to adapt framework.

Enable backwards navigation through Web applications
Spring Web Flow 2: A boon to JSF developers
Spring Web Flow for better workflow management in JSF
Spring Web Flow Examined

You may ask “Why should I know this?”, because those are the basic HTTP concept, and if you are interested, you can think more how they work in AJAX and RESTFul service. Enjoy!

Most Java developers use HTTPSession to store the state. We know how to store it and invalid it. But we don’t think about how it works.

1. What is session and why do we need it?
A session is a series of requests to a servlet, originating from the same user at the same browser. Sessions allow applications running in a Web container to keep track of individual users. For example, a servlet might use sessions to provide “shopping carts” to online shoppers. Suppose the servlet is designed to record the items each shopper indicates he or she wants to purchase from the Web site. It is important that the servlet be able to associate incoming requests with particular shoppers. Otherwise, the servlet might mistakenly add Shopper_1’s choices to the cart of Shopper_2.
A servlet distinguishes users by their unique session IDs. The session ID arrives with each request. If the user’s browser is cookie-enabled, the session ID is stored as a cookie. As an alternative, the session ID can be conveyed to the servlet by URL rewriting, in which the session ID is appended to the URL of the servlet or JavaServer Pages (JSP) file from which the user is making requests. For requests over HTTPS or Secure Sockets Layer (SSL), Another alternative is to use SSL information to identify the session.

2. Session tracking options
There are several options for session tracking, depending on what sort of tracking method you want to use:
* Session tracking with cookies
* Session tracking with URL rewriting
* Session tracking with Secure Sockets Layer (SSL) information

3. Distributed sessions
Web applications often keep state in HTTP session attributes. Depending on the nature of your application, you may keep all your application state here or, perhaps, only login credentials and presentation state. Nonetheless, if you want a totally fault tolerant application, you need to make sure your web session state is replicated. Especially we want to use at load balance or clustering.
For example. Some wbe server (i.e WebSphere or JBoss) provides
* Database Session persistence
* Session replication
capable of replicating HTTP session state.

4. Best practices for using HTTP Sessions
* Release HttpSession objects using javax.servlet.http.HttpSession.invalidate method when finished.
* Avoid trying to save and reuse the HttpSession object outside of each servlet or JSP file.
* Implement the java.io.Serializable interface when developing new objects to be stored in the HTTP session.
More details can be found at reference.

Reference:
What is Session Tracking?

Using the HttpSession object of the Servlet API

Best practices for using HTTP Sessions

2 Ways To Implement Session Tracking

JBoss – HttpSession Replication

update: 2009-05-20
State replication in the Web tier