Put on Your X-Ray Specs: Converting Web 1.0 to 2.0

This post was previously on the Pathfinder Software site. Pathfinder Software changed its name to Orthogonal in 2016. Read more.

I’ve blogged in the past about converting Web 1.0 to Web 2.0. There were and still are three options:

1. The Christmas Tree Approach – decorate your existing Web 1.0 application with lots of snazzy Ajax widgets. It’s quick, but it’s a bear to maintain.
2. The Version 2.0 Approach – scrap your existing app and develop a Web 2.0 version from scratch. This can take a while and suffers from the same issues that all version 2 projects do, i.e. if version 1.0 has evolved over time, capturing full requirements may be challenging.
3. The Resurfacing Approach – keep your backend logic, but rewrite the interface as a single page, desktop-like GUI.

This last approach has many advantages: it’s quicker and less expensive than #2, but easier to maintain and gives a more unified user experience than #1. It also has some of its own pitfalls. Mostly, the issues are around some of the hidden assumptions of a Web 1.0 applications that expect all interaction to occur through a postback.

So, what’s the plan? How do we go about converting our 1.0 app via resurfacing? To do this you have to put on your X-ray specs, so to speak, and look at the bones of your application. If you’re already using an MVC framework, you’re ahead of the game. So, what are the analytical steps?

1. What are your controllers? If you’re using an MVC framework like Spring MVC or the venerable Struts, then identifying your controllers should be easy. Otherwise, a good rule of thumb is
   that anything that takes parameters via a GET or a POST is likely a controller. If you’re storing lots of stuff in the session or in cookies, you may need to dig a little deeper.
2. What are your views? Again, an MVC framework makes this sort of thing easy to identify. They are the JSP’s or other sorts of dynamic pages that
   display the results of your interaction with the controllers. In some cases there may be a shortcut, where a view is not distinct from the controller, i.e. the view URL takes parameters. Make a note of this.
3. Which of your controllers and views are stateful? In other words, if you have an application that allows you to reserve hotel rooms and then book them, does it make sense to call the controller that handles payment without first having stepped through the workflow that involves the creation of an itinerary, etc.? If you’re keeping lots of state information in the application server session, this is a clue that you probably have some stateful controllers and/or views.

If you have an application map (also sometimes know as a site map) that shows the various interactions and workflows, this can be very helpful in identifying the elements discussed above.

Why have we gathered all of this information? What’s the next step in the plan? The controllers are going to turn into services, i.e. they are going to lose their workflow/navigation function, the views are all going to turn into XML, and the resurfaced front-end will orchestrate these services together.

Over the next couple of posts, I’m going to walk through a sample Web 1.0 application and look at a few of the issues that stand in our way:

• How stateful controllers can cause problems.
• Moving workflow from the server to the client.
• 404, server timed out, reload, and other Web 1.0 usability features
• How to handle history now that your pages are gone
• Security and the Web 2.0 application

Technorati Tags: ajax, web20