MSProjectReport.doc.doc.doc.doc

Computer Science Master's Project Paul Grosch

A Highly Optimized AJAX/HTML Databinding SQL Web Client

Problem Definition and Motivation:Most SQL/DML utilities involve a thick client application for querying and displaying

tabular results from database engines. The reason is clear: thick client applications can load, cache and render large amounts of data much more easily than a thin client application. Thick clients also maintain state. However, with web based applications becoming more and more pervasive; thin clients are being called upon to handle these large amounts of data (1000+ records) and stateful behaviors. The purpose of this SQL web client is twofold: 1) demonstrate a thin client handling large amounts of data with good performance 2) demonstrate a thin client with full-featured sql client capabilities that is seamless and stateful.

Developers are trying to squeeze every last drop of performance out of existing web technologies. There are few major obstacles to overcome when dealing with large amounts of data on a web client:

1) The network/server latency can add seconds to the response time of a HTTP request.

2) The browser parse & render time can add to the perceived wait time.3) The browser script parse/execution time (especially if it accessing a large amount

of data) can add to the perceived wait time.4) The browser is usually not interactive during page load or long running scripts,

making it seem less responsive.5) Paging at the server application or database level can be resource intensive for

non-trivial queries.6) Browsers consume excessive amounts of memory when rendering html elements

for large recordsets.7) Bandwidth is needlessly consumed by empty elements.8) There is no typically no separation of data and display elements in the browser

DOM.9) Pluggable browser controls (ActiveX, applet, etc.) specially designed for this type

of purpose can cause browser security, configuration and compatibility issues. 10)Sorting and searching typically require a server request, even for AJAX enabled

web pages.

State of the Art:Client: With the exception of embedded objects (such as Flash, applets & various

other controls), Web technology has not changed dramatically over the past 7 years. HTML, XML, CSS, DOM and scripts have been fairly stable tools of the trade for web client development. Some alternate uses of these technologies have begun to improve the otherwise clunky behavior of web pages. Specifically, “out-of-band calls” or “remote scripting” or “AJAX” (Asynchronous JavaScript and XML) development techniques have become common in many commercial web sites. Their main purpose is to minimize data transfer with the server and create a more dynamic and stateful web experience. Background HTTP requests transfer data to and from the web client, much like a TCP connection would in a thick client. AJAX is the most recent solution for this concept: a DOM XMLHttpRequest object (for hidden HTTP requests) sends requests to a server and the XML response is parsed by the web client. Scripts use this data to populate screen elements or provide users instantaneous feedback. XMLHttpRequest actually works well exchanging large amounts of data with the server, but the techniques required to manage large datasets on the client are not obvious or well-documented. For this reason, developers continue to use slow & user unfriendly implementations (server side paging, navigation and filtering controls, heavy script) for the large dataset problem.The following articles, developer tools and commercial web sites further reveal that most development strategies endorse these inferior solutions:

Computer Science Master's Project Paul Grosch

1) “The backbone of data-centric applications” is a very popular component suite for ASP.NET and Java web application developers. “Winner of over 225 industry awards”: The UltraWebGrid is touted as the premier component for navigating and modifying large datasets. However, as of the latest version (2006 Vol 3.), the AJAX enabled grids still use heavy javascript and the HTML DOM objects/methods to render & navigate records. Many developers outline the performance problems of this grid on the developer forum for Infragistics: http://news.infragistics.com/search?query=webgrid+performance

2) The Microsoft .NET development suite is gaining popularity in the web application development community as the rapid application development suite of choice. The latest technical articles from both MSDN and the “asp.net” site both recommend a custom server-side paging solution for large recordsets. A database procedure returns a subset of data to display or the server caches all data and sends only a subset to the web client. The obvious downside to this is server cache scalability, database intensive queries and network round trips to retrieve pages. The following articles discuss Microsoft’s approach in detail: http://www.asp.net/learn/dataaccess/tutorial25vb.aspx?tabid=63 http://msdn.microsoft.com/msdnmag/issues/05/01/ASPNETPerformance/

