Web 2.

0 application architecture
Sas Jacobs

Web 2.0 application architecture

As a developer, you may have heard of the term Web 2.0 to describe a new approach to Web sites and Web applications. Web 2.0 applications are responsive, have rich user interfaces and involve user participation in some way, often by allowing for user input and tagging of content. This is quite different to traditional or Web 1.0 applications. Web 2.0 introduces Web developers to a range of newer approaches in application development. These include new technologies, new architectures and new toolkits for creating Web applications. For example, Flash and Flex allow developers to create rich internet applications that use the Flash Player. The Ajax approach allows Web applications to load data in the background while the user carries out other tasks. In this article, I want to cut through some of the hype and look at some of the key points about Web 2.0 application architectures. Well see how this architecture differs from Web 1.0 applications and look at some of the key points for developers to consider. Lets start with a comparison between Web 2.0 and Web 1.0 (traditional) applications.

Web 2.0 applications

Web 2.0 applications usually involve the following. They are delivered through a Web browser using approaches that support Web standards. They are responsive to a user, often in a similar way to desktop applications. They use rich application interfaces, often including pre-built components and widgets. These characteristics are quite different from those in Web 1.0 applications. In fact, the only thing that the two really have in common is that both are delivered through a Web browser!

Differences between Web 1.0 and Web 2.0 applications

In Web 1.0 applications, a Web page is the basic unit of the application. Every event that happens in the application is represented by a page. For example, we might need one page to log in to an application, a separate page to view the latest news summary and yet another to view the details of a single news item. Each time the user carries out an action and requests a new page, the Web server responds by returning another Web page or by refreshing the current page. For every user interaction, the entire browser window is refreshed, including any fixed interface elements that dont change from page to page, such as global navigation. Obviously, it takes the server longer to provide the entire page compared with if it could just load the updated data.

Copyright 2004 DMXzone.com All Rights Reserved To get more go to DMXzone.com

Page 1 of 6

Web 2.0 application architecture

Sas Jacobs

The following diagram shows browser and server contact in Web 1.0 applications.

Web 2.0 applications, on the other hand, take advantage of technologies that dont require the full refresh of a page each time new data is requested. Instead, a page can be broken down into smaller components, widgets or sections. Events that occur within these component parts can trigger the loading of new data WITHOUT a full page refresh. Only the part of the interface displaying the changed data is reloaded. The fixed portions of the interface stay put. The following diagram shows the different approach taken in Web 2.0 applications.

This difference will probably become a little clearer with an example.

An example
Lets use the example of a user login form to illustrate the differences between Web 1.0 and Web 2.0 approaches. In a traditional Web 1.0 application, the user fills in the form and clicks the submit button. Client-side code, usually JavaScript, determines that all entries are valid. If not, the user sees an alert box indicating that there is an error. Processing on the page stops until the user clicks OK to try another entry. If the JavaScript validation succeeds, the details from the form are sent to the Web server. The user waits while the server responds and updates the browser. The server checks the availability of the username. If the name is unavailable, the full application interface is sent back to the user including a message that indicates that the username is not available. If the username is available, the server returns the full interface including a message of success.

Copyright 2004 DMXzone.com All Rights Reserved To get more go to DMXzone.com

Page 2 of 6

Web 2.0 application architecture

Sas Jacobs

If the user picks a username that isnt available, they dont find out until after the server has responded. That means they have to wait to find out that theyve been unsuccessful. Its possible that a user will have to repeat this process several times to find a username that has not been taken already. The diagram that follows indicates this process.

In a Web 2.0 approach, we still use the basic components of a Web application we have a page, form fields and a submit button. However, its there that the similarity ends. In this approach, there is no need to reload the page after requesting username information. After the username has been entered, the blur event (leaving the username form field) can trigger the validation of the entry. The first level of validation can check that the username meets requirements, for example, that it is of a minimum length. If the entry isnt valid, a message can be displayed in a small part of the interface, such as a <div> element. The application can also disable the submit button to prevent the page from being accidentally submitted to the server. If the entry is valid, JavaScript can then request information from the server about whether this username is available in the database. This request can occur asynchronously, as the user is entering their password. The application can display a message indicating that the username is being checked and can also disable the submit button while this process occurs. If the username is available, a success message can be displayed in a <div> element and the submit button can be enabled. Otherwise, the user can see an error message in the <div> element and the submit button can be disabled.

Copyright 2004 DMXzone.com All Rights Reserved To get more go to DMXzone.com

Page 3 of 6

Web 2.0 application architecture

Sas Jacobs

The following diagram shows the Web 2.0 approach.

In the

Web 2.0 approach, you can see that weve used: Small server-side tasks such as checking usernames Client-side events to trigger actions e.g. leaving a form field Asynchronous requests to the server i.e., they occur in the background and dont stop processing Updates to small parts of the interface e.g., a <div> element Enabling and disabling the interface in response to user and server events

These are classic parts of a Web 2.0 application. One of the key points to pick up from a Web 2.0 perspective is that there is a big change to the role of client and server compared with Web 1.0 applications. There is also a change to the role of pages and page components.

The role of client and server

