Tom's Blog

When should you use Ajax? Whenever you want to create a rich client application with the universal reach of the Internet. Stuart Halloway, speaking Friday afternoon at this fall's Northern Virginia Software Symposium, predicts Ajax will be part of nearly all web applications within the next year. Stuart's first session of the day focused on the architectural issues involving Ajax, from technical features to selling Ajax to management. In 90 minutes he discussed:

• the reasons to use Ajax
• how to introduce Ajax at your company
• the resistance you'll encounter when you do
• the tools and libraries to use in Ajax development
• the architectural decisions you'll need to make
• how Ajax isn't a panacea for all applications

Stuart demonstrated Ajax in action by showing how to build several incarnations of a web form that, once you input a U.S. Zip code, the address's city and state fields fill in automatically from an asynchronous JavaScript server call. Low-tech stuff compared to Google Maps, but simple enough to demonstrate several ways to get the job done.

The interest in Ajax has been increasing over the last couple of years not because of a breakthrough in technology, Stuart said, but because of a breakthrough in how we look at using asynchronous JavaScript to make web forms more dynamic. Instead of having web user-interface developers deal with the vagaries of the different browser versions, different implementations of JavaScript, different implementations of Cascading Style Sheets, and different implementations of the web page document object model, they learned in February 2005 from Jesse James Garrett to hide browser differences behind an adaptive interface provided by a library like Prototype or Dojo. Garrett coined the term Ajax in his seminal paper, "Ajax: A New Approach to Web Applications." Of course, it also helps, Stuart added, that the functionality provided by Internet Explorer and Firefox have converged over the years.

The reason to use Ajax in your web applications is to create a better experience for your users. Ajax allows your web page to communicate to the server in order to update the page "behind the user's back," making the application more responsive to the user's actions without having to reload the page.

The best way to introduce Ajax at your company, he said, is in non-core web applications. Depending on your company's culture, Stuart said, you can sell Ajax either as proven technology -- XML, HTTP requests, and JavaScript -- or by saying "Ajax is the revolution and we're all on board." When introducing Ajax, he said, stay "degradable." That is, ensure your web application still works if the user turns off JavaScript or uses a browser that doesn't support it. The fewer negative issues you create, the more the benefits will shine through and convince others to introduce Ajax into more web applications. If you want to be conservative, he said, wait until the web MVC frameworks, like JavaServer Faces, provide better support for Ajax in their page widgets.

Stuart mentioned several open source development tools and JavaScript libraries to use in your Ajax applications:

• Firefox
  Consider the Firefox browser (with its extensions that follow) your development platform and Internet Explorer as your deployment platform, Stuart said.
• JavaScript Shell
  a Firefox bookmarklet that allows you to dynamically run JavaScript statements against your current page in a debugging window. This tool is useful, Stuart said, "for poking around the page to figure out what's broken."
• FireBug
  a Firefox add-on with debugging features to monitor your page's JavaScript, CSS, and HTML. One feature allows you to spy on all HTTP traffic JavaScript functions send to the server.
• Web Developer
  a Firefox add-on toolbar that allows you to disable JavaScript, cookies, view and modify a page's CSS, view a page's generated source rather than the HTML originally loaded, and a host of other useful development tools.
• Tamper Data
  a Firefox add-on that logs all web navigation. It not only allows you to see what requests and responses are traveling between the Ajax components and the server, but it allows you to modify them or completely stop the request and see how the application reacts.

Ajax Libraries

Stuart mentioned several Ajax libraries. Since JavaScript libraries generally don't trample on each other, he said, you can often use more than one in a web application.

• Prototype
  A survey at an Ajaxian conference showed that more than half of the Ajax developers were using Prototype, Stuart said. Most of the rest were using Scriptaculous (next). Prototype allows you to register multiple event handlers to events (Event.observe()). You can register events outside of the HTML widget to allow you to separate concerns: your HTML page designer doesn't have to worry about coding the JavaScript events. Prototype also provides the Ajax.Request function that works as a factory to return the appropriate function that works with the user's browser version.
• Scriptaculous
  A library built on Prototype to provide page effects (highlight, fade), drag and drop, auto-complete and other features.
• Dojo
  This is a heavy-weight "kitchen sink" library, Stuart said, that provides almost everything you need for an Ajax application.
• Google Web Toolkit
  This toolkit allows Java developers to build front-end components in Java. The toolkit converts the Java code to JavaScript and HTML.
