Home	News	Index	Screen Shots	Tour	Downloads	Support	FAQs	Orders	Partners	White Paper

Introduction

The Internet was designed to transmit raw text data (encoded in a markup language called HTML) because of the varying operating system environments in which the data may be viewed.  A browser (a computer software application) is then designed and built in each operating system to interpret and present the text information for browsing.

The Internet browsers were not designed to display binary data, which are mostly operating system dependent.  To extend the Internet browsers to do more, some specialized applications are created and deployed alongside a Web Browser. In the Internet context, these applications are called helper or plug-in applications.  To display formatted text documents, another application called Adobe Acrobat was designed for this specialized task.  To play videos on the web, specialized applications like RealPlayer are employed.

One of the reasons the Internet has such a profound effect on companies is the ease with which business information such as product lists and other product and service related information can be sent to and accessed from remote locations.  Most business database applications can be easily redesigned for the Internet because in most cases, company databases have already been designed, deployed, and operational. The process of taking your business database to the Web can be easy, fast, and painless, or it can be quite difficult and expensive depending on the tools you choose to use.

Unlike the problems solved by RealPlayer and Adobe Acrobat, the database problem is more complex.  Not only do we need a helper application on the browser side to handle the user interactions with the browser; we also need a helper on the server side to interface with the database and the Web server.  Therefore, for databases, a good solution must provide Server-side and Client-side logic.  This poses a real problem for the computer software engineer.

THE PROBLEM
Many database applications were designed to run on specific operating systems.  Many companies are heavily vested in one or more of these database applications.  The problem is whether to build a specialized database for the Internet and if so, which of the many database vendors should do it?

In answer to the question, some completely new database vendor companies were founded to provide “THE ULTIMATE” solution.  What we ended up with is even more choices with an overwhelming array of solutions.

 In designing a solution, the most important problems are:

- How to implement state management.

- Security over the open World Wide Web.

- Database Integrity.

STATE MANAGEMENT

In the Web environment, connections are on an as-need basis. The client requests data from the server, and the server responds to the request. Once the server sends its response, the connection is terminated.  This relationship presents no serious issue for standard HTML pages but becomes problematic when databases are involved. The issue is primarily one of storing the user’s location within the database. The user’s state must be maintained so that data flows smoothly and without error, as if it were local with a persistent connection.

Persistent vs. Stateless Connections

Most Web database tools employ persistent connections to ensure proper management of the user’s state in the database at all times.  Note that “Persistent connection” in this context, does not have the same meaning as in the W3s HTTP/1.1 implementation of pipelining browser requests.  (See http://www.w3.org/Protocols/HTTP/Performance/Pipeline.html) In this context, a persistent connection is accomplished by setting up an open channel between server and client computers throughout the time a user is surfing the site.

While it solves the problem of state management, persistent connections result in very high network traffic as new HTML pages are created to refresh the browser with the new data.  High traffic often leads to broken connections and poor performance.   Other problems with the method include its inability to reflect data relationships—master to detail relationships between a customer and his orders, or a department and its employees.

SECURITY AND DATABASE INTEGRITY

In the LAN and desktop environments, the security and integrity of the database is not half the issue it becomes when data has to be transmitted over long distances.  When we talk about security and data integrity, the following questions must be answered:

- Has the data been copied, or altered along the way?

- Is the data coming from the source we think it is coming from?

- How current is the data?

- How are conflicting changes to data handled?

Answers
In answering these and other questions many vendors have come up with various solutions.

1) HTML PAGE BASED: Use HTML and its extensions such as Java, JavaScript, CGI, PERL,
ActiveX, cookies, and applets to extend HTML-based browsers to work with database information.

2) WEBIFIED LAN APPLICATION: Webify a LAN application so that it communicates
over the web, but has the look and feel of a locally run application.

3) HYBRID WEBIFIED LAN PAGES:  Create a marriage of the two by taking  the best of each, using a specialized browser to create the look and feel of a locally run application with Internet flexibility.
 

HTML PAGE BASED

This is the most common solution.  Using this method, the entire database application logic is built into an application server, or in the form of an array of CGI scripts using any of the many scripting languages already invented and those being invented, including Perl, VBScript, JavaScript and many more. It seems that each vendor has come up with a proprietary scripting language.  The common configuration steps of tools in this category are:

- Setup the Internet server computer to run a Web server and the CGI script or Application Server.

- Setup the database server.

- Create a proprietary communication structure for transferring database data between the browser and the Application Server.

Setting up the Internet Server