3) Blue Nile is the quintessential mature, heavy volume web application that would benefit from the solution discussed in this paper. The link below takes a user directly to the diamond search page, which (with no filter criteria) returns nearly 30K records upon load. Blue Nile handles the large dataset scrolling via “load on demand”; AJAX calls retrieve data and scripts generate relative positioned <div>’s on the fly to simulate scrolling. The Blue Nile solution is pretty good, but the behavior includes frequent pause & loads. It would benefit from the final solution offered in this paper. This is a link to the Blue Nile search page: http://www.bluenile.com/diamond_search.asp

4) Amazon.com is another mature searchable web commerce application that uses the standard HTTP post and paging design. Searches on Amazon.com commonly return hundreds or thousands of results. HTTP Posts are used to navigate through the results. In addition to being slow, this has the obvious disadvantage of consuming server and network resources.

5) The following article written by Ric Hardacre (Jan 31, 2007 - expert web solution developer, system architect consultant) briefly discusses a hybrid DHTML and AJAX solution developed to handle large

Computer Science Master's Project Paul Grosch

datasets within a shipping application. It specifically comments on dynamically creating table rows via the DOM and the heavy javascript required to support it. Dynamically generating DHTML objects and child elements is often slower that standard HTTP Posts when a large number of records are involved: http://java.sys-con.com/read/327906.htm

6) Telerik is another popular vendor of web user interface components. A quick tour of the developer forum will outline the same performance problems as Infragistics. The implementation is very similar; both companies use AJAX to gain only marginal improvements over the traditional HTTP Post model. The important point is that vendors who develop for developers, even with years of feedback and evolution are still not providing optimal solutions: http://www.telerik.com/

7) This is a unique developer article that discusses an efficient strategy to manipulate large recordsets on a web client. It is an obscure product “del.icio.us direc.tor” used to quickly navigate through potentially thousands of bookmarks stored on http://del.icio.us/. The developer outlines the AJAX loading XML data and XSL transforms used to filter and sort 12000 records. Some of the points in the developer article coincide with the final conclusions of this paper. “del.icio.us direc.tor” is a rare find and still does not address the issues with tabular data: http://johnvey.com/features/deliciousdirector/xslt-filter-sort.html

8) PowerBuilder “Datawindows” have been at the forefront of 4GL tabular data edit controls for years. The web based version “XML Web Datawindow” is an example of a good design: it separates the content (XML), the layout (XSL generated HTML) and style (CSS). Only XML is transmitted between the server and client after initial load to reduce bandwidth. XSLT stylesheets eliminate the need for slow javascript/DOM interaction. However, XML Web Datawindows do not cache the entire resultset on the client. Hence, sorting & filtering on the web client is not possible. XML Web Datawindows are the closest a commercial product comes to the final conclusions in this paper: http://www.sybase.com/content/1036155/L02708_PB_XML_Web_DW_WP.pdf

Upon the release of Internet Explorer 4.0, HTML databinding architecture was added to Internet Explorer. The design included a data source object, data consumers, a binding agent and a repetition agent. This thick client-like feature separates a data source from the tabular control, yet keeps the underlying data source synchronized upon data changes. It has native paging and asynchronous rendering characteristics, so the perceived load time is fast and the page is interactive during large dataset loads. These controls are part of the Internet Explorer browser, hence compiled code that is much faster than script. This project will leverage a combination of AJAX and HTML databinding with optimizations throughout.

Computer Science Master's Project Paul Grosch

Any server side language (Java, PHP, Cold Fusion, etc) could support this client. In this project, ASP.NET 2.0 with native XML and AJAX support will provide the server-side functionality. The latest release of the .NET framework has provider independent database APIs that provides completely generic data access code. This application supports Oracle, SQL Server, MS Access and MySql.

Problem Analysis:The problem will be discussed in terms of the SQL Web Client, but the concepts

discussed apply to all large datasets loaded by web clients. The following outline repeats the problem definition with conceptual solutions:

The network/server latency can add seconds to the response time of a HTTP request. Minimize the amount of data returned by each request. Do not request unnecessary content already displayed in the browser. Minimize temporary, intermediate data structures on the server

The browser parse & render time can add to the perceived wait time. Do not re-render content that has not changed. Do not render all of the data at once. Leverage native browser features to dynamically render content – not scripts. Leverage any other browser features that speed up rendering.

The browser script parse/execution time (especially if it accessing a large amount of data) can add to the perceived wait time. Do not use scripts to render large datasets, avoid looping through data in