• Direct Web Remoting
  Stuart said DWR is No. 3 in popularity, behind Prototype and Scriptaculous. It's Java RMI like. You write JavaScript stubs that run in the browser and make RMI calls to the server. It assumes you have Java running on the server side.

Introducing Ajax into an application raises two key architectural questions, Stuart said. These are the questions to think about early and thoroughly because changing the answers later could undermine previous development work.

1. What to send on the wire?
   When JavaScript calls to the server for updated information, does the server send back HTML, XML, JavaScript, or JSON? HTML is view centric, JavaScript is code-centric, and XML and JSON are model-centric. (See also this blog for a discussion.)
   
   Stuart said he believes 95% of all Ajax traffic soon will be HTML. It's developer-efficient (no parsing and XML creation) and the snippet of HTML can simply be rendered on the page. JSON will dominate applications that focus on data exchange because it is easier to parse than XML. XML will be the loser. Sending back JavaScript allows you to send back code that the browser would evaluate.
   
   
2. What library to use?
   Choose a library that supports the features you need. The library should hide the browser differences in the XMLHttpRequest. Prototype does this and builds upon JavaScript to make it more like a regular programming language.
   
   Use Scriptaculous if you need to adds page effects and you'd like to use its widgets.
   
   Dojo is the library beloved by Java programmers, Stuart said. It's bigger than all the other libraries, but it does more. Its API provides fixes for Back-button issues, client-side data storage, and other features.
   
   Stuart dislikes Google Web Toolkit. "I think it's architecturally wrong," he said, but I think I zoned out when he described the reasons for his dislike.
   
   

Although Ajax is useful, it won't be a panacea for all applications, Stuart said. Learning to design with Ajax correctly will involve some of the same growing pains the development community learned in creating n-tier applications. Stuart likened the future growing pains in the Ajax world to the pains Java programmers suffered in implementing n-tier web applications using EJB. "We're going to make a ton of mistakes" implementing Ajax applications, he said. "Asynchronous is hard. Asynchronous is as hard as threads, except you don't have an API in front of you reminding you how hard it is."
Saturday November 04, 2006 Permalink Today begins the fall session of the Northern Virginia Software Symposium put on by No Fluff Just Stuff (Jay Zimmerman and crew). That means I have to decide which one of the six concurrent sessions to attend in each time slot. That means I have to decide which of five sessions to miss during each time period.

Today has three time slots in the afternoon, followed by an after-dinner keynote by pragprog co-founder Andy Hunt. For the 1:15 p.m. session, I'd like to attend Stuart Halloway's "Ajax Architecture" session, Brian Goetz's "Java Performance Myths" session, and Venkat Subramaniam's "Open Source Tools for Agile Development" session. I'm not a web UI designer, but knowing the browser's asynchronous JavaScript abilities would help on a current project. We want to add dynamic page updates to an existing web application. The design of the server code I'm working on will be affected by what services the client needs. Brian Goetz's session promises to show how common Java idioms we use, thinking it helps the Java compiler optimize our code, actually make it harder for the JIT compiler to figure out how to optimize. Venkat Subramaniam will recommend open source tools he finds most useful to develop code and improve its quality. The open source world changes so fast, it would be good to get these tips from the good doctor.

See how hard Jay makes it to decide which session to attend? I'm leaning toward Stuart's Ajax session just because it's the area I know the least about. I'd like to know what cool features Ajax libraries Prototype and Scriptaculous provide.

Later in the afternoon, Venkat has sessions on test-driven design for Spring applications and working with rules engines. But these sessions conflict with sessions on how Acegi supports JavaScript for better user authentication interaction, and a session on Jini (the technology whose coolness keeps it alive despite being almost wholly ignored for years). Decisions, decisions.

I plan to blog more this weekend on the sessions I attend and what I learn.


Friday November 03, 2006 Permalink When I blogged in September about using the Java threading classes introduced in Java 1.5, I didn't know a similar library was available in Java 1.4. It is, courtesy of the backport-util-concurrent package maintained by Dawid Kurzyniec at Emory University.

The package provides versions of most of the java.util.concurrent classes, but converted to Java 1.4. The key feature missing is the ability to use generics. For example, using Java 1.4, you can't define a Callable anonymous inner class using syntax like:

   void showSearch(final String target) throws InterruptedException {
     Future<String> future = executor.submit(new Callable<String>() {
         public String call() { return searcher.search(target); }
     });
     displayOtherThings(); // do other things while searching
     try {
       displayText(future.get()); // use future
     } catch (ExecutionException ex) { cleanup(); return; }
   }

