Direct from Web 2.0

Web 2.0 Re-examined: Part 4 - Web 2.0 Technology Stack

December 18, 2006 – 4:02 am by coachwei | Category web 2.0 | 6 Comments »

Web 2.0 Re-examined: the Paradigm Shift, Technology Stack and Business Value

The Rise of a Web 2.0 Technology Stack

The Fundamental Flaws of Web 1.0

Web 1.0 was designed for sharing and browsing hyper-linked documents. Its technology stack serves this purpose well. However, it was never meant for applications and has following limitations:

1. The “click, wait and page refresh” interaction model: This user interaction model is designed for document browsing, not for interactive applications. Interactive applications require “stateful” computing that features incremental updates and asynchronous communications.
2. Lack of support for two-way communications: the web 1.0 communication based on HTTP is a client-pull model that can be initiated by the client only. Server can not initiate communications with clients. A good analogy to this model is a phone system that can only receive calls but not make calls. This one-way communication model is fine for browsing. However, a lot of applications require two way communications (client pull as well as server push).
3. Lack of support for messaging reliability: A lot of business applications have a certain level of messaging reliability requirement beyond what web supports, For example, only and only once delivery, guaranteed order of delivery and guaranteed delivery. The highly distributed and heterogeneous nature of the Internet means that it can not guarantee any of such. The frequent network disruption of Wi-Fi and wireless data services makes the problems even worse.
4. Lack of support for mobile devices: mobile web was an afterthought during web 1.0. Over the years, the industry has tried many different approaches to make the web available and useable on mobile devices, such as web clipping and WAP.
5. Lack of support for accessibility: HTML itself does not offer good accessibility support. It mixes visual presentation with data and provides no clear semantic ways of indicating the meaning of different elements so that accessibility tools can convey to users. Browser vendors have done a lot of workaround to make the web accessible, though significantly limited by the underlying inefficiencies.
6. Lack of support for rich user experience: The complexity of business applications requires much richer interactivity than standard browsing experience.
7. Lack of support for offline computing

The problems of web 1.0 have not gone unnoticed. Many developers have tried many different “hacks” to deal with various aspects of the problems, such as writing JavaScript widgets for richer user interface and using techniques like “comet” to provide two-way communications. To a large degree, the rise of Ajax precisely indicates how web 1.0 does not deliver what people are looking for as the web moved beyond browsing.

The Web 2.0 Technology Stack

Web 2.0 introduces a technology stack that addresses the flaws of web 1.0 and delivers the “architecture of partition”. This new stack includes three building blocks:

1. Application Client Container: the client engine for running rich web 2.0 applications;
2. Internet Messaging Bus: a bi-directional reliable messaging layer.
3. Enterprise Mashup Server: the middleware that enables mashing up heterogeneous data, services and business processes.

From Browser to Application Client Container

“Application Client Container” is the client engine for web 2.0 applications. Many of the Ajax toolkits available today are early example of such client engines.

What is an Application Client Container (ACC)?

1. ACC is stateful. A web browser is designed to be stateless – it discards all the current state information when a new page is loaded. This is the model of “browsing”. Applications are inherently stateful. To support stateful applications on top of the stateless browser engine, developers have to do a lot of hacking to work around the problem. ACC gives applications such support out of box.
2. ACC supports asynchronous interactions by default while browsers require careful developer coding to do so;
3. ACC can support offline computing while web 1.0 applications are online only.
4. ACC supports mobile computing as a first class citizen.
5. ACC supports accessibility.
6. ACC supports rich user experience.

There are 180 JavaScript libraries available today trying to compensate for the wrong client platform for applications. These Ajax toolkits represent the early evolution of Application Client Container. They still have limitations (for example, lack of support for offline computing), but they are leading the way to the next generation client side computing.

From Unreliable HTTP to Internet Messaging Bus

The Internet was initially designed for presenting and sharing hyperlinked documents in the form of Web pages. Therefore, the communication layer is based on the HTTP “Request/Response” model, which adequately serves the purpose of “browsing.” Internet Messaging Bus is an enhanced HTTP communication layer that delivers reliability and two-way communications.

First off, Internet Messaging Bus supports guaranteed message delivery. Without IMB, when a user submits a request to the server, whether this request will actually arrive at the server or not is unpredictable. If there is a network problem (either with the ISP or within the corporate network itself), there is a good chance the request will be lost. However, this is not always a problem for Internet browsing, as the user can always click the link a second and third time if the first URL request is lost. Although this seems like a basic example in very basic terms, it is a serious problem for mission critical enterprise applications. The case and point being, that it is not out of the realm of possibility that a multi-million dollar transaction can be literally be “riding on the line.”

IMB supports guaranteed order of message delivery. Without IMB, if the user submits two requests in a row, there is no guarantee that the first request will arrive at the server before the second request. Again, while this is not necessarily a problem for browsing Web pages, the result of a later request can be dependent on an earlier request when using the Internet for business applications. A random ordering of message delivery makes the application behavior unpredictable — a pattern that many Web application users are familiar with.

IMB supports once and only once message delivery. Without IMB, a user request may arrive on the server side twice or even more, if some network problem caused the message to be cached and delivered more than once. Again, while this is not necessarily a problem for browsing Web pages, it can cause serious transactional problems for business applications.

IMB supports server-initiated communications (server push). HTTP supports client-pull only. In a “client pull only” model, the server works like a phone that never rings. Obviously this is not a problem for browsing because the server needs to simply respond to page requests. However, many enterprise applications require the server to initiate interactions. For example, a stock trading application needs to push the latest stock price to the end user from the server. To side step this problem, developers typically use “client polling,” but this significantly increases the server/network load and therefore decreases application performance.

From Application Server to Mashup Server: Next Generation Middleware

The evolution on the server side is the emergence of a new category of middleware called “Enterprise Mashup Server”.

Application Server is the middleware component in a web 1.0 stack. An “Enterprise Mashup Server” is not a replacement for an application server, but instead, an additional component to dramatically simplify the development and maintenance of composite applications. An enterprise mashup server enables three tasks:

1. Data integration
2. Service/business process integration (logic integration)
3. UI integration

“Mashup” as a term was created in the consumer space to describe the kind of applications like “HousingMaps”. As a consumer application, “HousingMaps” requires only UI integration. For business applications, it is highly likely there will be need to achieve integration at data tier or middle tier. In particular, the adoption of SOA creates a natural service repository for service/business integration for mashup applications.

Compatibility with Web 1.0 Is Key

The rising web 2.0 technology stack is not replacing the web 1.0 stack. Instead, compatibility with web 1.0 is a key requirement.

On the client side, application client container is not replacing browser. Browsers serve the purpose of web browsing well. Application client containers may be implemented by leveraging available means from web browsers and are likely to run inside web browsers. Some of the Ajax Engines, such as Apache XAP, are early examples of such client containers.

Internet Messaging Bus is not a replacement for HTTP either. Instead, IMB relies on HTTP and is built on top of HTTP.

Mashup Server does not replace application server either. Application server functionalities are just as important for web 2.0 application as web 1.0 ones. Enterprise Mashup Servers typically run inside an application server, thus enabling developers to leverage all the web 1.0 capabilities.

Go to previous page |Go to next page| |Download As PDF