anything other than compiled code. Initialize scripts once and avoid searching for elements in the DOM.

The browser is usually not interactive during page load or long running scripts, making it seem less responsive. Leverage native browser features that allow asynchronous interaction (non-

blocking actions). Leverage any other browser features that speed up rendering.

Paging at the server application or database level can be resource intensive for non-trivial queries.

Computer Science Master's Project Paul Grosch

Develop a fast paging mechanism for data cached in the browser; relegate paging to the browser.

Browsers consume excessive amounts of memory when rendering HTML elements for large recordsets. Render only viewable portions of the data; do not allow the scrollbar to become

one pixel in height. Bandwidth is needlessly consumed by empty elements.

Omit empty data elements. Use a XML schema flexible enough to handle missing elements.

There is no typically no separation of data and display elements in the browser DOM. Maintain data in an xml object on the browser; populate viewable elements with

this data only when necessary. Maintain a diffgram for data modifications that will be posted to the server.

Pluggable browser controls (ActiveX, applet, etc.) specially designed for this type of purpose can cause browser security, configuration and compatibility issues. Use native browser controls and objects safe for scripting

These solution concepts will be applied across 3 different prototypes and timed against increasing dataset sizes to determine the best design. Designs may exhibit undesirable asymptotic behavior in many different ways. Therefore, a detailed analysis of server resources, network bandwidth, client memory consumption and client response/render times will be analyzed to evaluate the proposed solutions.

Technical Solution:This project will focus on the HTML Databinding architecture; this solution is exclusive

to Internet Explorer 4.0 – 7.0. The SQL Web Client is a detailed functional proof of concept. The following outlines and diagrams identify major components and their respective roles in the SQL Web Client:

HTML Databinding (SQL Web Client) Server Internet Explorer 4.0 or above browser (client) XML Data Island (data cache) Databound HTML table (data view)

Computer Science Master's Project Paul Grosch

Databinding Agent (paging data, rendering table rows, synchronizing underlying data source)

DHTML Event model for Databinding (updating row flags, status messages) XMLHTTPRequest object (sending updates to server; receiving response) DHTML (client logic)

A comprehensive discussion will cover all the optimizations and design considerations. First, the HTML Databinding offers specific technical solutions to all the requirements identified in the problem definition/analysis section:

The network/server latency can add seconds to the response time of a HTTP request. The SQL Web Client HTML page loads once – all server communication thereafter is

handled through AJAX requests. The XML markup returned with data is minimal. The database API used to return the data is fast, forward only, streamed resultset. No temporary data structures will be created on the server to hold/format or bind the

data; it will be streamed. The browser parse & render time can add to the perceived wait time.

An XML data island is used to load and cache data on the client; nothing is rendered by default.

HTML Databinding is used to load pages of data from the XML Data Island; only a portion of the data will be displayed at once.

The browser script parse/execution time (especially if it accessing a large amount of data) can add to the perceived wait time. Scripts only handle simple dynamic operations. Large dataset manipulations are only handled by compiled code (databinding agent

or DOM methods) DOM references are established on page load and stored in local variables; it is not

necessary to dynamically search the DOM for anything.

Computer Science Master's Project Paul Grosch

The browser is usually not interactive during page load or long running scripts, making it seem less responsive. The HTML Databinding architecture is asynchronous – as rows are rendered from the

client cache, the page is fully interactive. Paging at the server application or database level can be resource intensive for non-

trivial queries. Paging is handled through the dataPageSize attribute of the <table> element and

the nextPage()/previousPage()/firsPage()/lastPage() DOM methods. No database queries are re-run and no data cache is necessary on the server.

Browsers consume excessive amounts of memory when rendering html elements for large recordsets. This design only renders a viewable portion of the data; paging is lightening fast.

Bandwidth is needlessly consumed by empty elements. XML data islands require well-formed xml and they infer the xml schema from the

complete dataset. Every child element/attribute of a row is optional, so null value attributes or elements can be omitted. There needs to be only one fully populated header row that ensures all elements/attributes are recognized.

There is typically no separation of data and display elements in the browser DOM. Data remains in a XML Data Island until the user loads other data or navigates away.

As the data is modified through UI elements, the Internet Explorer HTML Databinding architecture handles the synchronization of the underlying XML Data Island. Only one event handler is required to flag row modifications.