to specify the call method returns a string, as in the above code excerpted from the Java 1.5 API for the Future interface. And, of course, you can't define a Future of type string that would be returned from the ExecutorService's submit method, as shown above. Without generics, you're confined to returning Objects and casting them to the expected type. You don't get the compile-time validity checking provided by Java 1.5 generics, but most Java developers are used to using narrowing casts like this.

This backport of the concurrent package came in handy this week when I wanted to use its features on a project that had to run in Java 1.4. It seems a lot of code from Java 1.5 has been backported to earlier Java versions, like Java annotations. Thank you, Dawid and Emory, and thank you for releasing the code into the public domain so the code may be "may be freely reproduced, distributed, transmitted, used, modified, built upon, or otherwise exploited by anyone for any purpose, commercial or non-commercial."

UPDATE 7 hours later:

I should mention that some of the code for the backport, as well as much of Java 1.5's java.util.concurrent package, came from Doug Lea's util.concurrent package. I woke up this morning and realized I had neglected to mention where the initial ideas for the Java 1.5 concurrency classes came from. Professor Lea, from the State University of New York at Oswego, created most of the ideas and code behind the improved multi-threading techniques that made it into Java 1.5. He also is a co-author of Java Concurrency in Practice, which Stuart Halloway recommended in my September 27 blog as being a great source to learn the effective use of the Java 1.5 concurrency package (and thus the backported version).

The benefit of favoring the Emory University backport over Doug Lea's original code is that code using the backport allows a smooth transition to Java 1.5. The transition mostly would involve renaming your imports. The backport's class names and APIs are identical to what's in Java 1.5. Doug Lea favors using the Emory backport over his older util.concurrent package.


Wednesday November 01, 2006 Permalink Like most tech geeks, I own multiple domain names and dozens of email addresses. I have configured many of my email servers with "catch-all" or wild-card forwards that allow mail sent to any address at a particular domain to be delivered to a particular inbox. One of my uses for this setup is to allow me to use unique email addresses when I give out my email address to online businesses. Doing so allows me to filter incoming email, immediately gauge the priority of email, and track if my email addresses leak beyond the online company with which I originally shared it.

With two notable exceptions, email addresses I have given out to companies end up being used by them only for legitimate business communications. The two recent exceptions: Addison-Wesley and Lands' End. Spam is making email less and less useful each passing month as hundreds or even thousands of spam messages flood my inboxes daily. I always thought of the people who sell or trade email addresses for spam use were faceless individuals operating from their living rooms, not major companies like Addison-Wesley and Lands' End or their affiliates.

With Addison-Wesley, I signed up for an email list several years ago for announcements of new technology titles. For a while, I received emails from Addison-Wesley every month or so announcing its latest technology books. The mailing list was low-volume and useful.

I no longer receive announcements of new books from Addison-Wesley. But the email address I gave them is now used by spammers several times a day to send me unsolicited commercial email messages. Here are some headers to a spam email I received tonight advertising "Cheap Vl x AG x RA"

Return-Path: <olmedaa@iskiv.net>
Received: from iskiv.net (lns-bzn-22-82-249-89-146.adsl.proxad.net [82.249.89.146])
    by [my email server] with SMTP id k9T7mmeJ029902
    for <awbookalert@[my domain]>; Sun, 29 Oct 2006 07:48:54 GMT
Reply-To: "Romano Wischmeier" 
From: "Romano Wischmeier" 
To: awbookalert@[my domain]
Subject: Re: 693

Now, with an email address like "awbookalert," you figure no spammer stumbled onto this address by guessing. More likely, the spammer purchased the address from someone who stole it from Addison-Wesley's computers, or Addison-Wesley gave it away or sold my email address for use by spammers. I consider it unlikely this email address was stolen from my computers because I use several "alias" email addresses and have had a problem only with this one I gave to Addison-Wesley.

I checked Addison-Wesley's privacy policy to see if they protect email addresses as private information. You know what? They don't. Addison-Wesley treats as private "your name, address, phone number, date of birth, job, personal interests, and credit card information," but your email address is not covered by Addison-Wesley's privacy policy. Addison-Wesley, and parent company Pearson Education, should be ashamed to have a privacy policy like this where email addresses are not held in confidence.

Another company contributing to spam is Lands' End. My wife ordered clothing a few weeks ago online from Lands' End, again using an email address unique to this one transaction. Lands' End sent two emails to this address: an order confirmation and a shipping notice.

