Table of Contents Terms of Use

HTML DataPort

Summary. DataPort is a communication channel between browser and host application. It allows for synchronous load on demand of arbitrary information and functionality without abandoning the current web page, enhancing thereby the versability of the browser. A complementary core set of JavaScript class management routines is implemented in order to gain full advantage of this technology - JavaScript Version 2 is not required. This technology opens client-side programming to new approaches for developing JavaScript based software components. An outstanding advantage is that the need to exchange data between client and server is reduced significantly, since state information on the client is not destroyed each time new data or application behaviour is requested from the server - currently, this usually means loading a new web page. Furthermore, use of hyperlink URIs is reduced and hence the cost of maintaining them, since resources may be requested by name where name resolution is done by the server. Taking this together we can state that development effort is reduced, web software construction quality improves towards well-founded software engineering, robustness of applications is increased as well as administrability of web-sites, and security is far less compromised. In addition, a large market opens for implementors of software components and tools.

Zusammenfassung. DataPort ist ein Kommunikationskanal zwischen Browser- und Host-Anwendung. Er ermöglicht ein synchrones Nachladen beliebiger Information und Funktionalität bei Bedarf, ohne die aktuelle HTML-Seite zu verlassen, und erhöht dadurch die Vielseitigkeit eines Browsers. Dies wird ergänzt durch die Implementierung eines Kernmoduls mit JavaScript-Routinen zur Manipulation von Klassen, um die Vorteile dieser Technologie vollständig zu nutzen - JavaScript Version 2 wird jedoch nicht benötigt. Diese Technologie erlaubt neue Ansätze für die Entwicklung JavaScript-basierter Komponenten zur Erstellung dynamischer Webseiten. Einer der größten Vorteile besteht darin, dass Zustandsinformationen für die Sitzungssteuerung in weit geringerem Maß als bisher üblich zwischen Client und Server ausgetauscht werden müssen. Weiter verringert sich der Bedarf, Hyperlink-URIs im Code zu verwenden, da angeforderte Resourcen über Namen angefordert werden können, die erst auf der Serverseite in Web-Adressen aufgelöst werden müssen. Zusammengenommen verringert das den Entwicklungsaufwand, trägt zur Verbesserung der Code-Qualität von Web-Anwendungen im Sinne eines fundierten Software-Engineerings bei, fördert die Robustheit von Anwendungen, verbessert die Verwaltbarkeit von Web-Sites und erhöht die Sicherheit der Benutzung. Zugleich wird hiermit ein breiter Markt für Anbieter von Software-Komponenten und -Werkzeugen eröffnet.

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.

Terms of Use

The material presented here is being considered to be put under a public license; however, no decision has been taken yet. Therefore, the following applies:

Clearly, this material is based on the work of others. Where appropriate, the author has tried to indicate sources wherever possible. Failure to do so does not mean that the author claims his authorship for the material in question. However, he claims authorship for all the material contained herein which has not been published elsewhere by others before. This material, called "material" in what follows, is subject to the following conditions:

No part of material may be used, exploited, copied, distributed, or reproduced in any form for commercial purposes without written permission by the author. For non-commercial purposes, the right to use and reproduce material is granted to everyone provided this copyright note is included with it.

© 2005 Goetz Heller, Dr.Heller Information Management

I agree
I don't agree

© 2005 Goetz Heller (


Table of Contents

© 2005 Dr.Heller Information Management