Pluggable browser controls (ActiveX, applet, etc.) specially designed for this type of purpose can cause browser security, configuration and compatibility issues. XML Data Islands and HTML Databinding can be used in any Internet Security Zone

(local, intranet and internet).

A walkthrough of the technological solution will clarify the role of each piece in the design. This begins with a standard HTTP request – the sql web client url is requested by the browser and the server returns a full HTML page. The client renders the page (which has no tabular data by default). Any references to frequently accessed DOM objects are initialized upon page load – the sql web client is ready for action:

From here, a user can type in a SQL/DML statement and click the button to execute and or they can select a table from the list and click the “Load” button. Both functions return tabular data: the “Load” function renders data in a spreadsheet modifiable format; the button renders a read-only format:

Computer Science Master's Project Paul Grosch

1) The SQL Web client uses an XML Data Island (Data Source Object) to load the results in a client cache. 2) The first row of data is parsed to get column header information. An HTML table is dynamically created to consume the data. The HTML table is databound to the XML data island by setting the “dataSrc” attribute of the <table> element. Individual columns within the table are bound to the individual data columns via the “dataFld” attribute. 3) The Internet Explorer databinding agent handles the asynchronous rendering of data rows. The diagram below illustrates this:

Using this design, nearly 50,000 rows of data can be loaded on a client in a few seconds. The databinding architecture loads the Data Source Object quickly because there is nothing rendered and the XML is extremely lightweight. The Data Consumer is bound to the Data Source Object, but the page is interactive during this process because it is asynchronous. Paging controls keep the visible dataset a manageable size and they are lightning fast because no further server round trips are required when paging through the dataset. The fixed-layout (CSS fast render algorithm) HTML tables further complement these optimizations.

The spreadsheet like capability of the SQL Web client best demonstrates all the advantageous features of AJAX, HTML data binding architecture and optimized design. A user selects a single database table to display. 1) The SQL Web client uses an XML Data Island (Data Source Object) to load the records in a client cache. 2) The first row of data is parsed to get column header information. An HTML table is dynamically created to consume the data. The HTML table is databound to the XML data island by setting the “dataSrc”

Computer Science Master's Project Paul Grosch

attribute of the <table> element. Individual columns within the table are bound to the individual data columns via the “dataFld” attribute. This time <input> elements allow editing of this data 3) The Internet Explorer databinding agent handles the asynchronous rendering of data rows. 4) Users edit the data, which triggers DOM events that flag rows as “u”pdated, “i”nserted, or “d”eleted. 5) Users click save; an XPath statement is run against the XML Data Island to collect the modified rows into a Diffgram. AJAX sends the Diffgram (changes) to the server. 6) The server responds with a success/failure message and new primary key ids for identity/sequence columns. The diagram below illustrates this:

The major advantages to this design are data can be edited while rows are still loading, saving changes does not result in a page refresh (even for new rows with sequence or autogenerated keys) and the databinding architecture handles all the data update events.

Evaluation/Comparison of Developed Solutions: While the proposed HTML Databinding solution is desirable in many regards; a

comparison with alternative solutions reveals some weaknesses. An AJAX Client Cache solution and a standard HTTP Form Post solution will be briefly discussed here. They will be evaluated against the HTML Databinding solution in 7 tests. All solutions are optimized to solve the large dataset on a web client issue.

Alternative #1The AJAX Client Cache design attempts to include all the optimizations of the HTML Databinding solution, without the use of Databinding architecture. The major difference is the AJAX Client Cache loads a XML DOM Document with a collection of XHTML tables as childNodes. These childNodes can be quickly paged and displayed with a simple “div.innerHTML = childNodes(x).text;”. DHTML scripts handle the synchronization of UI data

Computer Science Master's Project Paul Grosch

changes and the underlying data source. In all other aspects, the AJAX Client Cache solution is very similar to the Databinding solution.

AJAX Client Cache (alternative #1) Server XMLHTTPRequest capable browser (client) XMLHTTPRequest object (sending updates to server; receiving response) DHTML (client logic, rendering table rows, synchronizing underlying data source,

updating row flags, status messages) XML DOM (data cache, paging data) HTML table (data view)