Last week, though, she received an email sent to this unique address from a company advertising self-confidence books. Her thought was Lands' End either suffered a computer security breach, and the thieves sold her email address to spammers, or this publishing company is affiliated with Lands' End. Lands' End's privacy policy acknowledges the company shares private information with business partners. My wife called Lands' End to find out how this publishing company obtained her email address.

The Lands' End customer-service representative my wife spoke with assured her the publishing company is not affiliated with Lands' End, and that Lands' End experienced no data security breach. The spam must have originated, she said, by someone breaking into her ISP's email server and stealing that address.

Yeah. Uh huh. Someone broke into an email server and stole a solitary email address. These thieves overlooked the dozens of other email aliases on her server and focused solely on this one email address she shared with Lands' End. (Her email server is different from mine, by the way, eliminating the possibility that a single server was the source for both these email addresses picked up by the spammers.)

If Lands' End's computers were not broken into, it seems likely one of its business partners is using email addresses in ways not sanctioned (or at least acknowledged) by Lands' End. A possible partner could be Coremetrics, a company that provides website analytics for Lands' End. Lands' End says they share website information with Coremetrics, but the "data that they collect for us [cannot be used] for any other purpose." Interestingly, the self-help publisher who sent my wife the spam also is a Coremetrics customer.

I don't want to cast aspersions on Coremetrics. They have many online retail customers. What I want to ask Lands' End is which is more likely:

• Hackers broke into two of our ISP's email servers and stole one email address from each?
• One of your business partners is violating the confidentiality of your customer information?
• A hacker broke into your computer system and stole information?

I would think the likelihood of the latter two scenarios to be much higher, and a much higher concern to Lands' End.

If companies don't want to suffer black eyes when the public discovers how casually or carelessly they treat their customers' information, they need to start treating data privacy more seriously. The alternative, they will find, is that Congress will receive enough pressure from Americans so fed up with spam and identify theft that they will tighten data-privacy laws to make it a criminal offense when what should be private data leaks from their computer systems. When the first CEO goes to jail for contributing to spam or identity theft because the company treated customer data carelessly, perhaps that's when we'll see companies treat customer data with more seriousness and care.


Sunday October 29, 2006 Permalink Comments [3] The United States Air Force finally has a memorial in the nation's capital. The memorial was dedicated Saturday in a ceremony attended by President Bush and other dignitaries. The memorial honors those who have served and those serving in the Air Force. Its triple stainless steel spires soar to varying heights up to 270 feet in a "bomb burst" flaring-out pattern, "truly representative of flight and the flying spirit of the Air Force."

The memorial sits on a small hill between Arlington Cemetery and the Pentagon, and is visible from I-395 on the left as you approach Washington from Virginia. An approximate location is marked by this Google map. (If you view the map, the memorial is actually where Columbia Pike bends north toward Southgate Road.)

The weekend ceremonies were by invitation only, although the public was invited to view Saturday's ceremony remotely from big-screen TVs set up in the Pentagon South parking lot. The Washington Post has a video of the event.

Rather than watch from the parking lot, my wife and I viewed the airplane flyovers accompanying the event from the Mount Vernon Trail next to National Airport. Yes, they had to temporarily shutdown commercial air traffic for the event, as vintage and modern war planes flew overhead, capped off by a flyby from the Air Force's Thunderbirds. (Photos below.)

Ceremonies continued this morning with a memorial service. The service included a wreath-laying ceremony and a flyover (right) from four Air Force F-16s in a missing-man formation.

The memorial opens to the public on either Monday or Tuesday. (The Washington Post says Tuesday. The A.F. Memorial Foundation says Monday.)

Here are some of the other photos we took of the events.


Bicyclists on the Mount Vernon Trail look toward the memorial in the distance.


A Consolidated B-24 Liberator makes a flyby. Apparently, this is the only restored Liberator still flying.


A B-2 Spirit bomber made an approach from the east. My wife caught this picture just as it flew into the sun.


The B-2 banked right as it flew over the memorial. This is the first time I've seen a stealth bomber in flight. You can really see how the plane's thin profile helps foil radar echoes.


This photo from this morning shows the F-16 'missing man' formation as it flew over our apartment.

Updated at 10:50 p.m.: I earlier labeled the B-2 bomber as an F-117A. I'm pretty sure it's a B-2, thanks to Chris Nokleberg's comment.


Sunday October 15, 2006 Permalink Comments [2]