Datenbankanbindung an das Internet: Aktueller Stand und
Werbung
Datenbankanbindung an das Internet: Aktueller Stand und zukünftige Entwicklung Dipl.-Wirtsch.Inf Benedikt Wismans Universität Bamberg, Lehrstuhl für Wirtschaftsinformatik insb. Systementwicklung und Datenbankanwendung Feldkirchenstr 21, 96045 Bamberg [email protected] 1 Einführung Seit der Einführung des World Wide Web (WWW) entwickelt sich das Internet von einem Austauschforum für Wissenschaftler zu einem globalen und universellen Kommunikationsmedium. Insbesondere der kommerziell genutzte Anteil in Form von Werbung, Produktinformation, Entgegennahme von Bestellungen, Bestell- und Lieferverfolgung –um nur einige Bespiele zu nennen– wächst dramatisch. Der interaktive Zugriff auf aktuelle Unternehmensdaten über das WWW entwickelt sich zu einem unternehmenskritischen Produktionsfaktor. Die Aktualität und Interaktivität der Internetpräsenz eines Unternehmens kann aber nur durch die Integration geeigneter WWW-Komponenten in das betriebliche Informationssystem gewährleistet werden. Aufbauend auf dem relevanten Datenbestand als Integrationsbasis wird das betriebliche Informationssystem um WWW-basierte Anwendungssysteme ergänzt. Gegenstand dieses Papiers ist die Untersuchung und Bewertung von Architekturen WWW-basierter Anwendungssysteme aus der Sicht der Wirtschaftsinformatik. Dazu wird einleitend der verwendete Architekturrahmen vorgestellt. Danach werden die für die WWW-Anbindung relevanten Kriterien konventioneller, d.h. nicht WWW-basierter, Anwendungssysteme dargestellt. Der Hauptteil dieses Papiers stellt drei unterschiedliche Architekturformen WWW-basierter Anwendungssysteme vor und bewertet diese anhand der aufgestellten Kriterien. Den Abschluß bildet ein Ausblick auf mögliche zukünftige Entwicklungen. 2 Architekturrahmen Der in der weiteren Betrachtung verwendete Architekturrahmen ist das in der Wirtschaftsinformatik grundlegende ADK-Modell [FeSi94] für Anwendungssysteme. Das ADK-Modell unterscheidet in der Innensicht eines betrieblichen Anwendungssystems die Ebenen der Kommunikation (K), der Anwendungsfunktionalität (A) und der Datenhaltung (D). Die Ebene der Kommunikation wird hier auf die Betrachtung der grafischen Nutzerschnittstelle reduziert. In der grafischen Darstellung (s. Abb. 1-4) stellt der mittlere Balken die Aufteilung des Anwendungssystems zwischen Client (C) und Server (S) dar. Zusätzlich wird auf jeder Ebene im rechten Balken die verwendete Basissoftware bzw. das verwendete API benannt. Als Clients können beliebige grafische Workstations auftreten. Der Begriff Server steht nicht für eine konkrete Maschine, sondern für ein abstraktes Konzept, hinter dem sich beliebig viele dedizierte Servermaschinen (z.B. Datenbankserver und Webserver) verbergen können. 3 Eigenschaften konventioneller Anwendungssysteme Im folgenden werden die in diesem Kontext relevanten Eigenschaften konventioneller, also nicht WWW-basierter, Anwendungssysteme dargestellt. Im nächsten Kapitel wird dann untersucht, wie diese Eigenschaften in unterschiedlichen Architekturen WWW-basierter Anwendungssysteme realisiert werden. Abbildung 1 stellt die typische Architektur eines konventionellen Anwendungssystems dar. Kommunikation Win32 GUI C Anwendungsfunktionalität Datenhaltung C / C++ S RDBMS / SQL Abbildung 1: Client/Server-Architektur auf der Basis von RDA (remote data access) CLIENT / SERVER-ARCHITEKTUR Die Grenze zwischen Client und Server folgt typischerweise dem RDA-Konzept (remote data access) [RDA], da die heutigen Anwendungssysteme datenintegriert sind. Der Zugriff auf die Datenbasis erfolgt dabei über proprietäre Protokolle oder über standardisierte Middlewarekomponenten. In der Windows-Welt hat sich hier als Standard insbesondere ODBC (Open Database Connectivity) [ODBC] von Microsoft etablieren können. Das ODBC – API setzt auf dem Call Level Interface von SQL [SQL] auf und wird von fast allen großen Datenbankherstellern, wie z.B. der Software AG, unterstützt. GRAFISCHE NUTZEROBERFLÄCHE Das AWS präsentiert sich dem Nutzer als ein Multiple Document Interface (MDI), in welchem gleichzeitig mehre Client-Fenster, nicht-modale und modale1 Dialoge geöffnet sein können. Die zu bearbeitenden Daten werden in den Client-Fenstern angezeigt und können über die üblichen grafischen Controls wie z.B. Pushbuttons oder durch Menüauswahl manipuliert werden. Der Fensteraufbau und die Datendarstellung sind voneinander unabhängig. Die Darstellung ist fensterorientiert. SESSION-MANAGEMENT Der Programmstart erfolgt definiert durch die Systemanmeldung (Login), das Programmende durch die Abmeldung (Logout). Zwischen Login und Logout besteht eine kontinuierliche, personalisierte Verbindung (Session) zwischen dem Nutzer und dem Anwendungssystem. Die Session ist dabei unabhängig vom Datenzugriff: während einer Session können 0 bis beliebig viele Datenbankverbindungen geöffnet sein. Dabei können gleichzeitig verschiedene Datenbanken referenziert werden. 4 Architekturen WWW-basierter Anwendungssysteme In diesem Kapitel werden drei Architekturformen WWW-basierter Anwendungssysteme vorgestellt, die so oder in sehr ähnlicher Form bereits im Internet Standard sind. Es handelt sich um die CGI-basierte-, die ASP-basierte- und die Applet-basierte Architekturform. 1 Zu jedem Zeitpunkt kann genau ein modaler Dialog dargestellt werden In dieser Auflistung fällt die ASP-basierte Architekturform auf, da es sich um eine proprietäre Lösung für den Webserver Microsoft Information Server III handelt, während die beiden anderen Architekturformen auf offenen Standards basieren. Da aber auch in der ASP-basierten Architektur alle ODBC-fähigen Datenbanken und alle Webbrowser unterstützt werden, und diese die Lücke zwischen CGI-basierten und Applet-basierten Systemen füllt, wird sie hier thematisiert. 4.1 CGI-basierte Architekturform Durch das CGI (Common Gateway Interface) [CGI] wird es WWW-Clients ermöglicht, aus HTMLFormularen [FORM] heraus ausführbare Programme, sog. CGI-BINs, auf dem Webserver zu starten. Das CGI-BIN kann methodenabhängig (POST und GET) über Umgebungsvariable und die Kommandozeile parametrisiert werden. Neben CGI existieren weitere Implementierungen von Gateway-Schnittstellen wie z.B. ISAPI (Internet Server Application Programming Interface) [ISAPI] von Microsoft, die sich aber bezüglich der Architektur nicht voneinander unterscheiden. Abbildung 3 zeigt diese Architektur im ADK-Modell. Kommunikation C Anwendungsfunktionalität S Datenhaltung HTML / HTTP CGI -BIN (C / C++, Skriptsprachen) RDBMS / SQL Abbildung 2: CGI-basierte Architekturform 4.1.1 Eigenschaften CGI-basierter Anwendungssysteme CLIENT / SERVER-ARCHITEKTUR Der Datenzugriff ist für den Client transparent. Die für den Datenzugriff notwendigen SQLStatements sind Teil des CGI-BINs. Der Client erhält Ergebnismengen und/oder Fehlermeldungen als dynamisches HTML-Dokument zurück. Die Kommunikation zwischen Client und Webserver folgt dem HTTP (HyperText Transport Protocol) [HTTP]. GRAFISCHE NUTZEROBERFLÄCHE Nach der Betätigung des SUBMIT-Buttons auf der Formularseite (siehe Quelltextbeispiel) ruft der Client das CGI-BIN des Servers auf und wartet dann auf die Übergabe der Ergebnisseite, welche die Formularseite im Webbrowser ersetzt. Weitere Bearbeitungen der Formularseite sind nicht möglich. Die Nutzeroberfläche ist somit nicht fensterorientiert, sondern seitenorientiert. SESSION-MANAGEMENT Ein Session-Management existiert nicht. Jeder Start eines CGI-BINs stellt sowohl aus Sicht des Clients wie auch aus Sicht des Servers eine in sich abgeschlossene Programmausführung dar. Die Zwischenspeicherung von Informationen, die den Seitenaufbau der Ergebnisseite überleben, ist nicht möglich. Dies hat insbesondere zur Folge, daß der Nutzer bei jedem Start eines CGI-BINs die für den Datenzugriff notwendige Autorisierung erneut vornehmen muß. 4.1.2 Code-Beispiel Das folgende Codefragment zeigt den HTML-Code einer typischen Login-Maske mit der Möglichkeit, aus einem einfachen Menü die Form der weiteren Bearbeitung auszuwählen. Es ist zu beachten, daß die Eingabe des Login-Namens und des Passworts beim Aufruf des nächsten CGIBINs, z.B. im Bereich der Kundenverwaltung, erneut vorgenommen werden muß. )2500(7+2' SRVW$&7,21 PHQXH[H"BB,1)2BB1$0( 7)250! 3!1DPH %5!,13871$0( 1$0(7<3( 7(;79$/8( ,KU1DPH! 3!3DVVZRUG %5!,13877<3( 3$66:2571$0( 3DVVZRUW! 3!$XVZDKO %5! ,13877<3( 5$',21$0( .XQGHQ9$/8( &+(&.('!.XQGHQYHUZDOWXQJ ,13877<3( 5$',21$0( $XIWUlJH9$/8( !$XIWUlJH ,13877<3( 5$',21$0( %HVWDQG9$/8( !%HVWDQG 3!,13877<3( 68%0,79$/8( 2.!,13877<3( 5(6(79$/8( /|VFKHQ! )250! 4.1.3 Fazit Auf CGI basierende Systeme können aufgrund des nicht vorhandenen Session-Managements und der seitenorientierten Nutzeroberfläche nicht für stark interaktive Anforderungen eingesetzt werden. Für anonyme Auskunftssysteme, die einfach parametrisiert sind, wie z.B. die Fahrplanauskunft der Deutschen Bundesbahn [DB], können CGI-basierte Systeme aber effizient eingesetzt werden. 4.2 ASP-basierte Architekturform ASP (active server pages) [ASP] ist eine Erweiterung des Webservers Internet Information Server III von Microsoft. Wie der Name schon andeutet, stellt der Webserver eine Ablaufumgebung für Skripte in HTML-Dokumenten bereit. Skripte, die mit dem Zusatz RUNAT=SERVER versehen sind oder innerhalb der Trennzeichen <% und %> stehen, werden auf dem Webserver ausgeführt, während andere Skripte konventionell auf dem Client ausgeführt werden. Serverskripte haben Zugriff auf den folgenden Satz von Objekten: APPLICATION OBJECT Eine Applikation besteht aus allen Dateien und Unterverzeichnissen eines virtuellen Verzeichnisses auf dem Webserver. Für Start und Ende jeder Applikation können globale Initialisierungs- bzw. Aufräumfunktionen codiert werden. Der Zugriff auf das Application Object ist von allen Instanzen der Applikation, also allen Sessions, transaktionsgeschützt (lock/unlock) möglich. SESSION OBJECT Für jede Instanz der Applikation verwaltet der Webserver ein Session Object, in dem u. a. beliebige Variablen erzeugt, geschrieben und gelesen werden können. Auch für das Initialisieren bzw. Zerstören von Session Objects können „Konstruktoren“ und „Destruktoren“ codiert werden. REQUEST OBJECT UND RESPONSE OBJECT Das Request Object stellt eine höhere Schnittstelle zu den Übergabevariablen des HTML-Formulars zur Verfügung. Das Response Object dient der komfortablen Ausgabe von Daten in die Antwortseite, die vom Server an den Client zurückgeschickt wird. SERVER OBJECT Das Server Object bietet Zugriff auf Methoden, die der Webserver zur Verfügung stellt. Dazu gehören z.B. das Instantiieren neuer Objekte oder die Abbildung von virtuellen auf physische Zugriffspfade. Abbildung 4 zeigt die ASP-Architektur im ADK-Modell. Im Gegensatz zur CGI-basierten Architektur ist die Ebene der Anwendungsfunktionalität zu einem geringen Teil dem Client zugeordnet. Während in der CGI-basierten Architektur lediglich statische Client-Skripte Verwendung finden, welche insbesondere die Oberflächengestaltung betreffen, können in der ASPbasierten Architektur Client-Skripte dynamisch durch Server-Skripte erstellt werden. So kann z.B. der Code einer JavaScript-Funktion [JSCRIPT], die durch das Betätigen eines Buttons aufgerufen wird, in Abhängigkeit des Ergebnisses einer Datenbankabfrage vollkommen unterschiedliche Aktionen ausführen. Kommunikation C Anwendungsfunktionalität S Datenhaltung HTML / HTTP Client-Skripte Server-Objekte, Server-Skripte RDBMS / SQL Abbildung 3: ASP-basierte Architektur 4.2.1 Eigenschaften ASP-basierter Anwendungssysteme CLIENT / SERVER-ARCHITEKTUR Der Datenzugriff ist für den Client transparent. Die für den Datenzugriff notwendigen SQLStatements sind Teil der ASP-Seite und werden nach Anforderung der Seite durch den Client vom Server ausgeführt. Der Client erhält Ergebnismengen und/oder Fehlermeldungen als dynamisches HTML-Dokument zurück. Ein Server-Skript kann ActiveX Data Objects (ADO) erstellen und ändern. So können ADO-Objekte verwendet werden, um Anfragen nach Daten über einen ODBCTreiber an einen Datenbankserver zu senden. GRAFISCHE NUTZEROBERFLÄCHE Die grafische Nutzeroberfläche ist wie bei CGI-basierten Architekturen seitenorientiert, nicht fensterorientiert. Das Ausführen der Server-Funktionen einer ASP-Seite kann nur durch den Aufruf dieser Seite angestoßen werden. So ist es insbesondere nicht möglich, Funktionen auf dem Server durch das Betätigen eines Buttons auf der gleichen ASP-Seite anzustoßen. SESSION-MANAGEMENT Das Session-Management wird vom Webserver über das Application Object und das Session Object realisiert. Der erste Aufruf einer ASP-Seite der Applikation führt zur Instantiierung des Session- Objects und zur Ausführung der Session_OnStart()-Funktion, die zur Initialisierung der Session verwendet werden kann. Das Ende der Session wird dem Webserver entweder explizit durch den Aufruf der Session.Abandon()-Methode mitgeteilt oder durch timeout festgestellt. In beiden Fällen wird abschließend die Session_OnEnd()-Funktion aufgerufen, in der Aufräumarbeiten codiert werden können. 4.2.2 Code-Beispiel Das folgende Codefragment entstammt einer ASP-Seite, die von einem als Login-Maske dienenden HTML-Formular aufgerufen wird. Über das Request Object werden die Formularfelder LoginName und Passwort abgerufen und im Session Object gespeichert. Aus der Bezeichnung des ODBC-DSN, dem LoginName und dem Passwort wird der ODBC-ConnectionString erzeugt und ebenfalls als Variable im Session Object gespeichert. YDU/RJLQ1DPH YDU3DVVZRUW /RJLQ1DPH 5HTXHVW)RUP/RJLQ1DPH 3DVVZRUW 5HTXHVW)RUP3DVVZRUW 6HVVLRQ'61 )/(;12: 6HVVLRQ8,' /RJLQ1DPH 6HVVLRQ3:' 3DVVZRUW 6HVVLRQ&RQQHFWLRQ6WULQJ GVQ 6$*)/(;XLG /RJLQ1DPHSZG 3DVVZRUW! Die ConnectionString-Variable des Session Object wird innerhalb der Session von jeder nachfolgend aufgerufenen ASP-Seite ausgelesen, um die Verbindung zur Datenbank aufzubauen. Nach dem Ausführen des SQL-Statements wird das Response Object zur formatierten Ausgabe der Ergebnismenge verwendet. YDU2%-GE&RQQHFWLRQ 2%-GE&RQQHFWLRQ 6HUYHU&UHDWH2EMHFW$'2'%&RQQHFWLRQ 1HXHV$FWLYH;'DWD2EMHFW 2%-GE&RQQHFWLRQ2SHQ6HVVLRQ&RQQHFWLRQ6WULQJ $XVOHVHQGHU&RQQHFW3DUDPHWHU YDU64/4XHU\ YDU,1)2B/LVW 64/4XHU\ 6(/(&7',67,1&7VWXGIDFKVSH]LDOLVLHUXQJLQKDEHU)520/67BWSJUXSSH ,1)2B/LVW 2%-GE&RQQHFWLRQ([HFXWH64/4XHU\ 5HVSRQVH:ULWH +!/HKUVWXKOIU,1)2B/LVWVWXGIDFK LQVE,1)2B/LVWVSH]LDOLVLHUXQJ 3!,1)2B/LVWLQKDEHU+! ,1)2B/LVW&ORVH! 4.2.3 Fazit Die Unterstützung des Session-Managements ist ein wichtiger Meilenstein auf dem Weg von einer losen Sammlung von HTML-Dokumenten hin zu einem geschlossenen Anwendungssystem. Durch den dynamischen Zusammenbau von Client-Skripten kann der Programmfluß analog zu kontextabhängigen Menüs gezielt gesteuert werden. Allerdings bleibt das Manko der seitenorientierten Nutzerschnittstelle bestehen, so daß stark interaktive Systeme unter Verwendung von ASP kaum nutzerfreundlich codiert werden können. 4.3 Applet-basierte Architektur Applets sind in Java [JAVA] geschriebene Programme, die innerhalb eines Java-fähigen Webbrowsers [JVBROW] ausgeführt werden. Unter den vielen interessanten Aspekten, welche die Programmiersprache Java bietet, werden hier lediglich die Verwendung von Applets in HTMLDokumenten, der Zugriff auf Datenbanken aus Applets heraus und die Möglichkeiten der grafischen Nutzeroberfläche thematisiert. Abbildung 4 zeigt die Architektur Applet-basierter Anwendungssysteme im ADK-Modell. HTML / HTTP Java AWT Kommunikation C Anwendungsfunktionalität Datenhaltung Java-Applets S RDBMS / SQL Abbildung 4: Java-basierte Architektur 4.3.1 Eigenschaften Applet-basierter Anwendungssysteme CLIENT / SERVER-ARCHITEKTUR Der Zugriff auf die Datenbasis erfolgt durch den Client. Die für den Datenzugriff notwendigen SQL-Statements sind Teil des Java-Applets und werden über die JDBC-Schnittstelle an den Server weitergeleitet. Datenbanken, die JDBC nicht unterstützen, können alternativ über die JDBC-ODBC- Brücke angesprochen werden. Diese Konfiguration hat aber den Nachteil, daß der ODBC-Treiber für die Datenbank auf dem Client installiert werden muß. GRAFISCHE NUTZEROBERFLÄCHE Die grafische Nutzeroberfläche kann durch Verwendung des Java AWT (Java Abstract Window Toolkit) beliebig gestaltet werden. Die Nutzeroberfläche ist somit nicht seitenorientiert, sondern fensterorientiert. SESSION-MANAGEMENT Das Session-Management muß wie in konventionellen Anwendungssystemen vom Programmierer codiert werden. Dazu stehen die üblichen Konstrukte der Programmiersprache Java zur Verfügung. Allerdings birgt die Codierung einige Schwierigkeiten, da meistens nicht bekannt ist, welche Webseiten überhaupt zu einer Applikation gehören und welche nicht. Da Java aber eine automatische garbage collection zur Verfügung stellt, kann dieser Aspekt vernachlässigt werden. 4.3.2 Code-Beispiel Das folgende Codefragment demonstriert den Zugriff auf die JDBC-ODBC-Brücke aus einer JavaFunktion, die Teil eines Applets ist. Die Werte der Übergabevariablen SqlUser, SqlPassword und SqlDatabase sind vor dem Aufruf dieser Funktion über ein Fenster eingelesen worden. SXEOLFERROHDQORJLQ6WULQJ6TO8VHU6WULQJ6TO3DVVZRUG6WULQJ6TO'DWDEDVH ^ 8VHU 6TO8VHU 3DVVZRUG 6TO3DVVZRUG 'DWDEDVH 6TO'DWDEDVH 6WULQJ85/ MGEFRGEF6TO'DWDEDVH WU\^ ` ` &ODVVIRU1DPHVXQMGEFRGEF-GEF2GEF'ULYHU FRQ 'ULYHU0DQDJHUJHW&RQQHFWLRQ85/6TO8VHU6TO3DVVZRUG 'DWDEDVH0HWD'DWDGPD FRQJHW0HWD'DWD 6\VWHPRXWSULQWOQ?Q9HUEXQGHQPLW GPDJHW85/ UHWXUQWUXH 4.3.3 Fazit Java-Applets bieten durch das AWT für die Gestaltung der Nutzeroberfläche und durch JDBC für den Datenzugriff nahezu alle Möglichkeiten einer konventionellen Programmiersprache bei der Erstellung WWW-basierter Anwendungssysteme. Allerdings ist die vollständige Verlagerung der Anwendungsfunktionalität vom Server auf den Client bei mittleren bis großen Anwendungssystemen nachteilig, da zum einen das Laden der Klassen lange dauern kann, zum anderen keine Annahmen über die Leistungsfähigkeit der Clientmaschine getroffen werden können. 5 Ausblick auf zukünftige Entwicklungen Zweifelsohne werden WWW-basierte Anwendungssysteme zukünftig insbesondere auf Java aufbauen. Allerdings bieten auch die beiden anderen hier vorgestellten Architekturformen für bestimmte Aufgaben Vorteile. Es liegt also nahe, alle drei Ansätze in einer Architektur WWW-basierter Anwendungssysteme zu integrieren. Die Integrationsbasis muß dabei der kleinste gemeinsame Nenner der oben dargestellten Architekturformen sein: die Webseite. Aus der ASP-basierten Architektur werden dabei die Bündelung von zusammengehörigen Webseiten zu Anwendungssystemen und das Session-Management übernommen. Innerhalb dieses Applikationsrahmens können die Webseiten das ganze Spektrum möglicher Formen von Anwendungsfunktionalität enthalten: Script-Funktionen, die auf dem Server ausgeführt werden, Script-Funktionen, die auf dem Client ausgeführt werden, Aufrufe konventioneller CGI-BINs oder anderer Gateway-Schnittstellen und Java-Applets. Auf diese Weise kann die optimale Aufspaltung der Ebene der Anwendungsfunktionalität zwischen Client und Server vorgenommen werden. So kann z.B. eine sehr aufwendige Datenbankabfrage als CGI-BIN auf dem Server gestartet werden, der abrupte Seitenwechsel kann durch Framing-Technik abgemildert werden. Kleine Datenbankabfragen wie das Füllen einer Listbox können beim Seitenaufbau durch ein Serverskript oder bei Bedarf durch ein Applet durchgeführt werden. Alle Datenbankzugriffe werden mit der Autorisierungsinformation parametrisiert, die das Session Object vorhält. So entfällt auch beim Aufruf von CGI-BINs die lästige Neueingabe von Nutzername und Passwort. Weitergehende Verbesserungen der oben beschriebenen Architekturformen können z.B. durch Ergänzung des HTTP um ein asynchrones Kommunikationsprotokoll zwischen Webserver und Webbrowser erreicht werden. In Analogie zur non-blocking Socket-Verbindung kann so eine optimale Auslastung von Client und Server erreicht werden. 6 Literatur- und Webseitenverzeichnis [FeSi94] Ferstl O.K., Sinz E.J.: Grundlagen der Wirtschaftsinformatik. Band 1, 2. Auflage, Oldenbourg, München 1994 [DB] http://www.bahn.de [ASP] http://www.microsoft.com/iis; http://www.cobb.com/asp/freevw79.htm [JAVA] http://www.javasoft.com [JVBROW] http://www.netscape.com; http://www.microsoft.com/ie; [RDA] http://www.itaa.org/G6.htm [ODBC] http://www.bayon.com/cstar/database/connect.htm [SQL] http://www.bayon.com/cstar/database/sql.htm [CGI] http://kaos.erin.gov.au/www-standards/www-authoring/cgi.html [FORM] http://www.environment.gov.au/www-standards/www-authoring/form.html [HTTP] http://www.w3.org/Protocols/HTTP/AsImplemented.html [JSCRIPT] http://tips-tricks.com/j_script.html [ISAPI] http://www.bnt.com/inetsdk/default.htm