- Web Server software is installed on a computer (called Internet Server computer) running an Internet capable operating system such as Unix or Windows NT.  The web server software is designed to pass information stored in HTML files on the Internet Server to an HTML browser.

- A database server is installed either on the same physical computer or separate computer on the same subnet as the Web Server software.  The database server is software capable of holding structured information and the relationships between these structures.  There are two categories of database servers: desktop databases (such as Paradox or MS-Access) and encapsulated databases (such as Oracle, Sybase, Informix, etc.).  The major difference is the amount of outside code required to manipulate objects in the database.

- Experienced software programmers first design CGI scripts written in C, Perl, VBScript, or Java.  This is installed in a directory where the Web Server can reach it.  Application Servers contain far more complex and many more logic blocks than a single script and are designed to extend the capabilities of the Web Server they support.

- Query files containing SQL commands for retrieving, deleting, and storing data in a database are created and stored on the server computer.

- A URL referencing the CGI and the query file names is encoded into an HTML file, which is also copied to the server computer where the Web Server software can reach it.

Sending data from the Server to a Browser:

- When a browser request (in the form of a URL) comes to the Web Server for the HTML page, it simply sends a copy of the HTML file to the browser.

- If a browser request includes a reference to the CGI, the Web Server executes the URL.  It makes all the references in the URL, and activates the CGI script, passing it the appropriate query file.

- The CGI creates a connection to the database.  Depending on the nature of the CGI, it may use an ODBC driver.  Others may use proprietary drivers to interface their database.  Examples include Oracle’s Application Server or Active Server Pages (ASP)  from Microsoft.  See http://www.webreview.com/pub/1999/02/26/webdb/index3.html for a comparison chart on some of these Application Servers and the databases supported.  Note that the chart only contains eight servers.

- Once the connection is established to the database, the query file is read and the results are formatted into HTML and written to a file. Typically, the file is the Standard Output  (the computer screen).

- The Web Server immediately scoops up the contents of the file and sends it to the browser.

Sending data from a Browser to the Server:

Assuming a data entry page, the user enters new data or deletes or modifies existing data on the page.  The data has to be collected and transmitted to the Web Server so that the database is updated.  The process of gathering the data and updating a database on the server side is quite complex.  Each vendor employs different techniques.  Some tools base much of the work on the database itself, as many database vendors have done. (Ex: Informix, Oracle, Microsoft’s SQL Server, Sybase).  Others situate the code close to the Web Server (Ex. Delphi and Cold Fusion) while some distribute the work between the database server, Web Server, and the browser. (Ex: Oracles’ Application server, Database, and client side JavaScript enablement.)

 Some of the tools in this category include:

Active Server Pages
ASP runs only with IIS and supports only SQL Server with native drivers.  However, a company called ChiliSoft provides interfaces that let you run ASP with other Web Servers.  ASP supports VBScript, Java, JScript, C++ objects, and anything that can produce ActiveX controls such as Borland/ Inprise Tools (JBuilder, C++Builder, and Delphi).

The problem with ASP is that the FileSystem Object (FSO) allows anyone to access any directory on the hard drive, including the root level.  It also allows modification of files in virtual Webs.  The majority of hosts that support ASP have not taken precautions to limit clients.  (See Sharing Too Much: The Dangers of Hosting on Windows NT, Chuck Newman, Web Techniques)

OTHER TOOLS
Most of these tools use proprietary scripting languages or extensions to HTML, so you do need a thorough knowledge of HTML and their proprietary extensions.  Most execution takes place on the server side.

Cold Fusion
Doesn’t require CGI, Perl, Java, or C++. Uses proprietary tags to extend HTML, which are then resolved to normal HTML tags before processing by the browser.

LiveWire
Uses HTML and JavaScript.

Tango
Requires HTML knowledge, has its own extensions (not as extensive as Cold Fusion), and doesn’t require SQL, CGI, Perl, Java, or C++ knowledge.

WebDBC
Needs HTML, CGI, and SQL.
 

WEBIFIED LAN APPLICATIONS

They include those solutions built from the ground up to be executed over the Internet.  Single, highly specialized applications are designed to enable Internet database access.  Most popular applications in this category include Charles Schwab, and most Day trader interfaces.  Many companies have taken advantage of this type of Internet enablement.

How it works
The application is often built using such tools as Delphi Pascal, Visual Basic, and C++Builder. Many use the Internet database connection components provided by a database vendor.  Database vendors such as Oracle, Microsoft and others have created Internet Server versions of their databases.  These servers are designed to respond to Graphical User Interface applications running in a remote location.