Within Web 1.0 applications, the interface and data are tied together so that the Web server is responsible for delivering both to the Web browser at the same time. The client browser provides a means for viewing both the interface and the data but the two cannot be refreshed separately. Web 2.0 applications, however, separate the data from the presentation layer in much the same way as XHTML and CSS. In Web 2.0 applications, the Web server delivers the interface once. The browser can request new or updated information from the server and then manipulate or redraw the interface as required using client-side scripting, usually JavaScript. The following table summarises the main changes to role of server and client between Web 1.0 and Web 2.0 architectures. Web 1.0 Data and the application interface are tied together. When data changes, the interface must be reloaded. The server delivers the application and interface each time a page is loaded. The server hosts the interface and data. Web 2.0 The interface is independent of data. Changes to data dont require that the entire interface is refreshed. Data can be served from a different domain to the interface. The server delivers the interface once and has an ongoing role in providing data. The client hosts the interface and the server hosts the data.

Copyright 2004 DMXzone.com All Rights Reserved To get more go to DMXzone.com

Page 4 of 6

Web 2.0 application architecture

Sas Jacobs

Components vs pages
In Web 1.0 applications, each page is a state in the application. Events occurring within the application are tied to the reloading of a page. For example, new data is requested and displayed by reloading the page. The same is not true for Web 2.0 applications. These applications are made up of a set of components, widgets or page sections that can operate independently from one another. Any event associated with these components can trigger a request for new data. For example, a button click or entry into a text input can trigger a request for new data from the server. Because this can happen asynchronously, the user doesnt need to stop and wait for the page to reload to see the new content.

Asynchronous communication
A key concept behind Web 2.0 is asynchronous communication. This means that a page doesnt have to stop and wait for the communication from the server while data is being requested and provided. Web 2.0 approaches such as Flash/Flex and Ajax allow this to occur. When a user interacts with a component on the page, their interaction can trigger a script that requests information from the Web server. Another script can respond when the server sends back the information. Because the Web application doesnt wait around for the response, the user can continue working without being aware that data is being exchanged. In the previous example, after a user chooses their username, the act of tabbing past that input box i.e., losing focus, could prompt a request to the server to check if the username is available. While the user is entering their password, the response is delivered back to the page.

Implications
Using asynchronous communication in an application means that a developer has to be a little more aware of the application interface. The page refresh no longer acts as a cue to the user, indicating that something has changed. Web 2.0 developers need to consider the following when creating their interfaces: Providing notification that processing is occurring Marking changed information on the page Disabling and enabling interface elements appropriately In some cases, users need to be informed that processing is taking place. This might involve a simple message in a <div> element indicating that an action is taking place. In the login form, we display a message to indicate that we are checking the username. By displayed the message in a <div> element rather than in an alert box, the user does not need to stop processing to respond. After data is provided to the interface, users need to be able to identify whats new. This can involve changing the colour of the new data for a period of time or displaying a simple message, for example, indicating that the chosen username is unavailable. The interface could use other visual cues including flashing or blinking, or using a colour not used elsewhere in the interface, or any combination of these. Users also need to disable and enable interface elements so that only the available functionality is provided to the user. For example, if its not possible to submit a form until after the username is checked, the script calling the server to check the username should also disable the submit button. The button should not be enabled until its clear that the user can proceed. Web 2.0 application interfaces are likely to require a little more thought and scripting for developers compared with Web 1.0 interfaces.
Copyright 2004 DMXzone.com All Rights Reserved To get more go to DMXzone.com

Page 5 of 6

Web 2.0 application architecture

Sas Jacobs

Advantages of Web 2.0 architecture

One of the big advantages of the Web 2.0 architecture is that developers can build applications that are responsive to the user and their actions. The user doesnt have to wait for a server response each time they take an action on the page. There is no more stop-start when working on the Web. An advantage for developers is that the popularity of this approach has seen an increase in the number of tools available for creating Web 2.0 applications. There has also been an explosion in components and widgets that provide great functionality to the user. Adobe recently released the Flex Builder framework to assist developers of SWF applications in much the same way the Visual Studio .NET assists .NET developers. The framework provides an excellent drag and drop environment for creating interfaces as well as shipping with some advanced components for use in Web 2.0 applications. In addition, there are large numbers of JavaScript libraries and toolkits, including those that link with server-side languages and those that create user interface widgets.

Disadvantages of Web 2.0 architecture

The Web 2.0 architecture does bring associated problems. It requires developers to learn new skills and rethink the way they approach the development of Web applications. It can also require more programming than in traditional approaches. Using Flash/Flex to build Web 2.0 applications means that users need to have the Flash Player installed to see content. Relying on the Ajax approach places a heavy burden on developers in writing JavaScript that copes with the vagaries of modern Web browsers.

A caution
Developers need to be careful in their adoption of Web 2.0 approaches. Web 2.0 architecture is not suited to all types of applications and in some cases, a more traditional approach might be appropriate. Just because technologies are available, doesnt imply that they should always be used. Flash and Flex are great tools but shouldnt be used just because theyre new or cool. Similarly, Web 2.0 introduces us to a range of new user interface components and widgets, as well as encouraging applications to respond to a range of events. We need to be careful not to ignore existing controls as users are familiar with them. Completely reworking interface elements and relying on a wider range of events has the potential to confuse users and thus make Web applications harder to use.

Conclusion
In this article, weve looked at the architecture thats normally associated with a Web 2.0 application. Weve examined the differences in the roles of the client and server in Web 2.0 compared with Web 1.0. Weve also looked more closely at asynchronous communication and that implications arise for Web interfaces. If you want to determine if an application is really Web 2.0, try out the validator at http://web2.0validator.com/. Its a bit of fun!

Copyright 2004 DMXzone.com All Rights Reserved To get more go to DMXzone.com

Page 6 of 6