Whitepaper

Figure 1: A View file being edited in the DataWeb Builder

• Data tables are SQL tables that are presented as files within the user’s application. A graphical editor is provided for editing data-table schema and for displaying the data stored in the table. Data tables support multi-table relationships.
• Views are XHTML files that can be bound to data tables. Each view has four modes—insert, update, details and browse—giving a developer multiple ways of displaying data in a single page. Views understand multi-table relationships, have full knowledge of the security and membership model and can show and hide elements based on the users permissions.
• Script is processed by the DataWeb Server and is written in ECMA compliant server-side JavaScript-standard. Script can be executed within views, in response to database events (triggers), or directly from URLs. The object model provides server-side functionality including access to user profiles, HTTP requests and responses, database operations, and secure file-system access.
• Static Files are stored in the file tree and are served by the DataWeb Server. Text files such as .html or .css can be edited in the Builder, while graphic files can be stored and served but not edited.

Figure 2: Model Physical Architecture (Not Pictured: mail, dns and administrative servers)

• Web Servers: DataWeb currently runs on IIS and Windows 2000.
• Database Servers: The database servers run Microsoft SQL server 7.0.
• Load Balancers: The DataWeb data center uses F5 big IP load balancers.
• Auxiliary Servers: Mail gateways and DNS servers run Unix/Linux.

1. All HTTP requests are checked for permissions and mapped to the appropriate handler.
2. Assuming the user has sufficient permissions, requests for static files are handled as usual by the web server.
3. Script and view files are cached in compiled form and served as requested; a call to the file server is made if a file is needed that is not cached.
4. The data layer checks security and validates queries and updates.
5. The query cache checks if the query results exist in the cache, and if updates have invalidated cached results, in which case a request is made to the database server.

Figure 3: HTTP request path

• C++ Runtime: The majority of the DataWeb runtime is implemented in C++, allowing for the highest level of optimization. There are no Java, ASP or COM components.
• Virtual Database Support: Each DataWeb application has it’s own custom tables and schema, but many applications can share a single physical database. This lowers the overhead for each app and allows the back-end to service many virtual databases efficiently. The DataWeb security layer guarantees that users read and update tables only if they have appropriate permissions.
• Data Caching Layer: In typical web applications many queries are repetitive, and the results of those queries change infrequently. The DataWeb data layer caches common query results and invalidates cached results as updates occur. The data-caching layer also includes a database connection pool to optimize the use of database resources when SQL queries are necessary.
• View and Script Caching: Compiled views and scripts are cached on web servers to speed request handling.

• Secure Logon: All logons to the DataWeb system occur over SSL connections. The logon is preserved over standard HTTP connections and reauthorized via HTTPs at regular intervals.
• Security and individual pages: Any element of a page can be displayed or hidden based on user permissions. In addition, elements of a page can be made editable or non-editable based on user permissions.
• Groups and Roles: DataWeb supports sets of permissions known as “roles”. Roles include Reader, Depositor, Author, Editor and Builder. These roles can currently be assigned to a fixed set of groups, though the underlying architecture supports custom groups.
• Record-level security: The Author role allows groups of users to create records but limits their update privileges to the records they created. For example, I might be allowed to read the company address book, but only allowed to update my own address.

• Access Database Import/Export: The DataWeb server can “upsize” an Access database to the DataWeb Platform. Views and navigation are created to allow users to instantly create a web-accessible custom relational database. Relationships between tables are preserved on both import and export.
• CSV Import/Export: The DataWeb Platform imports and exports standard CSV files.
• XML Export: Any query can be returned as an XML dataset from a URL.
• Web Import: Given a URL, DataWeb servers can walk an existing web application, import pages, and fix up links within the pages. This gives users a quick start on porting web sites to DataWeb.
• Integrated FTP Server: The Platform includes a custom FTP server that integrates with the DataWeb security model. This allows developers to publish content to their DataWeb application from existing web development tools such as HomeSite and Dreamweaver.
• Archive Support: DataWeb can package an entire application as a zip file for easy archiving, maintenance and restoration.

• HTML data type: With the HTML data type, formatted text that is entered into a field is automatically converted to HTML. A graphical HTML editor makes it easy to format text to be stored as HTML.
• File upload data type: The file upload data type uploads a file to a folder in your web application and stores a pointer to that file in your table.
• HTTP Object: The HTTP client objects offer programmatic access to the data returned by a request to any web server. These objects make it possible to share data between a DataWeb web application and any other web site on the Internet.
• Web Schema Objects: Web schema objects offer programmatic access to the structure of your web application and tables. Using script, you can create and modify tables, fields, and indexes.

• JavaScript (ECMAScript) Compatible: DataWeb uses a server-side implementation of ECMA compliant JavaScript that allows developers to build dynamic web applications using DataWeb’s extensive object model. Developers can use JavaScript to create business logic to drive an application, to generate custom pages based on user requests, or to programmatically manipulate data tables.
• Object Model: The DataWeb object model includes the standard ECMAScript core object model along with a set of objects that are useful in a server environment. These include request and response objects, data and file system access, and user information.
• Class Model: User-created DataWeb script files can be loaded as classes. New classes can be added to DataWeb without changing the core runtime.
• Event Binding/Triggers: Scripts can be associated with database events and fired on insert, update, or delete of records.
• Tag Embedding: Scripts that produce web pages or email often need to output large bodies of text. Like ASP and JSP, the script compiler can mix tags directly in the script for convenience of authoring.
• Webcall: Functions within script files can be marked as “public”, “private” or “webcall”. Webcall functions can be called directly via a URL, allowing non-browser clients to automate DataWeb applications.

• Data Regions: Data regions are areas of a page that are bound to data. Data regions support filtering, sorting, and paging through data. Data regions can display data in grid, insert, update or details modes. Multiple modes allow a developer to create a single page and use it to serve different types of uses.
• Template Pages: Template pages are an innovative way to give a group of pages within an application a common navigation “frame” and formatting.
• Flexible Editing: The Builder has both a graphical editing tool that allows a developer to author views through the UI, and an editable source view, for direct editing.
• Script Integration: Script can be used anywhere within a view to calculate and output values. In addition, script expressions can be used within many attributes on the server, to change how a page is rendered.
• Auto Joins: Views can include data from multiple tables without exposing SQL or the concepts of joins. Users can add related fields to the display of any record and can also display "sub-lists" of related information.