Featured White Papers

• Measuring Risk to Improve Java Software Quality
• Do You Really Get Classloaders?
• Pragmatic Continuous Delivery with Jenkins, Nexus, and LiveRebel
• Your Next Java Web App: Less XML, No Long Restarts, Fewer Hassles
• Coding with JRebel, Java Forever Changed
• 2012 Developer Productivity Report: Java Tools, Tech, Devs, and Data

Sponsored Links

• Graph databases are 1000x faster than relational.

  Learn More!

• Career opportunities at Harman- Careers That'll Rock Your Socks Off.

  Learn More!

• Developer-friendly Java PDF libraries by Qoppa Software

  Live Demos

• Stop blaming your app! Diagnose Java performance issues.

  Free tool >

• UrbanCode: Go From Continuous Integration to
  Continuous Delivery

  Learn More!

Sponsored Links

Optimize with a SATA RAID Storage Solution
Range of capacities as low as $1250 per TB. Ideal if you currently rely on servers/disks/JBODs

AjaxChat: Chatting, the AJAX Way!

Start building your own AJAX-based chat room

By Frank W. Zammetti, JavaWorld.com, 09/11/06

This article presents an AJAX (Asynchronous Java and XML) project done with straight AJAX. That means this application will not be using any library or toolkit—it will just be you and JavaScript! Here we'll build ourselves a nice little multiuser, multiroom chat application, much like the Yahoo! chat rooms. Even better, we'll build this application using Struts on the server to make it that much more interesting!

Requirements and goals

Chat rooms have been with us for a very long time now. In fact, it is chat rooms, those gathering places where you can talk in real time with your fellow computer users, that draw many people to the Internet in the first place (email tends to be the biggest draw, but chat rooms are not too far behind for many people).

If you think about what a chat room application must require, it becomes clear that we'll need a server component. There has to be some broker in between all the chatter that deals with keeping track of the various chat rooms available, who is logged in and chatting in what room, and those types of system-level considerations. More important, though, is some arbiter of messages—a way for all the people currently chatting in a given room to see the various messages.

In a "real" chat application, such as those you might find on AOL, for instance, it is likely that the server actually pushes new messages out to the users in the room. That way, there is no delay between when someone says something and when everyone else in the room sees it.

If you were going to build a purely HTML-based chat application, as we are about to do, you'd have to consider all of these points. However, because the Web is based on a pull model of client-server interaction, ignoring things like applets and such, you clearly need to go about things a little differently. Could you have a meta refresh tag on a page that periodically asked the server for any new messages? Yes, but then you would be redrawing the entire screen each time, which would be rather inefficient, especially if you built it with something like JSP (JavaServer Pages) or another dynamic rendering technology where the server would be responsible for that redrawing.

There must be a better way, and of course there is: AJAX!

The AjaxChat application will have a number of requirements based on these, and a few others, as follows:

• The application must support multiple users and multiple rooms. We won't enumerate any specific scalability requirement except to say that a reasonably sized group of friends should be able to chat simultaneously, so something in the 10-user range should do fine.
• We have seen a number of solutions that use servlets on the back end, so this time, we'll do something a little more interesting and robust and build AjaxChat using Struts.
• We want to be able to adjust the font size of messages displayed in the room we are chatting in, to allow for people (like me!) with bad eyesight to have an easier time of it.
• Just for fun, we want the ability to show our messages in one color and other people's messages in another.
• The server will need to properly deal with things like duplicate users and users who do not properly log off. We won't, however, require a login per se—that is, user accounts will not be created and persisted.
• There should be an option to clear the "history" in a room so that a user can have a clean display at any time.

This should be a fun project! Let's now figure out how we are going to accomplish all that we have set out for ourselves.