The application is distributed to users all over the world.  The database server is deployed on the Internet Server side.  Once a user activates the application, a persistent Internet connection is immediately established to the URL of the Internet database server.  The built-in components initiate database requests to the server, and the server responds with data.
 

 HYBRID WEBIFIED LAN PAGES

There seems to be only one tool in this category.  AstroMark is a late comer into the Web tools market although its research and development started as far back as late 1996.  The creators and users of AstroMark believe the AstroMark approach was worth waiting for.  AstroMark takes a totally different non-HTML approach to solving the database to Web problem.  It successfully separates database data from HTML and provides a means for a symbiotic relationship between HTML and database data.

AstroMark suite has three major applications, the AstroDesigner for creating database web pages,  AstroServer, which is the application server Middleware/ WebServer, and AstroMark, the database page browser.

Solves Browser Incompatibility Issues
Recall that in the first few paragraphs of this article we mentioned that specialized applications can be installed as helpers to HTML browsers.  Two examples of such helper applications were given:  Adobe Acrobat and RealPlayer.  AstroMark was designed to be the database helper application, installed alongside an HTML browser.  AstroMark is to become to the database what RealPlayer is to videos.

AstroMark supports all versions of Web browsers, because it does not attempt to display database data in the HTML browser.  This means that the Web database programmer does not have to worry about browser incompatibility issues any more.

Transparent support for most database types
AstroServer supports most database types including ODBC.  AstroServer includes most database functions and operations that CGI scripts would be required to perform.  This way, the software programmer does not have to spend time and effort on that aspect.  This is a major difference from all other solutions.  It makes all database interactions transparent to the programmer and the user alike.

Supports all Web Servers
As Middleware, AstroServer can work with all other web servers.  Yet, as a Web Server, it can perform many of the standard functions reserved for regular HTML servers such as IIS.

Point and Click User Interface
Database web pages are created much the same way and sometimes faster than using a LAN based tool such as Delphi or Visual Basic.

All code is client side
Support three languages, called AstroScript.  PasScript,  JavaScript, and VBScript in future releases.

Built in Report Engine
Full-scale reports such as master-detail, tabular, and labels can be designed on any AstroPage.

How it works
Let us see how AstroMark handles each of the three steps discussed with respect to the HTML BASED solutions above, namely:  Setup the Internet server computer to run a AstroServer;  setup the database server;  create a proprietary communication structure for transferring database data between the browser and the Application Server.

 Setting up the Internet Server

- A Web Server software (AstroServer only or AstroServer and another third party Web Server such as IIS) is installed on an Internet Server computer. No server-side scripts are necessary.

- A database server is installed either on the same physical computer or separate computer on the same subnet as the Web Server software. Depending on the database type, much of your business rules can be enforced in the database using stored procedures.

Sending data from Server to Browser:

- When a browser request (in the form of a URL) comes to the Web Server for an HTML or GTI page, it simply sends a copy of the file to the browser.

- If an AstroMark browser requests database data, AstroServer automatically performs the operation and returns the data to the browser.

Sending data from a browser to the server.

Assuming a data entry page, the user enters new data or deletes or modifies existing data on the page.  The data has to be collected and transmitted to the Web Server so that the database is updated.  AstroMark sends a data packet to AstroServer which interprets the instructions and makes the changes to the database.

Suite Overview

AstroMark combines the ease of use of a visual development environment with the flexibility of a scaleable data access architecture to deliver a robust development suite for true WYSIWYG database-driven Web pages.

Great things come in small packages. There’s so much functionality built so compactly, you’ll wonder how the file sizes can be so small yet provide such robust functionalities. Each tool in the AstroMark suite is no larger than 2 MB. Plus, because there is no Java or any of its derivatives, no ActiveX, no COM or DCOM, no OLE Automation Objects AstroMark has none of their security breaches.

AstroMark is designed to be your Internet Mission Control Center in the new millenium.

AstroMark is a suite of three applications: AstroDesigner, AstroServer, and AstroMark Universal.

• AstroServer: This engine monitors, manages, and serves concurrent user accesses to the deployed applications and/or databases. The Server runs independent of existing Web servers to extract, insert, or modify data in popular databases.
 
• AstroMark Universal: The native browser runs in tandem with or independent of popular browsers to display database-driven Web pages.

AstroMark versus Dynamic HTML Web Pages

Traditional database-driven Web applications would require scripts or code such as JavaScript, ActiveX, CGI, Perl, C++, or VBScript. State management mechanism would be programmed, possibly with another tool or set of tools. Although some Web development tools encapsulate these features, they all generate dynamic HTML code and may encapsulate active features designed to execute on the user's CPU.

