HTML DataPort

Despite of its ever growing popularity, the web as a base for distributed applications suffers from several deficiencies. Essentially, HTTP is a stateless protocol. Since no application with an only slightly complex workflow can live without state, a lot of approaches to session handling has been taken to overcome this obstacle. Practically all of them require the server to take responsibility for this task. Therefore the application developer is charged with the additional burden to recreate state on the client side each time a new page is requested, and much additional traffic is generated by transmitting state information forth and back between server and client. This in turn creates security riscs since information is exposed to the public. Even if modern security technologies are employed, a much safer way would be to simply reduce data exchange. Responsibly creating secure applications demands for a lot of discipline and education; the overwhelming variety of existing technologies and new ones entering the scene makes it even more difficult to take the right decisions in design and implementation. On the client side, a simple markup language - HTML - and an ubiquitious not just as simple scripting language - JavaScript - let it appear to many that creating a feature rich web site is an easy task. If you don't know wether this is realistic view, just go on and surf the web.

The model how an application works is quite simple. The user clicks on a hyperlink, and a new web page is loaded into the browser and displayed. If the workflow requires information or functionality which is not contained in the current page, another page is loaded and the current page is abandoned. Sometimes work is done in parallel, which the browser or - more precisely - the HTML language supports by its frameset/frame construct and more recently by its iframe element. One important characteristic of these constructs is that they work asynchronously, i.e. the code initiating the loading of a resource returns immediately and does not know when the resource is loaded or wether an error has been returned. JavaScript does not offer anything like a wait() function whith which such an event could be captured. This makes frames and iframes inappropriate for processing tasks where synchronization of events is a must. In such situations, if new resources are needed, a request is sent to the server including state information so that the interrupted workflow can continue on receipt of the next page. Where a tight workflow control is needed, usually a kind of exterior technology is injected, such as Java applets or ActiveX controls and the like. Of course, the newly requested page could try to continue the work via a kind of callback function linked to it in form of a handler for the onLoad event. Thereby state information could continue to be used if it was possible to save it previously in an ancestor window. (frameset/frame solutions are less popular here because they do not work as reliably in conjunction with crawling robots.) What makes this kind of application less robust is the fact that application control is spread across different web pages.

The lack of synchronous communication leaves us in a very unsatisfacory situation. Therefore, the primary rationale of this project is to create an appropriate mechanism. We create a Java applet which realizes synchronous communication generically and establish a protocol to use it. This way, an implementation independent interface for both client and server side will be defined.

It took me not very long to realize that this approach has some serious - and favourable - implications. While my first intention was simply to reduce my efforts in implementing web applications with complex workflow and to reduce requirements of bandwidth, I saw that I could gain even more flexibility in implementing a kind of class loader. The idea is as follows: A web page is a piece of HTML code plus some more ingredients which altogether make up a network message - this is how TCP/IP works. Anything which flows into a webpage rendered by the browser does this in form of a message, be it HTML structure, formatting stuff, JavaScript code, or anything else. Now, loading JavaScript code dynamically opens a whole new world of possibilities. No more are we dependent on code statically linked to a HTML page through its script elements - it is sufficient to load just enough code to start the application. Any functionality not loaded during the first step could be requested from a server as needed. So the idea of a class loader for JavaScript was born.

Of course, in order to gain a significant amount of efficiency some infrastructure should be set up. One of the first things which came to my mind where namespaces. If we want to load code dynamically and to support this whith a server based name-resource mapping we need to organize code carefully; we need place for different implementations of similar things, and we need freedom to give reusable pieces of code meaningful names. Namespaces are a perfect means to support this. I am well aware of the fact that the next version of JavaScript, JavaScript2, has namespaces in the pipelines. However, since mid 2003 there seems to have been not very much activity around JavaScript2. Maybe the plethora of recent developments gave enough reason to rethink many features - I don't know (my feeling is that the language became to complicated to be accepted rapidly); in particular, I don't know when JavaScript2 will have made it into sufficiently many browsers out in use. What I do know, however, is that I want to have namespaces right now - and they can be quite easily implemented by means of existing language features without compromising the changes of the JavaScript language we have to expect. To take full advantage from them and from software classes, the class creation process has been carefully investigated. I came up realizing that classes should be instantiated via class factories. Class factories hide the new operator and instance initialization; additionally, they can load the class code from a server behind the scenes, transparently for the class user. Furthermore, a class factory installs a class in the parent name space of the class.

