In this article I look at how the traditional structure of web-based applications will, in certain circumstances, be turned upside-down. I call this new structure "The Inverted Web".
The principle that is important here is that of who owns the nodes in a web-based system. What I mean by "owns" is who makes the technology decisions for that node and, in particular, who decides what methods of communication a node in the system supports. For example, a web server supports HTTP to transport data and usually transports HTML. If it has a back-end database then that database might support ODBC, JDBC or XML. The scripts that run on the web server must also talk ODBC, JDBC or XML to talk to the database. The user's web browser must talk HTTP and be able to turn HTML into something the user can view. The important point is that the owner makes that decision.
Sometimes you have a choice over what protocol two nodes use to communicate. If you can then you probably own those two nodes. If you want a node you own to talk to a node you don't then you may have to make your node speak the same language as the other node. In the above example the people running the web server probably run the database and therefore can choose whether the two nodes will use XML or JDBC to communicate. The server administrators don't own the user's browser so, if they want people to use their servers then they must speak the language most of their potential users want supporting: HTTP and HTML.
The key point is that the architects of most first (CGI) and second (JSP/EJB) generation interactive web-sites can generally build them using web servers, application servers and databases that they are building from scratch or where they are working with the owners of the data. They have the luxury of deciding how those nodes of the system communicate. But, because they want to reach a wide audience, they can't choose how their system communicates with the client: that's got to be HTML and HTTP because that's all the clients are prepared to support. You can't dictate to them.
In the example above the web server is backed by systems that are controlled by the people who control the web server. This is really a "green field" scenario. When you are adding new systems you have most choice. But the long-term scenario isn't going to be like this because as time goes on most successful web systems will need to be integrated with other pre-existing systems. Companies will have many such systems owned by many different groups that may have used different technologies to network enable them. For example, some may base their solutions around Java 2 Enterprise Edition, some around Microsoft's .NET, others may use open source technologies.
Before, the system architect had little choice as to how to talk the client: it was HTML/HTTP or nothing. As time goes on they may have little choice as to how their new systems talk to other servers. Just as HTML/HTTP has become the lingua franca of client-server interaction so we will need a standard protocol for server-server interaction. This will probably be some variant of XML Messaging such as SOAP.
Returning again to our example we can consider the interaction with the client once more. The reason we can't dictate what protocols the clients speak is because we can't easily install software on the client machines. But this is now changing. Technologies such as Sun's Java Web Start allow the user to click on a link in a web page,check some security warnings and an application will automatically be installed on their machine. What is more, every time they run the application again the Web Start software ensures they have the latest version, and if not it downloads the new components.
What is clever about this is that now we can easily install new software on the client, we can get the users using any protocol we want. For example we could install a mail client that uses SMTP and POP3 or an X-windows client. Most likely a Java client will speak some variant of RMI but the important point is that we can choose the best protocol for the job.
And of course, what Sun is doing this year with Java is what Microsoft will be doing next year with C# - the idea is the important thing not the technology.
I like to think of this as turning the web on its head. Before it was general protocols for client-server and best-fit protocols for server-server and now there's the possibility of doing it the other way around.
Of course things are never that simple. Web-based clients are here to stay, at least for the foreseeable future. Companies can sometimes mandate the use of certain technology sets for system development obviating the need for the embrace of open protocols.
What is important is that XML-messaging and client deployment technologies have the potential to change the current model radically. And the forces at work, heterogeneous enterprise systems and the desire for more functional client software, may make this switch happen relatively quickly
| Date | Version | Comments |
|---|---|---|
| 30/3/2001 | 1.0 | First Draft |
| 2/4/2001 | 1.1 | Clarified the meaning of ownership and the enterprise section. |