Alternative #2For all intents and purposes, the HTTP Post solution is the “Control Group”. This solution uses a standard HTML form and table. No scripts or DOM features are used. The data paging is handled via server routines; hence data navigation/modification requires a HTTP Post.

HTTP Post (alternative #2) Server (data cache, paging data) HTTP client form (sending updates to server; receiving response, rendering table

rows)

Computer Science Master's Project Paul Grosch

ComparisonThe following graphs will compare the HTML Databinding solution with the AJAX Client Cache (alternative #1) and HTTP Post (alternative #2). Memory consumption, response times and network utilization tests were performed on a DELL Dimension XPS running Windows XP with Internet Explorer 7 (2GB of RAM and 3.2 GHz Pentium IV). The combined results of these tests directly correspond to overall perceived performance.

The “Time to Interactive” graph depicts the amount of time elapsed from initiating data load until the browser is interactive. The HTML Databinding solution is immediately interactive

Computer Science Master's Project Paul Grosch

upon data loads. This is due to the asynchronous behavior of the Databinding architecture that allows a XML DataIsland to load and render on a separate spawned thread. The HTTP Post is slightly slower due to heavy HTML markup and the fact that all records that are loaded must be rendered. The AJAX Client Cache exhibits the worst behavior because of the blocking script (div.innerHTML = xmldoc.childNodes(x).text;) that renders all the records.

The “Data Payload” graph depicts the amount of memory consumed by the HTML, XML and/or markup required to represent the dataset. HTML Databinding allows a flexible schema in which every child attribute/element of a row is optional. In addition, the HTML Databinding solution uses a <r a=”” b=”” c=”” … aa=”” ab=”” … /> schema to minimize the markup in a XML Data Island payload. The end result is structured data with very little overhead in size. The AJAX Client Cache uses XHTML structured data to simplify paging; it includes both data and formatting tags. The HTTP Post requires the data, formatting tags and other page elements to be transferred on each load. This is the most expensive in terms of data payload.

Computer Science Master's Project Paul Grosch

The “Browser Memory Usage” graph depicts the amount of process memory consumed by the browser process when displaying all records. The HTML Databinding and AJAX Client Cache solutions grow at a similar rate. They consume memory at twice the rate of the HTTP Post solution. The reason is simple: the data is replicated twice in memory – once for the underlying data cache and the other for display in UI elements.

The “Time to Load Data into Client” graph depicts only the amount of time to fully load the data payload into the client cache (no rendering). HTML Databinding and the AJAX Client Cache performed similarly, although beyond 50,000 records the HTML Databinding took slightly more time, most likely due to the asynchronous/non-blocking behavior that must

Computer Science Master's Project Paul Grosch

share processor resources with the UI. The HTTP Post takes much longer because all rows that are retrieved must be rendered. The rendering is typically the most expensive phase of large dataset retrieval on a Web Client.

The “Time to Fully Display All Records” graph depicts the amount of time to retrieve and fully render all records. The standard HTTP Post is the far superior solution in this regard, taking only 50 seconds to display 102,400 records. The browser parses the HTML tags once upon load and all elements are displayed. The AJAX Client Cache solution took twice as long to display 102,400 records, perhaps because setting the .innerHMTL property is not nearly as optimal as a HTML parse during page load. HTML Databinding becomes sluggish and unusable beyond rendering 10,000 rows due to its poor rendering time. This again is most likely due to its asynchronous behavior and event model that does not scale well when displaying all of a large recordset.

Computer Science Master's Project Paul Grosch

The “Time to Page (200 Records)” graph depicts the time elapsed from initiation of a paging action until the next page of data is fully displayed. It is important to note that this is after the client caches have been fully loaded. The AJAX Client Cache was extremely fast with regard to paging within the recordset, with almost no perceived delay. This is due to the direct access to individual table data pages within the XML DOM childNodes collection. The HTML Databinding never loses interactivity upon a paging action, but it takes approx 1 second to fully render 200 records. The databinding agent causes a delay in rendering rows as compared to a traditional HTML parse. The standard HTTP Post causes a network roundtrip for each paging navigation command; for non trivial queries, this would always be a slower approach.

Computer Science Master's Project Paul Grosch

The “Sort” graph depicts the time elapsed from initiation of a sorting action until the current page of data is fully displayed again. HTML Databinding sorts are handled by running a XSLT transform against the XML Data Island’s XMLDocument. Since the XML is a very simple attribute based schema, it takes just over 3 seconds to sort 102,000 records on the client. This allows data to be edited and sorted any number of times before saving – a very powerful web client feature. The AJAX Client Cache uses the same XSLT transforms to sort, but the XHTML markup slows the transformation process. HTTP Post solution sorts must be performed on the server, resulting in a network round trip, etc.

The table above summarizes results of the three solution comparison. The AJAX Client Cache solution is the best-rounded, the HTML Databinding excels in more areas and the HTTP Post provides a stable baseline. A hybrid design that includes some of the characteristics of the HTML Databinding and the AJAX Client Cache will be offered in the Conclusions section.

The sluggish rendering behavior of HTML Databinding beyond 10,000 records is very undesirable. In all other tests, it was a close second case to the AJAX Client Cache solution.

The “Client Side Event Model” and “Browser Compatibility” ratings are more subjective evaluations of the proposed solutions. Obviously, standard HTTP Posts do not make use of the client side event model and are compatible with all browsers. HTML Databinding is only compatible with Internet Explorer, yet offers a rich event model to manage data cache and

Computer Science Master's Project Paul Grosch

UI status along with data modification events. The AJAX Client Cache solution falls in the middle of terms of browser compatibility and event model.

Major Contributions:This project will identify a final design for a large dataset web client solution (see

conclusions) that is not obvious to many experienced web developers. Students interested in extending this project could change the types of applications made available to the web. Conclusions:

The W3C published a working draft specification for the XMLHttpRequest object's API on 04/05/2006. Its goal is "to document a minimum set of interoperable features based on existing implementations, allowing Web developers to use these features without platform-specific code"1. Given this information, a platform independent AJAX Client Cache solution with the following features would provide the most optimal solution:

The XMLHttpRequest object is used to load data into the client cache and the XML adheres to the lightweight schema identified in the HTML Databinding solution.

XSLT Transforms sort and filter the data (for searches). XSLT Transforms add HTML markup to the data for dynamic paging & rendering. The XMLHttpRequest object is used to communicate data modifications with the

server. DOM Event handlers and DHTML handle the client logic. A standalone XMLDOMDocument holds the diffgram. Strict XHTML capable browsers could offer more performance gains due to the

optimized XHTML parser. Dynamic page resizing, multiple field sorts, validation and other sophisticated

behaviors are handled through the XSLT Stylesheet compiled code transforms. CSS fast table rendering style=”{table-layout:fixed}”

1 Wikipedia, W3C XMLHTTPRequest http://en.wikipedia.org/wiki/XMLHttpRequest

Computer Science Master's Project Paul Grosch

Value to student/department:Like many development environments, the CS department is always in need of a fast,

reliable, easy-to-use and internet enabled SQL web client. The possibilities are limitless, but the most obvious application is the use of this project in the database concepts course. Students can run queries against the department database engine and expect performance nearly as good as a thick client. The GUI could easily be extended to allow DDL statements. The SQL client could be used to provide simple, read-only access to databases where data need only be queried.

In addition, students focused on emerging web technologies could extend this project from both the server side and client side. The highly optimized loading/rendering of large datasets may be useful to a variety projects utilizing web technologies. Years of professional web development experience in high transaction volume systems brought these ideas together. They are tried and tested in real production environments.

References/Bibliography

CSS fast table algorithmhttp://www.w3.org/TR/REC-CSS2/tables.html#fixed-table-layout

Fundamentals of Database SystemsElmasri | Navathe Third Editionhttp://www.aw.com/catalog/academic/product/1,4096,0805317554,00.html

Wikipedia AJAXhttp://en.wikipedia.org/wiki/Ajax_(programming)

Wikipedia, W3C XMLHTTPRequesthttp://en.wikipedia.org/wiki/XMLHttpRequesthttp://www.w3.org/TR/XMLHttpRequest/

Computer Science Master's Project Paul Grosch

Microsoft Data Binding Architecturehttp://msdn.microsoft.com/workshop/author/databind/data_binding_node_entry.asp?frame=true

About Data Binding Architecturehttp://msdn.microsoft.com/library/default.asp?url=/workshop/author/databind/data_binding_node_entry.asp

Will browsers ever deliver applications instead of documents?http://java.sys-con.com/read/327906.htm