All this must be supported by a server side infrastructure. I choose to use PHP (version 4) because it is well established and quite powerful, and of course, for my own convenience. It should not be a major challenge to implement the same functionality with say Microsoft's ASP.Net technology or Perl. In deed, this functionality could even be implemented as a module of an HTTP server. Therefore, my primary goal is not the implementation (consider it just a proof of concept) but the definition of an interface to separate functionality from implementation.

One conclusion I came up to this one: The dataPort class is a workaround for a major omission in the JavaScript client side model. A dataPort object as a language feature should be a property of the containing window and not of a document as I have to implement it here.

This project therefore defines a framework for web applications which are realized in a PHP or differently based server side environment. It addresses application areas such as maintaining state, authentication, encryption/decryption, session management, resource management, application configuration, error handling, workflow dispatching, localization, source code management, load on demand functionality, and more. The promise of this project is that it demonstrates how highly structured and powerful web applications can be set up by relying on existing technology and adhering to a couple of basic principles which are not new to software engineers but seldom observed in modern internet reality. Massive code reuse and maintainability of JavaScript libraries are the benefits we can achieve if we create the necessary counterparts on the server side which support a common infrastructure. Today, the server side language to be used is not essential any more. Essential is the use of common patterns throughout, and this is what this project is about. Another benefit is that given clear structures and patterns it is much easier and more feasible to produce tools which support software development, deployment, and maintenance. Many more implications appear - please have a look to the chapter "Looking Forward".

If you like these ideas come on and continue reading. What I present here corresponds to my proper experience. Now I think it's worth discussing within the community, to see if the needs of others could be satisfied as well. Your comments are welcome!

One more remark: The project is still under construction which means that all the pages here are being continuously reworked. So it may happen at some point of time or another that a piece of code fails to exute successfully. I'm committed to remedy such situations as soon as possible.

As of May 2003, the pages presented here are not any more very up to date. I tested my implementation with several browsers including IE 6.0, Opera 8.0, Mozilla 1.71, Firefox 1.03. I found a couple of incompatibilities between these browsers and fixed some bugs. Everything appears now to work fine. (Apart from the fact, that Firefox regulary crashes eventually - which it does whenever it loads a Java applet as simple this might be - and to a lesser degree also Mozilla. Since this behaviour occurs independently of this project on every machine I tried - all WindowsXP based - I decided to not consider this a bug of my implementation. Opera and IE run absolutely stable. However I replace the Java applet with some more or less browser specific constructs such as HTTPRequest and XMLHttpRequest wherever possible; apparently Firefox and Mozilla run more reliably this way. Opera's version 8 does not yet implement all the necessary methods of XMLHttpRequest - that is why we're still using the Java applet here.). So the next thing is to update these pages and to port them to the dataPort technology. Stay tuned! A first demo can be viewed here.

© 2005 Goetz Heller (heller@hellerim.de)

• Outline
• Architecture
  • Overview
  • Client Side Programming
    • Classes
    • Class Factories
    • Subclassing
    • Aggregation
    • Namespaces
    • Error Handling
    • Localization
    • Load on Demand Functionality
    • The core Class
    • Anatomy of a One-Page-Application
  • Server Side Programming
    • The Librarian
    • Workflow Dispatching
    • Error Handling
• Client-Server Communication
  • The dataPort Object
  • Using HTML <META> Tags as Data Headers
  • Using Base64 Encoding
  • Data compression
  • Dealing With File Uploads
  • Handling File Uploads
• Security
  • Authentication
    • User Credentials
    • Login Dialog
  • Encryption
• Server Side Configuration
• Looking Forward
• Reference
• Appendices
  • Appendix A: Algorithms
    • Base64 Encoding
    • hashAlgorithm: An Abstract Base Class
    • The MD4 Hash Algorithm
    • The MD5 Hash Algorithm
    • HMAC: Keyed-Hashing for Message Authentication