The Architecture of Databases on the Web

• It's useful to view and update databases from your web browser.
• Connecting web pages to databases is the most popular type of CGI application.

Architectures to Consider

Implementations of these Architectures -- Most Are Proprietary

• HTML with embedded SQL
• Template-based, e.g.
  • Allaire's ColdFusion
  • Microsoft IDC
  • Easy to use, quick successes, but you might outgrow it
• Server-side scripting, e.g.
  • Netscape's LiveWire
  • Microsoft's Visual InterDev
  • Servlets
• Server extensions, e.g.
  • ISAPI (Microsoft)
  • NSAPI (Netscape)
  • VelociGen
  • Ties you to a particular vendor
• Client-side scripting, e.g.
  • JavaScript
  • VBScript
  • ActiveX
  • Possible exposure of database structures or triggering client-side paranoia (ActiveX)
• Applets, e.g.
  • Java
  • other languages that compile to bytecodes (none yet)
  • Java is fragmented
• Database with built-in web server to call stored procedures or compiled SQL executables
  • Oracle's Web Application Server
• Use Perl with DBI and the appropriate DBD modules.
  • The approach advocated in this course
• Use Win32::ODBC instead of DBD::ODBC
  • This has more functionality...
  • but locks you in to the Win32 Perl.
  • Your scripts won't be portable to non-win32 platforms.
  • and it's slower than DBD::ODBC

Which Implementation to Choose?

• Desiderata: scalability, modularity, vendor-neutrality.
• It should be possible to replace any component -- the browser, the web server, or the database.
• It should be possible to connect to diverse databases from a single application.
• Replacing a component should have minimum impact on the others.
• Scenarios:
  • Capacity of Access is exceeded so switch to Oracle
  • Connect to a Sybase-based legacy application
  • IIS lacks some desired feature so replace it with Apache
  • Many more
• Performance considerations may influence the choice of architecture.
• The data flows:

Review