In the first article in this series I outlined a view of the emerging opportunities that the Web platform is created.  In particular, I tried to show that the opportunity of distributed Web applications, where every Web browser and server on the network leverages data and services of other servers, becomes the foundation for the new Internet Economy.  From that analysis, it is clear that we are at a turning point in how the Web is adopted as a platform for this class of applications.

Organically evolving over the past five years, the Web platform has moved from being a mere document sharing system to being a distributed, global application platform for running core business systems in organizations worldwide. Any approach taken to address the emerging crisis of web applications must embrace this emergent platform, accepting its core components and capabilities, as well as its limitations. While it is tempting to look for a replacement technology built from scratch that does not have the Web’s weaknesses, it is far more practical to look for an approach that evolves and embraces, but does not attempt to discard, the established Web platform.

The De Facto Web Platform
The Web is by nature heterogeneous. It consists of a myriad of browsers and servers deployed on any number of operating systems and vendor implementations. As an application platform, it weaves together many types of content and programming languages. No single vendor controls it, and applications deployed on it are assumed to have few boundaries. (As an achievement in social anarchy, it appears to have no peers.)

Yet, the Web as an application platform has at last started to take a common and predictable shape. By surveying the landscape of Web applications (i.e. any Web site that uses client-side or server-side scripting and application logic), a consistent model of applications has emerged. Most corporations have embraced and are actively building applications using this model.