Let’s examine the following HTML scenario:  A user wishes to find product availability and price for a particular product category.  Using a HTML browser, the user submits the query, the relevant product information is extracted from the database, the browser formats the data dynamically as HTML, and displays ten products per page. Each time the user wishes to see more products that match his category, the browser must load a new HTML page.  All browsers do not support all functionalities you may wish to add to your application, depending on how much your scripting language deviates from standard HTML.  These browser differences are not only from one vendor to another, but from version to version under the same vendor.  For example, a JavaScript command may work perfectly well in Netscape Navigator but not in MSIE, and the reverse may also be true for ActiveX controls.

Because AstroMark does not attempt to display database information on HTML pages, the data changes—not the page. Each component stays where it was designed. The user submits the query, the relevant product information is extracted from the database, and the data is displayed on the page.

Scrolling forward to next records
After a click on the "next" button, the data changes (NOT the page), and the next product record display. With other solutions, a completely new page will have to be created causing quite noticeable delays and many times broken pipes results.

Scrolling back to previously viewed records
If the user should want to scroll back to previously viewed records, AstroMark's data caching feature lets the user view the data without revisiting the remote server. This inspires confidence in the user.  With AstroMark, thousands of records can be pulled in seconds to the user's browser, letting the user browse, search, and sort records without visiting the server multiple times. Unlike other solutions, the page--with its associated information--is displayed exactly as the developer designed it, every time.

Database Flexibility:
While many tools offer access only to their proprietary databases, AstroMark allows you to access any ODBC compliant database and many encapsulated SQL database servers. You can even access several database types on the same page, oblivious to the user.

Security

Most Web development tools which create dynamic HTML require a browser that accepts Java, JavaScript or supports ActiveX. However, much controversy surrounds using these approaches because of potential security risks they pose to the end user:

• No Java, Java bean, or Java applets are allowed
• No ActiveX or ActiveX derivatives are allowed
• No JavaScript or other scripts such as VBScript are allowed

In addition, the AstroMark suite has several levels of data protection integrated within the Designer, Server, and Browser.

AstroScript

Existing solutions often introduce new and unfamiliar programming languages and extensions to both Java, and HTML that requires extensive training.

The underlying programming languages of AstroMark are versions of the Object Oriented languages called AstroScript. AstroScript
is a generic name for all supported scripting engines PasScript, VBAScript, and JavaScript:

About PasScript

• Well established:  Pascal is a well established programming language, having been tried and tested over many decades.
• Broad knowledge base:  Pascal is often one of the first languages a programmer is taught—whether it is in high school, in college, or at the university level.
• Shorter learning curve:  Thousands of programmers around the world already know the Pascal Language. This familiarity means a shorter learning curve.
• Ease of learning:  Having trained thousands of software engineers, we at GenoTechs know that Object Pascal is much easier to learn than C++ or any of its derivatives like Java.
• Tremendous savings:  A shorter learning curve and broad knowledge base translate to cost savings because of reduced training costs and quicker production time for individual developers and corporations.
• Multi-platform support:  Implementations of the Pascal Language exist on virtually all operating system platforms.
• Object orientation:  AstroMark can harness the power of Object Oriented Programming to create robust, efficient applications.

The Designer is the development environment for building true WYSIWYG (What You See Is What You Get) database and non-database enabled applications that can be executed locally on a desktop computer, on a LAN, on a WAN or over the Internet. While the Designer is a superior tool for Web developers, its ease of use means that even non-programmers can use AstroDesigner’s visual integrated development environment to quickly create AstroMark pages.

Developers can create Web pages which include static text or images. The Designer has a point and click interface with drag and drop components. Developers create pages by placing components on the design page, setting their properties at either design time or runtime, and adding events which execute at run time.

The AstroServer is the middle tier of AstroMark’s multi-tier architecture. Applications and reports built with AstroMark Designer are deployed with AstroMark Server. It is the engine that monitors, manages, and serves concurrent user accesses to the deployed applications and/or databases.

The Browser is the user interface layer of AstroMark’s multi-tier architecture. The AstroMark Browser loads, creates, and displays application pages by communicating with the AstroMark Server. The pages appear exactly as you designed them.  Download a  version of the browser now to see for yourself how it works.

AstroMark Browser and an evaluation version of AstroDesigner are available for download.  When you download our Browser, use it to visit our test site and browse through our sample applications.
 

SUMMARY
 

HTML PAGE SOLUTIONS

Server-side database connectivity involves letting clients invoke a CGI, NSAPI, or ISAPI process on the Web server to link the database via Dynamic HTML.

Client side scripts allows users to download an applet, control, or script that connects to a database.  Scripts could be JavaScript, JScript, VBScript, or Perl.

