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.
- 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
Give examples of data that might flow from
each component to the next.
Dan Keller Technical Services © 2000