Dubbed 'Page-based applications', these applications use server-side data access and application logic to dynamically build pages that contain HTML, JavaScript and Cascading Style Sheets (CSS) to create dynamic user interfaces. On the server, Web applications are predominantly created using programming environments such as Perl, ColdFusion and Active Server Pages. (At times you'll find server-side applications written using Java or C++, though these are limited due to the complexity of development and the poor integration of the languages with the page and content centric nature of Web applications.)

On the client, the vast majority of applications are implemented using a combination of HTML 3.2 and JavaScript 1.1. Most applications are deployed to that subset of functionality which is supported both by Netscape and Microsoft browsers. Increasingly, applications are using JavaScript 1.2 and CSS, though there is still low adoption of these given browser compatibility issues. A very small percentage of applications use client-side Java because of its poor platform compatibility and significant performance and stability problems. An even smaller percentage of applications use client-side ActiveX, given the single-platform focus of this technology and its poor integration with HTML.

Pragmatism Wins the Web Platform
It might be noted that the ubiquitous Web application platform is little more than the evolution of a range of Web scripting and content languages that share some common properties:

1. They are straightforward and easy to use and learn,
2. They are mostly typeless, ASCII-based environments, and
3. They seamlessly integrate into the existing HTTP-based infrastructure used by Web browsers and servers. In short, the established Web application platform is a pragmatist’s platform, not a single homogeneous technology and architecture.

Web applications are built with this architecture and these technologies because they are immediately available and they work within the severe constraints of the Internet: high-latency networks, low-bandwidth speeds, a huge range of client and server operating systems, and the ability to be leveraged across broad, globally distributed networks. Having emerged from a document publishing system (HTML/HTTP 1.0), the Web has had to cope with a huge variety of shifts, all of which have continued to accommodate the underlying vision of the Web as an application platform.

Attempts to impose "richer" architectures on the Web that purported to solve major architectural limitations have consistently failed. Whether Plug-Ins, ActiveX or Java as client-side executable platforms, or Shockwave and VRML, which imposed huge client-side overhead while offering questionable concrete value, these systems have failed to achieve broad adoption because of poor integration with the Web platform as it currently works.

Indeed, pragmatism has won and will continue to win the Web platform war.

The Next Evolution of the Web Platform
As noted earlier, the Web is today undergoing another major shift and evolution. The shift is from viewing the installed base of browsers and servers as stand alone nodes, to viewing this broad network as a set of distributed services that can be leveraged by each other. In particular, the dramatic increase in the capabilities of Web browsers, through JavaScript and Dynamic HTML (DHTML), combined with the surging importance of Web application servers has finally woken the industry and customers to the fact that a sea-change is occurring in how much this platform can accomplish.

The two major shifts that are driving the next phase of the Web platform evolution are the increasing role of DHTML and Web clients for handling applications, and the changing role of Web servers to being distributed application servers that expose content and programmatic interfaces to other servers on the network.

Web clients grow in role and capability
After a number of false-starts with Plug-Ins, ActiveX and Java, the browser platform vendors have finally settled into Dynamic HTML (the combination of HTML, CSS and JavaScript) as the core model for client-side applications in the Web environment. With this standardization, developers are now realizing that substantial benefits can be had if data processing and application behavior is off loaded from servers to these more intelligent and interactive clients, moving browsers into a role and capacity that is likely to surpass Windows and like APIs for graphical user interfaces.

Traditional capabilities found in legacy client/server platforms, such as databinding and rich, interactive forms behavior, is now quite possible in browser clients. This capability has excited software ISVs and corporate developers, as finally they can fully embrace the Web platform as the new model of software development and distribution.

With this shift, the overall end-user experience and the role that desktop computers can play in the Web platform and global network is increasing dramatically.

Web application servers: the other side of the web platform coin
Even with this shift towards richer client capabilities, the pragmatist web platform is also evolving to support a set of services on the Web server that drive both the client behavior and distributed, server-to-server capabilities.

Web application servers have emerged as the foundation of how companies build valuable applications and sites on the Web. As the host of application logic, user and personalization data, and most importantly, data and back-end systems integration, these application servers are the critical counterpart to the growing role of web clients.

In fact, the capabilities of web clients and their ability to participate as true 'citizens of the web community,' will increasingly rely on the ability of Web application servers to interact and provide structured data to those clients.

And, as companies move to use the Web as a platform to drive business-to-business commerce and collaboration, the ability of application servers to communicate and share data with each other across the Internet and Extranets is becoming a core requirement.

Structured Web data: the missing link
As identified above, two major problems exist for this next evolution of the Web:

1. Rich web-clients and web application servers have no structured way to exchange data, and
2. web application servers lack any common means to exchange data between servers over HTTP. The lack of a structured data exchange format is the missing link in this emergent platform.

Using our earlier FedEx example, we can see how this problem manifests itself. In the end-user example, it would be extremely costly for FedEx to have its server dynamically generate a set of pricing options data for a given package and send that data to the client, where the browser would allow the user to choose between varying options, examining different prices based on configuration options. Assuming that the FedEx system was implemented using server-side Perl, ColdFusion or C/C++, these server-based systems have no easy way to move the data about pricing options to the JavaScript based clients. In short, no standard mechanism exists to move data objects between these disparate, yet ubiquitous, web programming environments. Hence, increasing the value of the Web end-user experience has been hampered by this missing link.

On the server-side, the problem is magnified. Imagine that FedEx wanted to expose a set of URLs on its server to other corporations who are deploying e-commerce sites and servers on the Web. These other corporations want to be able to query the FedEx server for real-time pricing and package shipment status information over HTTP. FedEx can’t assume that these incoming queries are coming from any given platform; different corporations are deploying e-commerce servers built on Perl, Java, ColdFusion, ASP, and JavaScript using Web application servers. Second, even if FedEx knew what kind of application was requesting its data, it would have no standard and predictable way to exchange that data. Again, the ability of FedEx to construct a next-generation business model that leverages the new Internet economy has been hampered by this missing link in the Web platform.

It is clear that a new, pragmatic solution is required to bridge the Web of today with the Web of tomorrow, and that XML is emerging as the foundation for this bridge.  In the next article for this series, I will discuss the opportunity of XML as an answer to the missing link that exists in the Web platform today.

-Jeremy

Jeremy Allaire is co-founder and Vice President of Technology Strategy at Allaire Corp. Please direct comments on this column to talkback@allaire.com.