Java and ActiveX are gaining ground because they allow a download-once/run-many-times (DORMANT) approach.  They can respond to the user without having to first talk to the web site.  However, not all browsers support Java, or ActiveX, or both.  If they do, the user may have disabled that option.  (See Site Building:  Hooking Your Site up to a Database, David Linthicum, ZDNet)

Browser incompatibility:   up to 50% of a developer’s time is spent on browser compatibility issues.  These are primarily JavaScript and Dynamic HTML issues but also includes Cascading Style Sheet (CSS) rendering, font rendering and sizes. (See Q&A with Glenn Davis: The High Cost of Browser Incompatibility, David Sims, WebTools)
 

Pros:

• It is the most common approach; most web database tools use server side architecture.  This approach also allows browser independence PROVIDED HTML is used and not Java or ActiveX.

Cons:

• Extremely high Internet traffic between the web and browser, resulting in, often, very slow responses.  According to CNN's technology survey, 48% of shoppers say that "pages took so long to load that I gave up."  (See CNN's Technology Survey)

• Involves substantial Internet traffic so broken connections are common, resulting in poor performance.   According to CNN's technology survey, 26% of shoppers say that "System crashed (got logged off) before completion."  (See CNN's Technology Survey)

• Browser incompatibility makes technology very hard to implement, making required technical knowledge level quite high.  Some browsers may not support the scripting language you are using.  For Example, only MSIE supports VBScript.  According to Glen Davis, a co-founder of the Web Standards Project, about 50% of a Web Developer’s time is spent programming around browser compatibility issues.  He said, “Most of it plays out with Dynamic HTML and just plain display. How the CSS is rendered, or how the fonts are rendered, the sizes, things like that. Things like Netscape's browser have a rendering error in which the fonts show up smaller than in Microsoft’s browser. Things of that nature just drive a person absolutely batty.“   (See Q&A with Glenn Davis: The High Cost of Browser Incompatibility, David Sims, WebTools) The issue is not only about Browser vendors, it is also on Browser versions—older Browser versions do not support improvements on the scripting languages.

• Client side scripts, which are interpreted by the Browser, are slow compared to Server side scripts.

• Cost to businesses is still very high due to the expertise requirements, and vendors pricing structure.

• Due to persistent connections, it limits concurrent user accesses and may lock out a user with time critical needs in favor of window shoppers.

• Technology is not sophisticated enough. None of over 90 products in the market produces outputs that can be run on the desktop, LAN, or the Web.

WEBIFIED LAN APPLICATIONS

Pro:

• The programmer does not have to worry about browser incompatibility issues.

• Less security problems as only members with the browser can interact with database.  But security across the Web is just as important as in the HTML method.

• Programmer concentrates more on user interface design and less on database.

• Programmer often does not have to learn a new programming or scripting language.  Instead, they use well established languages such as Object Oriented Pascal and C++.

• Resulting application can be executed on the desktop, LAN, WAN, or over the Web.

Cons:

• Runs only in one operating system environment.  Costly to create versions for other OS environments.

• Distribution problems. If changes occur, each user must be provided a new copy.

• Users may weary of downloading  a new interface for every application.

• Not ready for sophisticated heterogeneous Internet database access.

• Limits concurrent user accesses and may lock out a user with time critical needs.

•  A separate application is needed for different business needs, creating a maintenance nightmare.

HYBRID WEBIFIED LAN PAGES

Pros:

• Tools in this category, as demonstrated by AstroMark, can be easier to use, and hence, more cost effective.

• AstroServer does not perform the extra step of formatting the extracted data and creating a dynamic HTML page like other solutions do. Only data is sent to browser.

• On the AstroMark browser, all data read from the server are held in the cache so that if a user should scroll back to it, it will be there. This saves huge amounts of trips to the server, virtually eliminating broken pipes and disruptions, enabling a smoother transaction processing.

• AstroMark does not have any problem with database state management.  A patent is still pending for AstroMark's state management techniques that do not depend on the state of the database.  So AstroMark does not open a persistent channel for database connections as other solutions do. This increases Web Server availability, and enables the server to serve far more users than other solutions.

• Underlying language is based on established programming language, Object Oriented Pascal.

• Resulting application can be executed on the desktop, LAN, WAN, or over the Web.

Cons:

Like all Helper applications, each user needs to download AstroMark, but its size is relatively small and downloads in a few minutes.

---

All GenoTechs product names are trademarks or registered trademarks of GenoTechs, Inc.  Other brand and product names are trademarks or registered trademarks of their respective holders.