FernUniversität Hagen
Lehrstuhl für Praktische Informatik I
Prof. Dr. Schlageter
Seminar 1906
Architektur und Anwendungen von WWW -
Informationssystemen
Beitrag: Datenbankanbindung im WWW
        von Gabriele Hawlena und Nicole Richter
WS 1999/2000
 
 
 
 
 
 
 
 
 

Datenbankanbindung im WWW
 
 

1. Einleitung

Viele Informationen im Web sind statisch dargestellt. D. h. die entsprechenden Dokumente im Web werden erstellt und erhalten Information, die zum Erstellungszeitpunkt aktuell ist. Je nach Art der Information sind diese Daten u. U. sehr schnell überholt.

Die aktuellen Daten hingegen liegen oft bereits elektronisch vor. Sie sind in den DV-Systemen der Firmen etc. gespeichert. In dem Seminarbeitrag geht es darum, welche Möglichkeiten es gibt, um die Informationen aus den DBMS heraus im Internet zur Verfügung zu stellen.

Nach einer Einleitung werden in Kapitel 3 sieben mögliche Philosophien erläutert. Auf diese Philosophien wird dann in den Kapiteln 4 bis 10 eingegangen. Dabei wird in jedem Kapitel zuerst das Prinzip der entsprechenden Philosophie beschrieben. Im Anschluss folgen Erläuterungen an konkreter Software, die nach diesem Prinzip arbeitet.

In Kapitel 11 wird als Besonderheit der Lotus Domino-Server behandelt.

Kapitel 12 beschäftigt sich mit den Besonderheiten bei Interaktionen im Netz. Speziell geht es hier um einen Vergleich zur klassischen Transaktionsprogrammierung. Auch hier wird mit dem Internet Transaction Server ein Realisierungsbeispiel dargestellt.

Kapitel 13 geht zum Schluss noch einmal auf Besonderheiten im Sicherheitsbereich (Firewall) bei der DBMS-Anbindung ein.
 

2. Gliederung

1. Einleitung

2. Gliederung

3. Mögliche Philosophien

4. Statische HTML-Seiten

5. Report-Generator-Schnittstellen
    5.1. Prinzip
    5.2. GDIdb
        5.2.1. Arbeitsweise
        5.2.2. Ausblick

6. Webserver mit DB-Zugriff
    6.1. Prinzip
    6.2. ODBC/JDBC
      6.2.1. ODBC-Architektur
      6.2.2. JDBC
      6.2.3. Zusammenfassung
   6.3. Internet database Connector
      6.3.1. Die Struktur des Internet Database Connectors
      6.3.2. Die IDC-Datei
      6.3.3. Die HTX-Datei
      6.3.4. Datenzugriff über ODBC

7. Datenbanksystem mit integriertem Web-Server
    7.1. Prinzip
    7.2. Informix Universal Server mit Web Data Blade

8. Web-Server mit Komponentenschnittstelle
    8.1. Prinzip
    8.2. Internet Information Server mit ASP
      8.2.1. ASP-Architektur
      8.2.2. Datenbankanbindung mit Database-Access-Komponente
      8.2.3. Datenbankanbindung mit Koomponenten-Schnittstelle
    8.3. Oracle Application Server
        8.3.1. OAS Architekturüberblick
        8.3.2. Client - Server Interaktion
        8.3.3. Zusammenfassung

9. Standardgateways
    9.1. Prinzip
    9.2. CGI und FastCGI
    9.3. Server-Erweiterungen durch APIs

10. Middleware
    10.1. Prinzip
    10.2. ColdFusion und WebObjects
        10.2.1. ColdFusion
        10.2.2. WebObjects

11. Lotus Domino
    11.1. Lotus Notes
    11.2. Lotus Domino
      11.2.1. Prinzip
      11.2.2. Konfiguration des Domino-Servers
    11.3. Domino – Web - Sicherheit
    11.4. Zusammenfassung

12. Interaktion im Web
    12.1. Vergleich zu klassischen Transaktionen
    12.2. Internet Transaction Server von SAP
      12.2.1. SAP R/3
      12.2.2. Der Internet Transaction Server
      12.2.3. Reporting innerhalb SAP R/3
      12.2.4. WebReporting mit dem Internet Transaction Server
      12.2.5. Zusammenfassung

13. Datensicherheit / Firewall - Besonderheiten bei DBMS-Anbindung
   13.1. Web-Server als Screened Host Firewall
    13.2. Dual-Homed Gateways
    13.3. Besonderheiten bei der DBMS-Anbindung
    13.4. Zusammenfassung

14. Zusammenfassung / Ausblick

15. Glossar

16. Literaturverzeichnis
 
 
 

3. Mögliche Philosophie

Die Methodik der datenbankbasierten Anwendungsentwicklung auf Basis von Internet-Technologie steckt ebenso noch in den Kinderschuhen wie die technologische Basis selbst. So hat sich auch noch kein Ansatz als dominierend herauskristallisieren können, wie es im Bereich der konventionellen Anwendungsentwicklung mit der Client-Server-Technologie auf der Basis von relationalen Datenbanken der Fall ist. Anwendungen im Internet sind mit normalen Anwendungen nur bedingt vergleichbar. Sie basieren in einem hohen Maße auf der Rekonstruktion vorhandener Anwendungsdaten und Anwendungsfunktionalität. Es ist also ein wichtiges Teilgebiet der Anwendungsentwicklung für das Internet, vorhandene Ressourcen internetkompatibel aufzubereiten. Dies trifft auch und gerade auf Informationen zu, die in (Unternehmens-)Datenbanken organisiert sind. [Assfalg et al. 1998]

Es gibt vielfältige Ansätze, Datenbanken und Internet-Server zu kombinieren. Welcher Ansatz für eine konkrete Problemstellung der Optimale ist, hängt von der Art der Anwendung ab, die entwickelt werden soll. [Assfalg et al. 1998]

Die beiden obigen Zitate weisen bereits auf ein großes Problem dieser Thematik hin. Es gibt viele, zum Teil sehr unterschiedliche Lösungen. Keine dieser Lösungen hat sich endgültig durchgesetzt. Je nach Anwendungsfall wird in der Praxis nur ein Teil der Möglichkeiten relevant sein, weil Web-Server und / oder Datenbanksysteme andere Möglichkeiten nicht unterstützen. Welche der im Folgenden beschriebenen Lösungen dann die Richtige ist, muss im konkreten Fall sorgfältig abgewogen werden.

In den folgenden Kapiteln stehen die Möglichkeiten zur Übernahme der in den (Unternehmens-) Datenbanken verfügbaren Information in das Internet im Mittelpunkt. In den Kapiteln 4 bis 10 werden sieben Philosophien beschrieben. Die Philosophien unterscheiden sich in der Stärke der Kopplung zwischen Web-Server und Datenbank- Managementsystem.

Bei statischen HTML-Seiten besteht keinerlei technische Koppelung. Die Erstellung der HTML-Seiten erfolgt unabhängig von dem DBMS.

Bei der Erstellung der HTML-Seiten über eine Report-Generator-Schnittstelle hingegen wird zum Zeitpunkt der Erstellung der Seite der aktuelle Stand aus dem DBMS entnommen. Dazu wird ein entsprechendes Tool zur Erstellung von Reports verwendet. Vorteil dieser Lösung ist, dass die HTML-Seiten in beliebigen Zeitabständen neu erstellt werden können. Je nach Report-Generator kann dies sogar maschinell geschehen.

Bei der Erstellung der HTML-Seiten mit einem Web-Server mit DB-Zugriff steuert der Web-Server die Aktualisierung der HTML-Seite. Dies kann immer dann geschehen, wenn ein neuer Zugriff auf die Seite erfolgt. Dazu sind alle Informationen, die für die Datenbankanfrage notwendig sind, in der HTML-Seite zu integrieren. Die Anfrage an das DBMS erfolgt entsprechend zeitnah. Im Gegensatz zu den vorhergehenden Lösungen kann hier auch eine flexible Anfrage erfolgen. Z. B. ist es möglich, auf der vorhergehenden HTML-Seite Filterbedingungen einzulesen, die dann in die Datenbankanfrage aufgenommen sind.

Die stärkste Kopplung zwischen DBMS und Internet findet man bei Datenbanksystemen mit integriertem Web-Server.

Eine weitere Möglichkeit ist die Nutzung der (vorhandenen) Komponenten-Schnittstelle des Datenbanksystems vom Web-Server aus. Man benötigt dazu einen Web-Server mit Komponentenschnittstelle.

Standardgateways oder Middleware können ebenso für die Datenbankanbindung eingesetzt werden.
 

 4. Statische HTML-Seiten

Auch heute noch sind viele Seiten im Internet als statische HTML-Seiten konzipiert. [Assfalg et al. 1998] schreibt zur Historie von Anwendungsentwicklung und Datenbankanbindung im Internet:

Anwendungen auf dem Internet hatten in der Vergangenheit mehr Merkmale klassischer Printprodukte wie Bücher, Zeitschriften, etc. als solche von Softwareprogrammen. Interaktivität und Funktionalität standen eindeutig im Hintergrund. Es lag daher nahe, die Methoden des Desktop Publishing (DTP) und die einschlägigen Werkzeuge wie Textverarbeitungssysteme, Satzprogramme, etc. zu verwenden, um internetkompatible Dokumente zu generieren. Mit zunehmender Verfügbarkeit leistungsfähiger, plattformunabhängiger und damit internetkompatibler Objektmodelle oder Komponententechnologien (Java, ActiveX) ändert sich dies jedoch zunehmend. Diese werden nunmehr auch von vielen Entwicklungsumgebungen der klassischen Anwendungsentwicklung unterstützt, die damit ebenfalls für die Entwicklung von internetkompatiblen Anwendungen genutzt werden können. Gleichzeitig werden auch Datenbanksysteme um Schnittstellen ergänzt, die dieser neuen Objektwelt gerecht werden. Neben vorhandenen Standardschnittstellen wie Open Database Connectivity (ODBC) werden zunehmend auch objektorientierte Application Programming Interfaces (APIs) auf der Basis dieser neuen Objektmodelle angeboten.
 
 

Abb. 4.1: Zwischen Web-Server und DBMS gibt es bei statischen HTML-Seiten keine Verbindung
 

Auch heute noch finden sich im Internet viele statische HTML-Seiten. Optionen wie Animation oder interaktives Handling sind im Rahmen der vorliegenden Seminararbeit nicht zu betrachten. Die folgenden Ausführungen beziehen sich deshalb auch auf dynamische HTML-Seiten, solange es technisch keinen Zugriff auf andere Datenbestände gibt. Statisch ist hier also in Bezug auf die Datenbeschaffung zu sehen.

Abb. 4.1. zeigt einerseits den Web-Server mit den Clients sowie den Zugriff auf die HTML-Seiten. Auf der anderen Seite des Bildes steht auch das DBMS. Zwischen beiden Teilen gibt es aber keinerlei Verbindung.

Eine solche Lösung ist technisch sehr einfach. Allerdings ist der manuelle Pflegeaufwand auf Dauer u. U. enorm. Je nach Änderungshäufigkeit der Daten im DBMS können die Daten schon nach Fertigstellung der HTML-Seite wieder veraltet sein. Außerdem sind - um die HTML-Seiten aktuell zu halten - alle relevanten Änderungen im DBMS auf den HTML-Seiten nachzuvollziehen. Da die Pflege einer einzelnen HTML-Seite nicht von mehreren Personen gleichzeitig erfolgen kann, sind die Grenzen einer solchen Lösung schnell ersichtlich.

Eine Übernahme der Daten aus einem DBMS in das Internet über statische HTML-Seiten empfiehlt sich also nur dann, wenn die Daten ebenfalls statisch sind und der Umfang der Daten auch gering ist.
 

5. Report-Generator-Schnittstellen

Report-Generator-Schnittstellen stellen eine technische Verbindung zwischen Datenbanksystem und HTML-Seiten und damit dem Web-Server her. Sie sind eine meist einfach zu handhabende Schnittstelle. Allerdings sind auch die Möglichkeiten stark eingeschränkt.
 

5.1. Prinzip

Eine sehr gute Beschreibung des Prinzips der Report-Generator-Schnittstellen findet sich in [Assfalg et al. 1998]:

Dies ist sicherlich der einfachste, aber zugleich unflexibelste Ansatz Datenbanken und Internet-Technologie zusammenzubringen. Man verwendet spezielle Report-Generator-Schnittstellen, die statt einer Ausgabe in ein Textformat (Rtf, Postscript, etc.) die Dokumente in HTML erzeugen. Diese so erzeugten Seiten können dann als normale HTML-Seiten von jedem beliebigen Web-Server verwendet werden. Es ist hierfür auf der Seite des Web-Servers keinerlei spezielle Erweiterung erforderlich.

Die Interaktion mit derartigen Anwendungen ist natürlich sehr eingeschränkt. Man kann zwar die Aktualisierung der in diesen Dokumenten angebotenen Daten automatisieren, indem man bei einer Änderung der Daten in der Datenbank, z. B. gesteuert durch Trigger, die Aktualisierung der Seiten veranlasst. Aber die Manipulation der erzeugten Dokumente durch den Anwender (z. B. durch eine parametrisierte Abfrage) ist mit dieser Technologie nicht möglich. Die meisten Datenbanksysteme bieten mittlerweile Assistenten oder Schnittstellen, die auf diese Weise arbeiten, an.

In den meisten Fällen sind die Möglichkeiten der Layoutgestaltung beschränkt auf tabellarische Darstellung der Daten der zugrundeliegenden Abfrage. Die Erstellung derartiger Berichte kann interaktiv erfolgen, z. B. durch Dialoge oder auch programmiert, d. h. durch die Erstellung von Skripten in einer vom System vorgegebenen Syntax. Die Ausdruckmöglichkeiten des jeweiligen Verfahrens sind jedoch meist sehr eingeschränkt. D. h., es stehen meist nicht die Konstrukte der strukturierten Programmierung zur Verfügung, und auch die Arbeit mit Prozeduren oder gar Objekten wird nicht unterstützt. Der Vorteil ist aber die einfache Bedienbarkeit auch für Anwender, die wenig Programmiererfahrung besitzen.
 

 
Abb.5.1: Verwendung einer Report-Generator-Schnittstelle [Assfalg et al. 1998]
 

Die Lösung der Datenbankanbindung an das WWW über Report-Generator-Schnittstellen ist ebenfalls technisch sehr einfach. Report-Generatoren wenden sich oft an Anwender ohne (oder mit wenig) Programmiererfahrung, die - unabhängig von Softwareentwicklern - Auswertungen oder Berichte erstellen wollen. Die Benutzeroberfläche ist meist einfach gestaltet. Man muss lediglich die Strukturen der Datenbanken kennen (Welche Datenbanken gibt es? Wie stehen sie in Beziehung zueinander?). Bei vielen Report-Generatoren lässt sich die Berichtserstellung zusätzlich automatisieren.

Allerdings ist das Ergebnis einer Report-Generator-Schnittstelle leider einigen Einschränkungen unterworfen. Das Einbinden von Animationen etc. dürfte sich im Allgemeinen eher schwierig gestalten.

Der größte Nachteil dieses Art der Datenbankanbindung ergibt sich aber bei der unflexiblen Datenbeschaffung. Zum Zeitpunkt der Reportausführung sind keinerlei Informationen über zukünftige Anfragen aus dem Internet bekannt. Das Ergebnis der Reportausführung ist daher - im Hinblick auf den Dateninhalt - wieder eine statische HTML-Seite.

Eine prinzipielle Möglichkeit ergibt sich durch Triggern der Reportausführung vom Web-Server her. Der Web-Server muss dabei den Report-Generator aufrufen. Bei vielen Report-Generatoren können dabei Werte des gespeicherten Reports überschrieben werden (z. B. Filter der Anfrage, Dateiname der Ergebnisdatei). Hat der Report-Generator die gewünschte HTML-Seite erstellt, so kann der Web-Server diese an den Web-Client weitergeben. Diese Lösung ist allerdings sehr laufzeitintensiv und dürfte sich in der Praxis als unpraktikabel erweisen.
 
 

5.2. GDIdb

Mit Hilfe von GDIdb (Global Data Internet database von Global Data Industries, London) können Datenbanken mittels statischer WWW-Seiten publiziert werden.

Für einige Aufgaben ist es zweckmäßig, die Informationen nicht bei jeder Anforderung aus der Datenbank zu holen, sondern von Zeit zu Zeit statische Web-Seiten zu erzeugen. Ein Beispiel ist die Preisliste eines Versandhauses. Sie dürfte höchstens einmal pro Woche aktualisiert werden. So ist es sinnvoller, den Katalog statisch beim Provider vorzuhalten, als eine dynamische Anbindung zu realisieren. Nur wenn sich Einträge ändern, aktualisiert man die betreffenden Seiten zunächst lokal und überträgt sie dann zum Web-Server des Providers.
 

5.2.1. Arbeitsweise

Mit Hilfe von GDIdb kann o. g. Anforderung relativ einfach realisiert werden. Die Software ruft Daten per ODBC (s. a. 6.2.) aus einer Datenbank (z. B. Access, Excel, Oracle) ab und trägt sie in beliebig gestaltbare HTML-Seiten ein.

GDIdb ist eine Windows (95/98, NT4) Applikation, die auf einem lokalen PC ausgeführt werden kann. Die Software kommt v. a. dann zum Einsatz, wenn die Verbindung zum Internet nicht ständig vorhanden ist, sondern nur temporär erfolgt.

Das Kernstück von GDIdb ist eine eigene Skriptsprache, die gewöhnliche Skript-Syntax (ähnlich Perl) mit high-level Skript-Funktionen, die speziell für die Verbindung von Datenbanken mit dem Internet geschrieben wurden, kombiniert.

Mit einer einzigen GDIdb-Skript-Funktion können z. B. folgende Aufgaben gelöst werden:

GDIdb-Skripte bestehen aus Die eigene Skriptsprache ist, HTML-Kenntnisse vorausgesetzt, leicht zu erlernen.
Das folgende Beispielfragment
&getdata(„SELECT * FROM Artikel“)
{
<A HREF=“category?rownumber?.html">
 ?Artikelname?</A><BR>
 &categorypage
}
erzeugt innerhalb einer Übersichtsseite eine Liste von Verweisen auf Detailseiten, die die Funktion &categorypage erzeugt.

Verknüpfungen von Tabellen und Abfragen lassen sich nachbilden, sodass das Werkzeug beispielsweise Übersichtstabellen mit den zugehörenden Detailansichten publizieren kann. Obwohl das Programm auch komplexe Seitenverbünde erzeugen kann, lassen sich diese flexibel und automatisch aktualisieren. Eine relationale 1:n – Strukur wird in eine Link-page mit Hyperlinks zu den weiteren Daten konvertiert.

Der Skripteditor von GDIdb bietet einen einfachen Assistenten, der den Anwender bei dem Entwurf von einem Skriptschema für Standardaufgaben, z. B. für eine Einzeltabelle, unterstützt. Bei komplexen Aufgaben, etwa dem Veröffentlichen einer Datenbank mit vielen verknüpften Tabellen, hilft der Assistent jedoch nicht weiter.

In der Standardversion umfasst das Produkt neben dem eigentlichen Report-Werkzeug einen integrierten FTP-Client und einen Scheduler. Mit diesen Werkzeugen aktualisiert GDIdb die zu einem Projekt gehörenden Web-Seiten regelmäßig und automatisch. Eine Professional-Version (GDIdb-Pro) nimmt darüberhinaus auch Daten von Web-Formularen entgegen und fügt sie in eine Datenbank ein [Wagenknecht 1999]. GDIdb-Pro hat noch weitere zusätzliche Funktionalitäten, wie z. B. die Möglichkeit, eMail aus einem Skript heraus zu versenden, eine verbesserten Entwicklungsumgebung und erweiterte Skript-Sprache-Funktionalitäten [GDIdb].
 

5.2.2. Ausblick

Zur schnellen Anbindung von statischen Informationen, v. a. wenn keine permanente Internetanbindung vorliegt, eignet sich GDIdb sehr gut. Sollen komplexere Strukturen und nicht nur eine einzelne Tabelle veröffentlicht werden, muss der Anwender selbst Hand an die Programmierung der GDIdb-Skripte und die HTML-Formatierung legen.

Da die Software lokal auf dem PC läuft, werden weder Web-Server-Software noch CGI-Skripts benötigt. Standleitungen zu einem Provider entfallen.
 

6. Webserver mit DB-Zugriff

Bei Web-Servern mit DB-Zugriff ist die Funktionalität des Web-Servers erweitert. Der Web-Server bietet dann auch Möglichkeiten, auf Informationen aus Datenbanksystemen zuzugreifen. Dazu kann z. B. eine ODBC-Schnittstelle oder ein Datenbank-API integriert sein.
 

6.1. Prinzip

Bei der Erweiterung eines Web-Servers um Datenbank-Zugriffsfunktionalität auf der Basis einer standardisierten Schnittstelle (ODBC, JDBC) oder einer nativen Datenbank-API handelt es sich um einen Ansatz, der meist von Web-Server-Anbietern verwendet wird. Dem Server werden Funktionen hinzugefügt, die über die reine Funktion eines HTTP-Listeners hinausgehen und ihm den Zugriff nicht nur auf statische Dateien erlauben, sondern auch auf Datenbanken, die über die von ihm implementierten Schnittstellen verfügen. D. h., wenn die Anfrage eines Clients ein bestimmtes Dokument vom Server anfordert, so kann dieser dieses Dokument zur Laufzeit auf der Basis von Daten in einem Datenbanksystem generieren. [Assfalg et al. 1998]
 
 
Abb.6.1: Erweiterung eines Web-Servers um Datenbank-Zugriffsfunktionalität [Assfalg et al. 1998]
 

Eine etwas andere Darstellung dieser Art der Schnittstelle ist in [Greenspun 1998] beschrieben. Diese Darstellung geht weniger auf die technischen Details als mehr auf den Vergleich zum CGI-Skript ein. Von dort ist Abb. 6.2 und die Erklärung übernommen.
 
 

Abb. 6.2: Eine high-performance RDBM-System-backed Web-Site-Konfiguration.

Das Web-Server-Programm selbst ist der Datenbank-Client. Es öffnet einige Verbindungen zur Datenbank und hält diese offen. Wenn eine Web-Seite von einem Web-Client (z. B. Netscape Navigator) angefordert wird, sucht sich das Web-Server-Programm (z. B. AOLserver) eine freie Datenbankverbindung und übergibt diese einem von Ihnen geschriebenen Script. Ihr Script kann diese bereits offene Verbindung nutzen, um mit dem RDBM-System zu interagieren [Greenspun 1998].
 

Der direkte Zugriff des Web-Servers auf Datenbanksysteme stellt unter den aufgeführten Prinzipien als Erstes eine wirkliche dynamische Schnittstelle dar. Es ist hier jetzt möglich, dass vom Nutzer des Web-Clients Informationen angegeben werden, die die Datenselektion innerhalb des DBMS beeinflusst. Da die Datenselektion beim Aufruf einer Web-Seite jeweils neu erfolgt, ist außerdem sichergestellt, dass die Daten immer aktuell sind. Zusätzlich müssen keine Daten auf Vorat selektiert werden, die vielleicht nie abgefragt werden.

Andererseits ist diese Art der Verbindung nicht mehr so einfach zu erstellen wie die vorherigen Möglichkeiten. Vom Entwickler wird bei dieser Lösung nicht nur Know-how im Bereich Web-Seiten-Programmierung gefordert. Zusätzlich benötigt er Know-how im Bereich DBMS.

Zusammenfassend ist die Schnittstelle komplexer, bietet dafür aber auch erheblich mehr Möglichkeiten.
 

6.2. ODBC/JDBC

ODBC (Open Database Connectivity) ist eine (von Microsoft definierte) Standardschnittstelle für den Zugriff auf Datenquellen, ohne Kenntnisse der jeweiligen möglicherweise proprietären Programmierschnittstellen dieser Systeme. ODBC legt gewissermaßen eine (API)-Schicht über diese proprietären Schnittstellen und zeigt sich dem Anwendungsprogramm, welches ODBC benutzt, als ein einheitliches Interface. ODBC verwendet für den Datenbankzugriff SQL.
Abb. 6.2.1: Anbindung von Datenbanksystemen an Web-Server über proprietäre Schnittstellen
 
Abb. 6.2.2: Anbindung von Datenbanksystemen an Web-Server über ODBC

ODBC – Treiber werden von verschiedenen Herstellern (z. B. Intersolve, Microsoft) angeboten, um mit SQL-kompatiblen Datenbanken zu kommunizieren. ODBC-Treiber sind Programme, die auf dem gleichen Computer laufen, wie der angenommene Database Client, normalerweise ein PC. Wenn die Eingabemaske der Applikation des Clients Daten bekommen möchte, verbindet sich diese nicht direkt mit der Datenbank, sondern ruft stattdessen den ODBC-Treiber auf, der dann die Verbindung zur eigentlichen Datenbank herstellt. Theoretisch ist das Wechseln zwischen zwei Datenbanken so einfach wie das Installieren der neuen ODBC-Treiber. Das bedeutet, dass es möglich ist, Anwendungen zu schreiben, die auf Datenbanken zugreifen und diese Datenbanken gegen ein anderes Produkt eines anderen Herstellers auszutauschen, ohne an der Anwendung Änderungen vornehmen zu müssen. Für den Interneteinsatz bedeutet dies z. B., dass zunächst einfache Desktopsysteme eingesetzt werden können, die bei steigender Beanspruchung durch leistungfähigere Server-Datenbanken ersetzt werden können, ohne dass an den Seiten und Skripten Änderungen vorgenommen werden müssen. In diesem Sinne sorgt ODBC für System- und Geräteunabhängigkeit. Die Entwickler brauchen sich nicht mehr mit verschiedenen APIs (Application Programming Interfaces) auszukennen, sondern nur noch mit einer Datenbankschnittstelle.
JDBC (Java Database Connectivity) kann als Java-Pendant zu ODBC bezeichnet werden.
 
 

6.2.1. ODBC-Architektur

Die ODBC-Architektur umfasst folgende Module Die Treiber nehmen die SQL-Anweisungen aus Anwendungsprogrammen entgegen, leiten sie an die entsprechende Datenquelle weiter, nehmen Ergebnisse oder Fehlerzustände von den Datenquellen entgegen und geben sie an die aufrufende Anwendung zurück.

Der Treibermanager dient der betriebsspezifischen Verwaltung der auf dem System verfügbaren Treiber, da die Treiber im System installiert werden und zwar gemeinsam für alle Anwendungen. Der Treibermanager ist somit für die Verwaltung des Zugriffs von Anwendungen auf die Treiber verantwortlich.

Die Datenquelle, z. B. eine Datenbank, wird im System über ihren Namen referenziert, sodass bei Austausch der Datenquelle lediglich der neuen Datenquelle dieser Name zugeordnet werden muss.

Anwendungen setzen SQL-Anweisungen ein, um Daten aus den Datenquellen abzurufen. Sie übergeben diese Anweisungen an den jeweiligen Treiber, den sie vom Treibermanager zugeordnet bekommen und nehmen von diesem die Ergebnisse der Abfrage entgegen.
 
 

Abb. 6.2.3: ODBC-Architektur

Client Programme verfügen über zwei Optionen, SQL-Anweisungen über ODBC abzusetzen. Wenn das Client-Programm „ODBC SQL“ verwendet, wird ODBC evtl. kleine Ungereimtheiten der SQL-Syntax, welche sich in verschiedene firmenspezifische Implementierungen eingeschlichen haben, ausgleichen. Wenn das Client-Programm spezielle Eigenschaften eines bestimmten RDBM-Systemes, z. B. Oracle ConText, verwendet, kann es das ODBC auffordern, die SQL-Anweisung direkt an das DBMS-System weiterzugeben.
 

6.2.2 JDBC

JDBC als Teil der Java-API ist ein Interface für SQL-Datenbanken. JDBC ist ein fester Bestandteil der Java-Klassenbibliothek und bietet flexible Zugriffsmöglichkeiten auf nahezu alle Datenbanksysteme. Die API definiert Objektklassen, die Datenbankverbindungen, SQL-Anweisungen, etc. definieren. JDBC arbeitet ebenfalls mit einem Treibermanager, der Mehrfachzugriffe verschiedener Objekte auf unterschiedliche Datenbanken verwalten kann.
JDBC-Treiber können auf folgende Arten implementiert werden.

6.2.3. Zusammenfassung

ODBC-Aufrufe sind normalerweise langsamer als die ursprünglichen Datenbank-Anfragen. Sie sind aber sehr nützlich, wenn die Datenbankmanagement-spezifische Sprache nicht beherrscht wird, oder eine Anwendung realisiert werden soll, die auf verschiedenen Datenbanken läuft, und der Code nicht für jedes Programm abgeändert werden soll. ODBC bietet somit einen standardisierten Zugriff auf beliebige Datenquellen mittels SQL. ODBC-Einsatz gewährleistet weiterhin die Skalierbarkeit von Datenquellen.
 

6.3. Internet database Connector

6.3.1. Die Struktur des Internet Database Connectors

Bereits die erste Version des Microsoft Internet Information Server (IIS 1.0) enthielt eine Server-Erweiterung, die den Zugriff auf Datenbanken via ODBC gestattete. Diese Erweiterung wird als Internet Database Connector (IDC) bezeichnet. Im Gegensatz zu den [...] Anwendungs-Frameworks ist diese skriptbasierte Schnittstelle als sehr rudimentär zu bezeichnen, da sie keinerlei anwendungsspezifische Funktionen oder Objekte zur Verfügung stellt, also keinerlei Typ von Anwendungssystem direkt unterstützt wird. Zudem sind die Möglichkeiten der Kontrolle über die Ausgabe durch das Fehlen einer vollständigen Skriptsprache stark eingeschränkt. Der Grund, warum der Einsatz dieser Erweiterung dennoch sinnvoll sein kann, ist die Einfachheit der Benutzung, die es auch Anwendern, die über keine oder geringe Kenntnisse der Programmierung verfügen, ermöglicht, datenbankbasierte Web-Seiten zu erstellen. IDC ist quasi eine Stufe über den dialogbasierten Report-Generator-Schnittstellen wie den Internet Assistent für Microsoft Access oder den Web Assistent für den SQL-Server einzuordnen, aber bezüglich Komplexität und Mächtigkeit unterhalb den Anwendungs-Frameworks wie Active Server Page (ASP), die neben einer vollwertigen Programmiersprache meist auch noch über eine oder mehrere anwendungsspezifische Objektklassenbibliotheken verfügen. Bei diesen Anwendungs-Frameworks sind zumindest Kenntnisse der strukturierten Programmierung erforderlich, und für den Umgang mit Datenbankobjekten ist zudem ein gewisses Verständnis der Grundbegriffe der Objektorientierung erforderlich. [Assfalg et al. 1998]
 
 
Abb.6.3: Architektur des Internet Database Connectors [Assfalg et al.1998]
 

Trotz dieser ersten Einschätzung des Internet Database Connectors zwischen Report-Generator-Schnittstellen und Web-Servern mit DB-Zugriff von [Assfalg et al. 1998] soll eine Überblick über den IDC in diesem Kapitel erfolgen. Die prinzipielle Architektur ist in Abb. 6.3 dargestellt. Die Kommunikation des Web-Clients erfolgt nur direkt mit dem Web-Server. Dies ist im Fall von IDC der Internet Information Server (IIS) von Microsoft.

Der IDC verbirgt sich hinter der HTTPODBC.dll und ist eine ISAPI-dll. Die DLL selbst stützt sich auf Dateien und Treibern ab und ermöglicht den Zugriff auf Datenbanken via ODBC-Treiber. Die Dateien auf die sich der IDC abstützt, haben zwei verschiedene Typen. Es sind die IDC-Dateien und die HTX-Dateien.
 

6.3.2. Die IDC-Datei

Eine IDC-Datei ist eine sogenannte Internet Database Connector-Datei und besitzt die Endung .idc. In dieser Datei werden die eigentlichen Datenbankabfragen und die Information zum Herstellen einer Verbindung zur entsprechenden ODBC-Datenquelle definiert. Die Datei hilft also dabei, die Verbindung zur Datenbank herzustellen und eine Anfrage an das DBMS zu stellen. Typische Felder einer IDC-Datei sind in Tabelle 6.1 und 6.2 aufgezählt. Die Anfrage selbst ist eine beliebige SQL-Anweisung (Neben SELECT auch INSERT, UPDATE und DELETE). Die Anweisung kann durch Variablen parametrisiert sein. Die Werte der Variablen können vom Web-Client über Eingabeformulare übernommen sein.
 
 
Feld Beschreibung
Datasource  Der Name der ODBC-Systemdatenquelle (DSN) aus der Systemsteuerung
Template Der Name der HTX-Datei, welche als Vorlagendatei die Formatierung der von dieser Abfrage gelieferten Daten bestimmt.
SQLStatement Die eigentliche SQL-Anweisung. Die SQL-Anweisung kann mehrere Zeilen in der IDC-Datei umfassen, die mit einem Pluszeichen (+) als erstes Zeichen in einer Zeile verbunden werden. Dieser Parameter kann seit der IIS-Version 2.0 mehrfach in einer IDC-Datei vorkommen. D. h. es können mehrere Anweisungen angegeben werden.
Tabelle 6.1: Felder einer IDC-Datei [Assfalg et al. 1998]
 
Feld Beschreibung
DefaultParameters Defaultwerte für Parameter, die in der IDC-Datei verwendet werden, aber unter Umständen von einem Client nicht mit Werten belegt werden.
Expires Anzahl von Sekunden, bis eine gepufferte Ausgabeseite neu erzeugt wird. Dies kann die Performance bei häufigen identischen Anfragen verbessern, da in diesen Fällen die zwischengespeichrte Seite geliefert wird, ohne dass auf die Datenbank zugegriffen werden muss. Standardmäßig werden Ausgabeseiten vom IDC nicht zwischengespeichert.
MaxFieldSize Die maximale Puffergröße, die pro Feld reserviert wird. Zeichen, die diese Puffergröße überschreiten, werden abgeschnitten. Der Parameter gilt nur für aus der Datenbank zurückgelieferte Felder mit mehr als 8.192 Bytes. Der Standardwert beträgt 9.192 Bytes. Insbesondere beim Generieren vollständiger HTML-Textseiten aus Datenbanken kann dieser Puffer zu klein werden, was sich in unvollständigen Seiten äußert.
MaxRecords Die maximale Anzahl von Datensätzen, die der IDC für eine Abfrage liefert. Ohne diesen Parameter werden alle Datensätze, die eine Abfrage generiert, zurückgeliefert, was in manchen Fällen nicht erwünscht ist.
ODBCConnection Durch Setzen dieser Option kann die Performance des Internet Database Connectors verbessert werden, indem eine Verbindung dem Verbindungspool hinzugefügt wird und für weitere Anfragen verwendet werden kann.
Password Das Kennwort, das dem Benutzernamen zugeordnet ist und für den Zugriff auf eine Datenbank erforderlich ist. Ist kein Kennwort vergeben, kann dieses Feld weggelassen werden.
RequiredParameters Die Parameternamen, deren Übergabe durch den Client erfolgen muss. Parameternamen werden durch Komma getrennt.
Translationfile Der Pfad zu einer Übersetzungsdatei, die nichtenglische Zeichen (wie ä, ö, ü, à, ô oder é) so abbildet, dass Browser sie im HTML-Format korrekt anzeigen können. Diese Textdatei enthält für jedes Sonderzeichen eine Zuordnung im Format Wert=Zeichenfolge<CR>, wobei Wert ein internationales Zeichen ist und Zeichenfolge der HTML-Übersetzungscode, der für die korrekte Darstellung geeignet ist.
Username Ein gültiger Benutzername für die Datenbank.
Content-Type Ein MIME-Typ, der den Typ der Daten, welche zum Client gesendet werden, beschreibt. Bei HTML ist dies text/html.
Tabelle 6.2: Optionale Felder einer IDC-Datei [Assfalg et al. 1998]
 

6.3.3. Die HTX-Datei

Eine HTX-Datei ist eine sogenannte HTML-Extension-Datei und besitzt die Endung .htx. In ihr wird die Art und Weise, wie die Ergebnisse der Anfrage formatiert und aufbereitet werden, gespeichert. Sie ist eine spezielle HTML-Datei, denn sie enthält neben dem reinen HTML-Format noch spezielle Steuerkennzeichen. Diese Vorlagedatei ist entsprechend in die Formatierung für den Kopf- bzw. Fußbereich und in die Formatierung des Detailbereichs mit den Anfrageergebnissen unterteilt. Die Vorlagendatei kann außerdem <%if%>, <%else%> und <%endif%> als Kontrollstrukturen enthalten. Zusätzlich kann auf die Parameter der IDC-Datei und auf wenige allgemeine Variablen zugegriffen werden.
 

Die Verbindung von IDC-Datei und HTX-Datei erfolgt durch Angabe der zugehörigen HTX-Datei in der IDC-Datei. Der Aufruf des IDC selbst erfolgt in der URL durch Nennung der IDC-Datei. Ein Aufruf von HTTPODBC.dll ist nicht notwendig. Entsprechende Einträge in der Registry sorgen für die Weitergabe der IDC-Datei an die dll, damit diese dort verarbeitet werden kann.
 

6.3.4. Datenzugriff über ODBC

Zusätzlich muss ODBC auf dem Web-Server installiert sein. Es ist eine ODBC Version 2.5 oder höher erforderlich.

Voraussetzung für den Datenbankzugriff mit IDC ist das Vorhandensein einer Systemdatenquelle, die mit einer Datenbank oder einer anderen Datenquelle verbunden ist. Die Systemdatenquelle muss dem System bekannt gemacht werden. Man verwendet hierzu den Datenquellen-Administrator des ODBC Moduls.

Nach der Bekanntgabe der Datenquellen ist dann der Zugriff über ODBC-Treiber vom IDC aus möglich.

Somit erlaubt es der Internet database Connector über ODBC-Treiber auf beliebige Datenbanken zuzugreifen. Die Anfragen können durch Variablen flexibel gestaltet sein.
 

7. Datenbanksystem mit integriertem Webserver

Bei Datenbanksystemen mit integriertem Web-Servern ist die Funktionalität des Datenbanksystems erweitert. Das Datenbanksystem beinhaltet dann auch alle Funktionen eines Web-Servers.
 

7.1. Prinzip

Bei diesem Ansatz, der in der Regel von Datenbankherstellern angeboten wird, werden bestehende Datenbanksysteme um die Funktionalität eines HTTP-Listeners erweitert. D. h. ein Datenbanksystem übernimmt quasi die Funktion eines Web-Servers [Assfalg et al. 1998].

Der Web-Server ist damit ein Bestandteil des Datenbanksystems. Abb. 7.1 verdeutlicht diesen Zusammenhang. Damit stellen sich Datenbanksystem und Web-Server als Einheit dar. Schnittstellen sind nicht notwendig. Die Handhabung sollte deshalb im Allgemeinen erheblich einfacher sein. Durch den Wegfall der Schnittstellen sollte auch eine potentielle Fehlerquelle wegfallen. Der Ansatz hat also große Vorteile. Andererseits dürften die Anforderungen an die Kenntnisse des Entwicklers höher sein. Er muss sich bei diesem Prinzip komplett im Umfeld des Datenbanksystems auskennen.
 
 

Abb. 7.1: Erweiterung eines Datenbanksystems um einen HTTP-Listener [Assfalg et al. 1998]
 

Bei dem vorliegenden Prinzip erfolgt die Erstellung der Web-Seiten im Allgemeinen dynamisch zum Zeitpunkt der Anfrage durch den Web-Client. Die Systeme arbeiten meist report-basiert oder über Anfrageschnittstellen mit HTML-Formularen. Für die Steuerung der Ausgabe stehen im Allgemeinen HTML-spezifische Funktionen zur Verfügung. Zusätzlich steht der Sprachumfang des zugrundeliegenden Datenbanksystems (also z. B. der SQL-Dialekt) zur Verfügung.
 
 

7.2. Informix Universal Server mit Web DataBlade

Der INFORMIX Universal Server ist das erste objektrelationale Datenbanksystem [Petkovic 1997].
Die Architektur des Systems erlaubt die Integration sogenannter DataBlades. Dies sind Software-Module, die die Leistungsfähigkeit des Datenbank-Servers um ein bestimmtes Anwendungsgebiet unterstützen. Das können z. B. Volltexterweiterungen sein (Text DataBlades) oder Erweiterungen für das Arbeiten im WWW, Web DataBlades, die im Folgenden betrachtet werden sollen. Mit dem Modul des Web DataBlades enthält der Universal Server innerhalb des Datenbanksystems die Möglichkeit, HTML-Seiten dynamisch zu erstellen. Er ist somit ein Beispiel für ein Datenbanksystem mit integriertem Web-Server.
 

INFORMIX Web DataBlade bietet (unter anderem) beide [..] Möglichkeiten:

Die HTML-Seiten heißen bei Web DataBlade Application Pages (Applikationsseiten) [Petkovic 1997]. Der Universal Server speichert alle Teilkomponenten aller Web-Pages wie Texte, Bilder, etc. sowie die Application Pages (AppPages). Jede AppPage enthält Anweisungen für den Aufbau seiner Web-Page wie z. B. einen SQL-Befehl, um ein bestimmtes Bild aus einer Datenbank zu holen und die Anweisung, wo das Bild auf der Web-Page positioniert werden soll.

Die DataBlades werden erst bei der Verwendung entsprechender Funktionen dynamisch in die Datenbank geladen. Dazu muss der Datenbankadministrator mittels BladeManager die gewünschten DataBlades in der jeweiligen Datenbank registrieren.
Jedes DataBlade beinhaltet einen SQL-Wrapper, der für die Kommunikation der DataBlades mit dem Datenbank-Server verantwortlich ist [Heede 1998].

Das Web DataBlade-Modul enthält drei Hauptkomponenten:

Im Folgenden sollen die einzelnen Komponenten des Web DataBlade-Moduls kurz mit ihren Funktionen genannt werden.

Der Webdriver bildet das Ergebnis einer SQL-Anweisung und liefert das Ergebnis an den Webserver. INFORMIX Web DataBlade bietet zwei Arten von Webdriver:

WebExplode bildet dynamisch die HTML-Seite aufgrund der Daten, die in der abgefragten Datenbank gespeichert sind. Diese Funktion untersucht HTML-Seiten nach speziellen tags und führt diese aus. Zusätzlich dazu formatiert WebExplode das gelieferte Ergebnis und schickt es an den Webdriver [Petkovic 1997].
 

Mit Hilfe der tags können spezielle Funktionen durchgeführt werden. Dazu ist auf die Attribute der tags zuzugreifen.

Folgende tags stehen im Web DataBlade-Modul zur Verfügung:

Wie die einzelnen Komponenten beim Aufruf einer Web-Seite arbeiten, beschreibt [Petkovic 1997]. Der Ablauf ist in Abb. 7.2 noch einmal verdeutlicht.

Damit erfolgt der Aufruf an einen Webserver und die Rückgabe einer HTML-Seite an den Webbrowser folgendermaßen. Der Webbrowser schickt die entsprechende http-Adresse an einen Webserver, der gleich danach den Webdriver aufruft. Aufgrund der existierenden Konfiguration erstellt der Webdriver die SQL-Anweisung und ruft die WebExplode-Komponente auf. WebExplode führt die in der Applikationsseite enthaltene SQL-Anweisung aus, formatiert das Ergebnis und liefert es an den Webdriver als eine HTML-Seite weiter. Diese Seite wird schließlich vom Webdriver an den Webserver und danach weiter an den Webbrowser geschickt [Petkovic 1997].
 
 

Abb. 7.2: Komponenten des Web DataBlade-Moduls [Petkovic 1997]
 

Damit stellt Web DataBlade innerhalb des INFORMIX Universal Servers die Funktionalitäten zur Erstellung von Web-Seiten zur Verfügung. Das Prinzip hört sich prinzipiell gut an. Laut [Greenspun 1998] scheint es aber noch erhebliche Defizite in Hinblick auf die Handhabbarkeit zu geben:

Das Web DataBlade-Programm ist das am schlechtesten entwickelte, am schlechtesten laufende Programm von Web/RDBMS Integration Software, das ich je verwendet habe. [...] Es hat ernsthafte Schwierigkeiten in den folgenden Punkten:

Informix Universal Server verspricht ein sehr nettes RDBMS zu sein, aber sagen Sie nein zu dieser Art, Ihre Web-Site eine RDBMS zu binden [Greenspun 1998].
 

Eine wirkliche Einschätzung des Web DataBlade-Moduls ist aufgrund mangelnder eigener Erfahrung nicht möglich.
 
 

8. Web-Server mit Komponentenschnittstelle

In der modernen Anwendungsentwicklung besteht der Trend hin zur Komponententechnologie. Diesen Ansatz greift das Prinzip der Web-Server mit Komponentenschnittstelle auf. Der Web-Server nutzt dabei die Komponentenbibliothek des Datenbanksystems und stellt hierfür eine eigene Komponenten-Schnittstelle zur Verfügung.
 

8.1. Prinzip

Dies ist ein sehr moderner Ansatz, welcher der Tatsache Rechnung trägt, dass Anwendungsentwicklung heute in hohem Maße komponentenorientiert ist und die meisten Systeme Schnittstellen für Komponenten anbieten. Der entscheidende Vorteil derartiger Systeme ist die hohe Modularität und die Möglichkeit zur massiven Wiederverwendung vorhandener Problemlösungen in Form von Komponenten mit standardisierten Schnittstellen. Dieser Ansatz vereinigt den einfachen Umgang mit standardisierten Komponenten mit der Möglichkeit, beliebig komplexe Anwendungen zu entwickeln durch die Verwendung entsprechend leistungsfähiger Komponenten. Da diese Komponenten in der Regel benutzt werden können, ohne Details ihrer Implementierung zu kennen, können auch weniger geübte Entwickler diese in ihren Anwendungen verwenden. Gleichzeitig stehen mit der Komponententechnologie aber alle Möglichkeiten der modernen Softwareentwicklung zur Verfügung, sodass der Einsatzbereich dieser Systeme unbegrenzt erscheint. Zudem ist der Übergang von einfachen Erweiterungen von Seiten durch einen HTML-Autor hin zu komplexen Anwendungen auf der Basis komponentenorientierter Internet-Technologie fließend [Assfalg et al. 1998].

Möchte man in eine Internet-Anwendung Daten aus einem bestehenden Datenbankmanagementsystem (DBMS) integrieren, welches eine Komponentenschnittstelle anbietet, so ist das Prinzip ein sehr Gutes. Es bietet von den genannten Prinzipien als Einzigste die Möglichkeit, nicht nur auf die Daten des DBMS zuzugreifen. Hier ist es zudem möglich, alle bereits vorhandenen Komponenten mitzuverwenden. Gerade, wenn bereits ein DBMS mit vielen Datenbanken und Anwendungen existiert, kann hier unter Umständen auf eine Vielzahl bereits vorhandener Funktionen zurückgegriffen werden. Dies kann den Entwicklungsaufwand für die Internet-Anwendung drastisch reduzieren. Zudem ist durch die Kapselung zwischen Datenzugriff und Internet-Anwendung auch eine bessere Aufteilung der Arbeit unter Entwicklern möglich. Es ist dann möglich, die Internet-Anwendung von Entwicklern ohne genaue Kenntnis des Datenbanksystems schreiben zu lassen. Die Komponenten für den DBMS-Zugriff hingegen können von den Anwendungsentwicklern im DBMS-Umfeld geschrieben werden.
 
 

Abb. 8.1: Erweiterung eines Web-Servers um eine Komponentenschnittstelle und Verwendung von Anwendungs-Frameworks mit komponentenbasierten Datenbankschnittstellen [Assfalg et al. 1998]
 

8.2. Internet Information Server mit ASP

8.2.1. ASP-Architektur

Zur kurzen Einführung in ASP zuerst einige allgemeine Bemerkungen:

Mit dem Internet Information Server steht nicht nur ein leistungsfähiger Webserver, sondern zugleich auch eine interessante Plattform für die Programmierung interaktiver, datenbankgestützter Webseiten zur Verfügung. Die verwendete Technologie bietet Microsoft unter dem Namen Active Server Pages (ASP) an [Krause 1999].

ASP stellt zugleich eine Skript-Umgebung zur Verfügung, die auf dem Server ausgeführt wird. ASP ist damit vom Web-Client unabhängig. Außerdem bietet ASP die Möglichkeit der Anwendungsentwicklung.

[Assfalg et al. 1998] charakterisiert ASP in Kürze:

ASP ist eine Erweiterung des Microsoft Internet Information Servers 2.0 (IIS 2.0), der Bestandteil von Windows NT Server 4.0 ist. Diese Erweiterung besteht aus einer Laufzeitumgebung, die als Server-Erweiterung implementiert und für die Verarbeitung von ASP-Skripten zur Aufrufzeit einer Seite zuständig ist, und aus ActiveX-Komponenten, in denen das eigentliche Framework implementiert ist. IIS 2.0 mit ASP wird auch als Microsoft Internet Information Server Version 3.0 (IIS 3.0) bezeichnet [Assfalg et al. 1998].
 

Zur Nutzung von Datenbanken mit ASP schreibt [Krause 1999]:

Aufgrund der engen Verflechtung mit dem IIS und den sehr leistungsfähigen Objekten in Bezug auf die Datenbanknutzung ist ASP optimal für die Nutzung mit dem SQL Server 7 geeignet. ASP bietet eine Skriptumgebung, bei der Befehle in HTML-Seiten eingebunden werden. Die ASP-Engine wertet die Seiten aus und ersetzt die Skriptbefehle durch die erzeugten Ausgaben - beispielsweise Datenbankabfragen. Die fertige Seite - pures HTML - wird dann zum Webserver gesendet, der den Transport per HTTP zum Browser übernimmt.
 

Zum Scripting mit ASP ist in Kürze folgendes zu bemerken:

Mit ASP werden normale HTML-Seiten mit den Grundkonstrukten der strukturierten Programmierung wie bedingte Verzweigung (if-then-else), Schleifen (for, while, ...) und Enumeratoren (for each, next, ...) angereichert. Auch die Verwendung von Variablen und Prozeduren ist möglich [Assfalg et al. 1998].

Mit ASP ausgeliefert werden die Skriptsprachen VBScript oder JScript. Andere Skriptsprachen können ebenfalls genutzt werden.

Nähere Informationen zum generellen Thema ASP und Skriptnutzung sind in der vorliegenden Arbeit nicht enthalten.
 

Die Verarbeitung von ASP-Dateien erfolgt über die ASP-Engine:

Auch auf die Funktionsweise der ASP-Engine soll hier nicht näher eingegangen werden. Es ist lediglich die prinzipielle Vorgehensweise kurz zusammengefasst:

Wenn der Browser die Seite angefordert hat, liest die ASP-Engine die Seite von oben nach unten durch, führt die gefundenen Befehle aus und erstellt daraus eine HTML-Seite. Die fertige HTML-Seite wird dann an den Browser gesendet. Da der Browser eine Datei mit der Endung .ASP erwartet, bleibt der Dateiname dabei unverändert, die Skript-Befehle sind allerdings nicht mehr sichtbar - nur das Ergebnis, die fertige HTML-Seite [Krause 1999].
 

In diesem Zusammenhang ist die Datei global.asa sehr wichtig:

Normalerweise sind Active Server Pages zu einer Anwendung zusammengefasst [...]. Ein wichtiger Bestandteil einer ASP-Anwendung ist eine Datei namens global.asa, die im selben Ordner wie die .ASP-Dateien gespeichert ist, welche die Benutzerschnittstelle der Anwendung ausmachen. Diese Datei enthält wichtige, anwendungsweit geltende Einstellungen und Code-Teile [Gunderloy et al. 1999].

Das Programmiermodell von ASP ist ereignisgesteuert. In der Datei global.asa findet sich unter anderem Code, der bei bestimmten Ereignissen durchzuführen ist.
 

Nach diesem ersten allgemeinen Überblick zu ASP folgen Ausführungen zur Datenbankanbindung. Bevor auf die Datenbankanbindung mit Komponenten-Schnittstelle eingegangen wird, soll zuerst noch die allgemeine Schnittstelle zu Datenbanken über Datenbankobjekte vorausgehen. Es folgt deshalb eine Beschreibung der Database-Access-Komponente von ASP, welche die Verbindung zu Datenbanksystemen herstellen kann. Anschließend soll dann auf die Zugriffsmöglichkeit auf Datenbanken von ASP aus über die Komponententechnik eingegangen werden.
 

8.2.2. Datenbankanbindung mit Database-Access-Komponente

Einen ersten Überblick über die Möglichkeiten der Database-Access-Komponente bietet [Krause 1999]:

Um in ASP eine leistungsstarke Datenbankumgebung zur Verfügung zu stellen, liefert Microsoft die ActiveX-Data-Objekte (ADO) mit aus. Diese ermöglichen den Zugriff auf ODBC-Datenbanken direkt aus VBScript und JScript heraus. Insgesamt gibt es sieben Objekte, die die Datenbankanbindung leicht und einfach unterstützen. Für die Arbeit mit dem SQL Server 7 ist ADO das maßgebliche Werkzeug. Hier werden beide Welten zusammengeführt.

Zu Flexibilität und Wichtigkeit der Database-Access-Komponente schreibt [Assfalg et al. 1998]:

Die Database-Access-Komponente verwendet für den Zugriff auf Datenbanken oder allgemeiner Datenquellen die ActiveX Data Objects (ADO). Datenquelle ist eigentlich die richtige Bezeichnung, da grundsätzlich nicht nur Datenbanken mit dieser Komponente genutzt werden können, sondern auch andere Datenlieferanten wie Tabellenkalkulation oder strukturierte Textdateien.

Dies ist die wichtigste und mächtigste Komponente, die ASP zur Verfügung stellt. Datenbanken bzw. Datenbankanbindung ist heute die wichtigste Eigenschaft eines Frameworks für die Anwendungsentwicklung auf dem Internet.

Die oben genannten sieben Objekte der Database-Access-Komponente gehören alle zur Klasse ActiveX-Data-Object-Database (ADODB). Sie sind in Tabelle 8.1 aufgeführt und kurz erläutert.

Allerdings können nur die drei Hauptobjekte CONNECTION, RECORDSET und COMMAND direkt in ASP-Seiten instanziiert werden. Alle anderen Objekte sind den drei Hauptobjekten zugeordnet und werden bei Bedarf automatisch erzeugt.
 

Objekt Beschreibung Objekt
CONNECTION Stellt die Verbindung mit dem SQL-Server bzw. mit der Datenbank her und repräsentiert diese - geöffnete - Verbindung im folgenden Ablauf.
RECORDSET Stellt die Datenschnittstelle zu den Tabellen der Datenbank her. Ein Objekt repräsentiert einen einzelnen Datensatz oder das Ergebnis einer Abfrage. Bei einer Gruppe von Datensätzen zeigt der Bezug dabei immer besonders auf einen einzelnen Datensatz, der den aktuellen Datensatz repräsentiert. Zur Unterstützung existiert innerhalb des Objektes ein Cursormanagement.
FIELD Erlaubt den Zugriff auf ein einzelnes Feld. Es bezieht sich immer auf den aktuellen Datensatz im RECORDSET. Mit Hilfe des Objektes ist es möglich, einzelne Felder des aktuellen Datensatzes zu lesen oder zu ändern.
COMMAND Sendet einzelne Kommandos an den SQL-Server oder startet dort gespeicherte Prozeduren. Die Kommandos können allgemeingültige SQL-Anweisungen sein. Sie können auch sehr spezifisch zur aktuellen Datenquelle sein, wie das z. B. bei gespeicherten Prozeduren zur Datenquelle ist.
PARAMETER Erlaubt den Zugriff auf die Rückgabewerte oder Parameter einer gespeicherten Prozedur. Es ist immer mit einem COMMAND-Objekt verbunden. Es ermöglicht auch den Zugriff auf die Parameter einer Parameterabfrage.
PROPERTY Ermöglicht den Zugriff auf Eigenschaften der SQL-Datenbank. Damit können z. B. zusätzliche Funktionalitäten, welche die Datenquelle bietet, ermittelt werden.
ERROR Ein Objekt zur Behandlung von Fehlermeldungen. Es enthält Einzelheiten zu Fehlern beim Datenzugriff.
Tabelle 8.1 Übersicht über die Objekte zum Datenbankzugriff mit ASP
 

8.2.3. Datenbankanbindung mit Komponenten-Schnittstelle

Die bisherigen Ausführungen beziehen sich noch nicht auf die Anbindung über Komponenten-Schnittstelle. ASP bietet diese Möglichkeiten, neben den bereits Erwähnten. Während die bisher erwähnte Möglichkeit über allgemeine Objekte weitgehend unabhängig von der konkreten Datenquelle sind, muss bei der Verwendung der Komponententechnologie die Datenbasis bereits feststehen. Außerdem muss die Datenquelle eine entsprechende Komponenten-Schnittstelle anbieten. Dafür kann unter Umständen ein Vielfaches der vom Datenbanksystem bereitgestellten Funktionalität genutzt werden.
 
 
Abb. 8.2: Die SQL-DMO-Objekthierarchie [Assfalg et al. 1998]
 

Zur Anbindung von ASP an des SQL-Server schreibt [Assfalg et al. 1998]:

SQL-Server bietet mit Distributed Management Objects (SQL-DMO) eine auf dem OLE/COM-Objektmodell basierende Schnittstelle für einen großen Teil seiner Funktionalität an, die von einem ActiveX-basierten Framework wie ASP ohne weiteres genutzt werden kann!

Grundsätzlich bieten die meisten Datenbanksysteme embedded SQL-Schnittstellen an, meist in der Form von C-APIs, die in der Regel einfach durch selbstentwickelte ASP-Komponenten gekapselt werden könnten, sodass sie in einer Umgebung wie ASP genutzt werden können. SQL Server bringt eine derartige Komponentenbibliothek bereits im Lieferumfang mit (neben der üblichen Schnittstelle DB-Library, die in Visual C++ und Visual Basic verwendet werden kann), sodass man sich diese Arbeit sparen kann, und die Objekte des SQL Servers sofort ohne weiteren Programmieraufwand in ASP einsetzen kann. Der Preis für die Verwendung dieser mächtigen Objektbibliothek ist der Verlust der Kompatibilität mit anderen Datenbanksystemen [Assfalg et al. 1998].

Die Nutzung der Objekte aus der Komponenten-Schnittstelle erfolgt prinzipiell genauso. Deshalb wird auf die Einzelheiten an dieser Stelle nicht mehr eingegangen. Um aber - für diesen konkreten Fall - einen Vergleich der Komplexität zu geben, ist in Abb. 8.2 die SQL-DMO-Objekthierarchie dargestellt. Man sieht hier noch einmal, dass über die Komponenten-Schnittstelle ein erheblich größeres Leistungsspektrum angeboten wird. Wobei das hier gezeigte Leistungsspektrum nur die vom Hersteller ausgelieferten Komponenten beinhaltet. Zusatzentwicklungen im DBMS, die neue Komponenten zur Verfügung stellen, können selbstverständlich ebenfalls genutzt werden.

Die Nutzung der Komponenten-Schnittstelle bietet sich deshalb immer dann an, wenn das Datenbanksystem, das die Datenquelle bildet, bereits feststeht und es selbst eine solche Komponentenschnittstelle bietet. Kann allerdings die Datenquelle für die Webanwendung wechseln, so ist bei dieser Art der Anbindung Vorsicht geboten. Durch ein Wechsel des Datenbanksystems der Datenquelle kann die Möglichkeit der Komponenten-Schnittstelle unter Umständen komplett entfallen.
 
 
 

8.3. Oracle Application Server

Der Oracle Application Server (OAS) der Oracle Corporation ist aktuell in der Version 4.0 erhältlich. OAS unterstützt mehrere Applikations-Paradigmen (Web HTTP, CORBA, Enterprise Java Beans) sowie Programmiersprachen (Java, Perl, C, COBOL, etc.) und bietet die Zusammenfassung mehrerer Middlewareprodukte (s. a. Kap. 10.) in einem einzigen, integrierten Programmpaket.
 
 
Abb. 8.3.1: Middleware-Funktionalität, die im integrierten Application-Server von Oracle vereinigt ist
 

8.3.1. OAS Architekturüberblick

Die interne Architektur des OAS beinhaltet folgende Funktionalitäten. Diese Komponenten können über mehrere Plattformen verteilt werden, sodass Flexibilität, Skalierbarkeit und Zuverlässigkeit gewährleistet werden können.
 
 
Abb. 8.3.2: Oracle Application Server Architektur
 

HTTP Listener
Alle Anfragen nach statischen Seiten oder CGI-Skripten werden direkt vom Listener bearbeitet und nicht zum Application Server weitergereicht. Es können mehrere heterogene Listener (Netscape Listener, Microsoft Listener, Oracle Listener) in beliebigen Konfigurationen verwendet werden.

Application Server
Der Application Server verwaltet automatisch die Ressourcen, wenn Anfragen auf die als Cartridges installierten Anwendungen auf dem Server eingehen. Er bietet einen allgemeinen Satz von Funktionalitäten für dynamische Lastverteilung, automatisches Wiederherstellen von Prozessen im Fehlerfall, Sicherheitsdiensten, Directory- und Transaktionsservices. Ist eine Oracle-Datenbank im Einsatz, basiert die Kommunikation zwischen Application Server und Datenbank auf SQL*Net.

Application – Cartridges
Cartridges sind Objekte oder Komponenten, die über den OAS zum Einsatz kommen. Jede Applikations- bzw. Anwendungs-Cartridge läuft in einer eigenen, isolierten Prozessumgebung.
 

OAS kann für drei hauptsächliche Anwendungstypen eingesetzt werden: Web-basierte Anwendungen, Komponenten-basierte Anwendungen und Integration unternehmensweiter Anwendungen. Alle Anwendungstypen können auf einer Instanz des OAS koexistieren.
 

8.3.2. Client - Server Interaktion

Folgende drei grundsätzliche Wege zur Anwendungsgestaltung werden unterstützt. HTTP: Anfrage-Antwort-Modell

Clients schicken hierbei HTTP Anfragen zu HTTP Listenern. Anfragen für CGI Skripts und statische Seiten werden direkt vom HTTP Listener bearbeitet und nicht vom OAS. Alle anderen Anfragen werden an den OAS weitergeleitet, der dann diese Anfrage an die entsprechende Anwendungs-Cartridge weiterleitet. Anfragen an Anwendungen werden von einer verfügbaren Instanz dieser Anwendungs-Cartridge bearbeitet und das Ergebnis an den Client-Browser zurückgeschickt. Nachdem das Ergebnis zurückgesandt wurde, wird die Verbindung zwischen dem Browser und dem Webserver abgebrochen, sodass die Kontextinformationen zur Anfrage verloren gehen. Dies ist also eine statuslose Anfrage.
 

IIOP: Anfrage-Antwort-Modell

JCORBA Komponenten, die in Java geschrieben wurden, die auf der darunterliegenden OAS CORBA Infrastruktur eingesetzt werden, sind für Clients und andere JCORBA Objekte über IIOP zugreifbar. IIOP Anfragen können von Browsern stammen, die einen ORB enthalten (z. B. Netscape Communicator).

Besitzt ein Client keinen integrierten ORB, kann eine IIOP Verbindung trotzdem aufgebaut werden. Die ursprüngliche HTTP Anfrage des Client initiiert das Herunterladen eines Java Applets in den Client-Browser. Dieses Applet öffnet dann die IIOP Verbindung zum OAS, der dann seinerseits diese Anfrage an das entsprechende JCORBA Objekt weiterleitet. Die Verbindung bleibt solange bestehen, bis die Ergebnisse an den Client zurückgeschickt worden sind, sie sind somit nicht statuslos. V. a. für E-Commerce-Anwendungen und geschäftskritische Transaktionen ist dies wichtig.
 

HTTP: Sitzungs-Modell

Web-Anwendungen können einen Session-Mechanismus des OAS verwenden, um eine anhaltende Assoziation zwischen Browser und einer bestimmten Instanz einer Applikations-Cartridge zu unterstützen. Dies ist besonders dann wichtig, wenn eine logische Interaktion zwischen einem Endanwender und einer Applikation aus mehreren, miteinander verknüpften HTTP Anfragen und Anworten besteht. In diesem Fall müssen Kontextinformationen erhalten bleiben. Bei alternativen Lösungen werden Statusinformationen in Form von Cookies vom Client über das Netzwerk übertragen, was letztendlich die Netzlast erhöht.

Die OAS-Lösung besteht darin, dass die Kontextinformationen auf dem Server gespeichert werden. Da das OAS-System auch verteilt angelegt werden kann, werden die erste und alle weiteren Anfragen vom selben Browser von derselben Cartridge Instanz bearbeitet. Das bedeutet, dass der Kontext von der Cartridge Instanz vorgehalten wird und somit der Anwendung bei jeder Clientanfrage lokal zur Verfügung steht. In diesem Modell bleibt die Sitzung bestehen, bis die Anwendung ein festgesetztes Zeitlimit überschreitet, oder aber der Client oder der Server die Verbindung proaktiv abbrechen.
 

HTTP und IIOP: Transaktions-Modell

Eine Transaktion ist einer Sitzung sehr ähnlich, da sie normalerweise aus mehreren HTTP Anfragen besteht. Im Gegensatz zu Sitzungen werden Transaktionen jedoch dazu verwendet, dass Interaktionen, die auf Basis geschäftskritischer Informationen durchgeführt werden, entweder vollständig oder aber gar nicht durchgeführt werden (commit, rollback).

Der OAS unterstützt sowohl deklarative als auch programmatische Transaktionstypen. Deklarative Transaktionen werden während der Laufzeit mittels Konfigurationsoptionen für Cartridge-Umgebungen definiert. Sie setzen keinerlei explizite Programmierung voraus, sie sind somit einfach und leicht zu benutzen. Programmatische Transaktionen werden explizit in einer Applikation über Programmierschnittstellen für Transaktionen angesprochen. Diese Schnittstellen enthalten Schlüsselwörter, die beschreiben, wo eine Transaktion beginnt und wo sie endet, wann sie festgeschrieben, bzw. zurückgefahren werden soll [Oracle 1998].
 

8.3.3. Zusammenfassung

Der OAS bündelt eine Reihe von Middleware-Funktionalitäten in einem integrierten Produkt. Obwohl der OAS auch beliebige, z. B. in nicht-Oracle Datenhaltungssystemen gespeicherte, Daten verarbeiten kann, kommen seine Stärken v. a. dann zum Tragen, wenn Oracle-Datenbanken die Basis darstellen. Dann kann nämlich auf eine integrierte Verwaltungsumgebung zurückgegriffen werden, von der sowohl die Administration des Application-Servers, die Administration von Anwendungen und von der Datenbank vorgenommen werden kann.
 

9. Standardgateways

Mit Hilfe von Standardgateways werden Schnittstellen für alle möglichen Übergänge zwischen den einzelnen Internet-Diensten bereitgestellt.

9.1. Prinzip

Traditionell gibt es im Bereich des WWW Gateway-Standards, welche für alle Arten von Übergängen zwischen den einzelnen Diensten des Internets genutzt werden können. Insbesondere wurden und werden diese Gateways auch für die Anbindung von Datenbanken eingesetzt. Dieser Art der Anbindung ist jedoch i. d. R. mit hohem Codierungsaufwand verbunden. Die so entstandenen Lösungen sind häufig nur mit hohem Aufwand an sich ändernde Systemparameter wie ein anderes Datenbanksystem anpassbar. Es entsteht immer eine Teilung der Anwendung in statische Anwendungsteile in Form von HTML-Seiten und dynamische Anteile, die durch Gateways generiert werden. Ein fließender Übergang oder eine Mischform ist meist nicht möglich. Diese Schnittstelle verliert somit zunehmend an Bedeutung.

Standard-Gateways sind z. B. CGI, FastCGI oder Web-Server-seitige APIs.
 
 

Abb. 9.1: Verwendung standardisierter Gateways wie CGI, FastCGI, oder einer proprietären Server-API auf der Seite des Servers in Verbindung mit Standard-APIs auf der Seite des Datenbanksystems (z. B. C in Verbindung mit embedded SQL)

9.2. CGI und FastCGI

CGI steht für Common Gateway Interface und besteht aus Standards für die Kommunikation zwischen Web-Server und serverseitgen Anwendungen. Diese Standards stellen die Schnittstelle dar, über die die Daten zwischen dem Web-Server und der CGI-Anwendung ausgetauscht werden können.

Grundsätzlich definiert die CGI-Spezifikation, wie Web-Server CGI-Anwendungen Informationen zur Verfügung stellen und wie CGI-Anwendungen Daten an den Web-Server zurückgeben. Bei „CGI-Programmierung“ handelt es sich also um eine Methodologie für die Programmierung und nicht um eine spezielle Sprache.

Fast jede Programmier- bzw. Skript-Sprache, die von der Web-Server-Maschine unterstützt wird, kann für die CGI-Programmierung gewählt werden. Die gebräuchlisten Sprachen sind Java, Perl, C, C++, etc. Das CGI kommuniziert mit dem Web-Server über Aufrufparameter und v. a. über Umgebungsvariablen, die vom Betriebssystem unterstützt werden und auf die sowohl das CGI-Programm als auch der Web-Server zugreifen können.

Erfolgt eine Client-seitige Anfrage aus dem Internet, initialisiert das CGI zunächst die Umgebungsvariablen, die zur Informationsübertragung zwischen Server und CGI-Programm dienen. Sie enthalten alle für die Dokumentenadressierung notwendigen Daten. Nach der Initialisierung der Variablen wird das CGI-Anwendungsprogramm gestartet, das die Inhalte dieser Variablen auswertet, da sie in den Prozess des Generierens des HTML-Dokuments eingehen.

Nachfolgend ein Auszug der Variablenbelegung, die durch den Aufruf
    http://www.inf-wiss.uni-konstanz.de/khs/cgi-bin/f/path?Wort=Hallo
vom Server an das über CGI gestartete Programm übergeben werden.
 
 
Name CGI Variable Wert CGI Variable Bedeutung
SERVER_SOFTWARE CERN/3.0 Produktbezeichnung für die Server Software
SERVER_NAME www.inf-wiss.uni-konstanz.de DNS-Alias-Adresse des Servers
SERVER_PORT 80 DNS-Portnummer
GATEWAY-INTERFACE CGI/1.1 Versionskennung des verwendeten CGIs
SERVER_PROTOKOLL HTTP/1.0 Versionskennung des vom Server unterstützten Protokolls
REQUEST_METHOD GET Anfragemodus des Clients
PATH_INFO /path Pfaderweiterung für die Anfrage
QUERY_STRING  Wort=Hallo Aufrufparameter des CGI-Scripts
SCRIPT_NAME khs/cgi-bin/f  Pfad des ausgeführten CGI-Programms
Die komplette Variablenbelegung findet sich in [Assfalg et al. 1998], Kap. 3.2.

CGI ist der traditionelle Weg, um von einer Webseite auf eine Datenbank zuzugreifen. Für die Realisierung benötigt man die Kenntnis von HTML, einer Progammiersprache für das CGI-Skript und der Datenbankzugriffs-Sprache.

Obwohl CGI-Anwendungen einfach zu realisieren sind, besteht ihr Nachteil darin, dass für jede einzelne Anfrage aus dem Internet ein Programm initialisiert werden muss, also im Sinne des Betriebssystems ein eigenständiger Prozess realisiert werden muss. Daraus ergeben sich Performance-Probleme, ein CGI-Zugriff kann also relativ langsam sein.

Bei der Datenbankanbindung gibt es noch weitere Probleme mit CGI. Zum CGI-Anschluss der Datenbank ist i. d. R. die Initialisierung einer Datenbanksitzung (login) notwendig, bevor Abfragen durchgeführt werden können. Die Implementierung einer Interprozesskommunikation zwischen einem Programm, welches eine Datenbanksitzung unterhält und dem anfragenden CGI-Programm ist eine Möglichkeit, diesem Problem aus dem Weg zu gehen. Das CGI-Programm muss also nach dessen Start nur dafür sorgen, dass die Verbindung zu dem Programm aufgenommen wird, welches die Datenbanksitzung unterhält. Unter UNIX bieten sich zur Realisierung von Anforderungen dieser Art Shared-memory-Bereiche, Message-queues oder auch Fifo-Dateien (Pipes) an. Daneben werden auch Produkte angeboten, die nach dem CORBA-Standard funktionieren und plattformübergreifende Prozesskommunikation zwischen Datenbank bzw. dem Programm, welches eine Datenbanksitzung unterhält, und dem CGI-Programm auf Basis von Kommunikation zwischen Objekten möglich machen.

Die Idee, Programme zu unterhalten, die ständig laufen, wie es zum Unterhalt einer Datenbanksitzung notwendig ist, und diese für den Web-Server erreichbar zu machen, hat zur Entwicklung von FastCGI geführt. FastCGI ist ein Paket, das aus einer Server-Erweiterung zur Kommunikation und eine Funktionsbibliothek zum Erstellen von FastCGI-Anwendungen besteht. Sind die FastCGI-Programme in Perl geschrieben, kann ein ganzer Satz von Perl-Funktionen eingebunden werden.

Die wichtigste Eigenschaft von FastCGI-Programmen ist, dass diese nicht beenden, nachdem ein Internet-Zugriff abgearbeitet wurde. Vielmehr wird die Verbindung zum Server über ein spezielles Protokoll aufrechterhalten. Das FastCGI-Programm kann so praktisch endlos Anforderungen aus dem Internet bearbeiten. Damit können die Programme auch eine modale Kommunikation unterstützen, indem die Zugriffe im Programm selbst in Variablen abgelegt werden können. Auf diese Art stehen Möglichkeiten einer effizienten und einfachen Dialogverwaltung zur Verfügung. Ein FastCGI-Programm kann nach seiner Initialisierung, die mit dem Starten des Web-Servers erfolgt, eine Datenbanksitzung eröffnen. Diese bleibt im weiteren Verlauf bestehen, um Datenbankanfragen aus dem Internet zu bedienen. Dadurch entfällt die Zeit, die bei CGI-Programmen benötigt wird, um bei jeder Anfrage aufs Neue ein Programm und eine Datenbanksitzung zu initialisieren.

FastCGI hat jedoch auch Nachteile. Es ist leider nicht möglich, mehrere identische FastCGI-Programme parallel laufen zu lassen und zu erwarten, dass der Web-Server für eine Lastverteilung sorgt, um Anfragen aus dem Internet gleichmäßig auf die gestarteten FastCGI-Programme zu verteilen. Vielmehr kann ein einzelnes FastCGI-Programm immer nur eine Anfrage zu einer Zeit bearbeiten. Kommen mehrere Anfragen gleichzeitig, werden diese nacheinander abgearbeitet. Werden Suchoperationen auf Datenbanken realisiert, können bei anderen Benutzern eventuell längere Wartezeiten auftreten, wenn das Suchergebnis auf sich warten lässt. Man kann nun versuchen, Teilapplikationen der Internet-Datenbank-Lösung zu extrahieren, um diese auf verschieden benannte FastCGI-Programme, die Jedes für sich eine separate Datenbanksitzung unterhalten, umzulenken. Bei FastCGI muss man also in performancekritischen Fällen applikationsspezifisch entzerren, statt diesem Aufkommen mit parallelem Abarbeiten begegnen zu können.

Das Systemmanagement bei FastCGI ist in der Handhabung recht unkomfortabel, da die Installation in die Interna des WWW-Servers eingreift. Des weiteren bestehen Abhängigkeiten mit Perl, da zum Paket Funktionsbibliotheken für diese Sprache dazugehören [Assfalg et al. 1998], [Shelly Power et al. 1998].
 

9.3. Server-Erweiterungen durch APIs

Einige Internet-Server bieten spezielle Server-Application-Programming-Interfaces (APIs) an. Dies sind proprietäre Low-level-Schnittstellen, mit deren Hilfe man die Funktionalität eines Servers anwendungsspezifisch oder aufgabenspezifisch erweitern kann.

Anwendungsspezifische Erweiterungen können z. B. Datenbankzugriffe auf eine Dokumentendatenbank sein, die von einer speziellen Erweiterung in HTML konvertiert und zum Client gesendet werden.

Aufgabenspezifische Erweiterungen modifizieren z. B. die Logging-Fähigkeiten eines Servers, indem für jeden Zugriff neben den üblichen Informationen auch noch zusätzliche Daten in ein Logfile geschrieben werden.

Der Vorteil von Server-Erweiterungen ist, dass sie in aller Regel im selben Prozess- und Adressraum wie der Server selbst ablaufen. D. h. insbesondere unter hoher Last müssen nicht wie bei CGI für jeden Request zusätzliche Prozesse gestartet werden, sondern die Server-Erweiterung kann, einmal geladen, beliebig viele Requests (quasi-)parallel abarbeiten. D. h. APIs müssen durch die kontrollierte Verwendung von Threads parallelisiert werden. Wird dies nicht beachtet, kann dies zu Fehlfunktionen, im schlimmsten Fall zum gesamten Server-Absturz führen.

Technologisch gesehen werden APIs meist als dynamsiche Funktions- oder Objektbibliotheken realisiert, die vom Server bei Bedarf geladen oder entladen werden können.

Zusammenfassend kann man sagen, dass Server-APIs eine mächtige und performante Art der Entwicklung von Server-Erweiterungen sind, aber auch gefährlich und u. U. teuer. Gefährlich, weil jede Einzelne dieser Erweiterungen die gesamte Server-Integrität bis hin zum Server-Absturz beeinflussen kann und teuer, weil die Entwicklungsarbeit sehr komplex im Vergleich zur Programmierung anderer Gateways ist. Und weil die erstellten Erweiterungen i. d. R. nicht auf andere Betriebssysteme oder Server anderer Hersteller portierbar sind.
 
 

10. Middleware

Middleware steht als Oberbegriff für alle Systeme, die den Übergang zwischen bereits existierenden Web-Servern und Datenbanken ermöglichen.

10.1. Prinzip

Unter dem Begriff Middleware werden alle Systeme verstanden, die ausgehend von den vorhandenen Schnittstellen gängiger Web-Server und Datenbanksysteme den Übergang zwischen den Systemen so einfach und transparent wie möglich gestalten. Es gibt z. B. Systeme, die einer mit objektorientierter Technologie implementierten Web-Server-Anwendung eine objektorientierte Sicht auf eine Datenbank bieten können, die eigentlich ein relationales Datenmodell besitzt. Diese Art von Middleware leistet also die Transformation von Relationen auf Objektklassen und umgekehrt, unter Berücksichtigung der Abbildungsvorschrift. Grundsätzlich ist auch Middleware denkbar, die einem Web-Server, der eine auf eine relationale Datenbanktechnologie abgestimmte Schnittstelle wie ODBC besitzt, die Objekte eines objektorientierten Datenbanksystems in eine relationale Form transformiert [Assfalg et al. 1998].
 
 
Abb. 10.1: Verwendung von Middleware, die die Transformationsarbeit zwischen den Systemwelten leistet
 

Middleware kommt v. a. dann zum Einsatz, wenn Datenbanken in bereits existierende Mainframe-Lösungen oder Client-Server-Umgebungen mit dem Internet verbunden werden sollen. Der Nutzen liegt v. a. in der Vereinfachung und Vereinheitlichung der Systemschnittstellen, der besseren Skalierbarkeit der Systeme und in der Nutzung zentraler und wiederverwendbarer Softwarekomponenten.
 

Applikationsserver

Ein Applikationsserver ist eine Komponente der mittleren Schicht einer i. d. R. mehrschichtigen Client-Server-Architektur und bildet somit aus der Sicht der Internet-Clients eine Schnittstelle zu verschiedenen Backends, z. B. zu Datenbanken. Die zentrale Funktion des Applikationsservers ist die Vermittlung zwischen verschiedenen Clients und Servern, zunehmend aber auch die Speicherung und Aktivierung von Geschäftsprozessen [Rudat 1999].

Folgende Abbildung zeigt ein Modell, inkl. Firewallsystem (s. a. Kap. 13.), bei dem der Applikationsserver die zentrale Architekturplattform darstellt, bei der CORBA-, OMG-, DCOM-Technologien zum Einsatz kommen.
 
 

Abb. 10.2: Applikationsserver als zentrale Architekturplattform [Rudat 1999]
 
 

10.2. ColdFusion und WebObjects

ColdFusion und WebObjects sind serverseitige Lösungen für die schnelle Anwendungsentwicklung. ColdFusion steht i. d. R. über NT-basierte Internet-Service-Provider bereit und wird von kleinen und mittelgroßen Unternehmen eingesetzt. WebObjects ist ein Profiwerkzeug, das auf den meisten Server-Plattformen zur Verfügung steht und von kleinen und großen Firmen eingesetzt wird. Beide Werkzeuge sind Browser-unabhängig. Sie basieren auf einer offenen Architektur, um die Integration in herkömmliche Datenbanksysteme zu ermöglichen. Sie enthalten Hooks für die Einbindung von Code, der unter Verwendung anderer Web-Technologien, wie ActiveX, Java, CGI entwickelt wurde.

Die nahtlose Datenbankintegration, die diese Technologie charakterisiert, bedeutet, dass sie mit Datenbanken wie Access, Oracle und anderen heute gebräuchlichen Produkten verbunden werden kann.

Sowohl ColdFusion als auch WebObjects unterstützen bereits alle aktuellen Technologien, bzw. planen dies für die nahe Zukunft ein [Shelly Powers at al, 1998].
 

10.2.1. ColdFusion

ColdFusion (von Allaire) ist seit 1995 am Markt, heute in der Version 4.0, und wird unter Solaris und Windows NT unterstützt. Die Software ist ein gebräuchliches Entwicklerwerkzeug für die Web-Datenbankimplementierung auf NT- Maschinen. ColdFusion als Entwicklungslösung für Websites bietet eine nahtlose Datenbankanbindung und eine HTML-ähnliche Sprache mit der Leistungsfähigkeit von höheren Programmiersprachen. Das System besitzt eine leistungsfähige Markierungssprache CFML (ColdFusion Markup Language), die HTML und XML ähnlich ist. Über mitgelieferte APIs werden Datenbankabfragen aus Standard-ODBC-Datenbanken, wie Access oder Oracle, realisiert. Ebenso ist das Einlesen von Formularen möglich, die an Datenbanken übergeben werden.

Der Anwendungsserver ColdFusion 4.0 besteht aus folgenden Komponenten.

Application Server (ColdFusion Server)
Der Application Server wird als Dienst unter Windows NT ausgeführt. Er reagiert auf Anforderungen vom Webserver, die Seiten einer ColdFusion-Anwendung zu verarbeiten.

ColdFusion-Administrator
Dies ist eine Management-Konsole für Anwendungen, Anwendungsserver und Serverclusteradministration. Z. B. Konfiguration der ColdFusion-Datenquellen, Servereinstellungen, Debuggen der Ausgabe, etc.

ColdFusion Studio
Darunter wird eine integrierte Entwicklungsumgebung (IDE) mit einer Reihe von visuellen Tools zur Erstellung von ColdFusion-Anwendungen verstanden.

ColdFusion Extensions (CFX)
Darunter wird eine offene, XML-basierte Basisstruktur zum Erweitern von ColdFusion mit neuen Serverkomponenten und Verbindungen mit COM, CORBA, C, C++, etc. verstanden.

Desweitern gibt es:

ColdFusion-Anwendungsseiten
Die Anwendungsseiten sind die funktionellen Bestandteile einer ColdFusion-Anwendung. Dazu gehören die Seiten und Formulare der Benutzeroberfläche, die die Dateneingabe handhaben und die Datenausgabe formatieren. Diese Seiten und Formulare können ColdFusion-Tags, HTML-Tags, JavaScript und andere Elemente enthalten, die normalerweise in einer gewöhnliche HTML-Seite eingebettet werden können.

ODBC-Datenquelle
ColdFusion-Anwendungen können interaktiv mit jeder Datenbank arbeiten, die den ODBC-Standard unterstützt.

Weitere Datenquellen
Daten können auch von Verzeichnisservern abgerufen werden, die LDAP unterstützen, von Mailservern, die das Post Office-Protokoll (POP) unterstützen, etc.

LDAP (Lightweight Directory Access Protokoll) ist ein Standardprotokoll über TCP/IP für Verzeichnisdienste im Internet. LDAP wird im RFC 1777 definiert [LDAP 1999].
 

Anwendungsprozess

Fordert ein Browser eine ColdFusion-Anwendungsseite an, wird diese Seite zunächst von dem Browser als HTTP-Anfrage über das Internet an den Webserver gesandt (1). Der Webserver leitet die vom Client übermittelten Daten und die entsprechende Seite an den ColdFusion-Server über eine Server-API weiter (2). ColdFusion liest die Daten des Clients und verarbeitet CFML-Tags in der Seite. Basierend auf den CFML-Tags interagiert der Server mit dem Datenbankserver, bzw. anderen Anwendungen oder Erweiterungen (3). ColdFusion erstellt dynamisch eine HTML-Webseite, die an den Webserver zurückgegeben wird (4). Der Webserver gibt die HTML-Seite zurück an den Browser des Anwenders (5).

Da die gesamte Verarbeitung auf dem Server stattfindet, werden weder Clientsoftware, Komponenten oder Plug-Ins benötigt.
 
 

Abb. 10.2.1: ColdFusion Anwendungsprozess [ColdFusion 1998]
 

CFML

CFML ist ähnlich HTML und XML.
Folgendes Beispiel fragt alle Spalten aus der Tabelle KundenInfo ab.

<CFQUERY NAME=“namenabrufen“ DATASOURCE=“Kunden“>
     SELECT * FROM KundenInfo
</CFQUERY>
Das CFOUTPUT-Tag interpretiert die Variablen für Spaltennamen und gibt sie aus.
 
 
Abb. 10.2.2: Beispiel einer einfachen CFML-Seite und des dynamisch erstellten HTML-Codes, der an den Browser übergeben wird

Die Software wird v. a. von Entwicklern, die bereits mit HTML und SQL vertraut sind, genutzt. Es ist quasi eine Kombination von HTML mit der Leistungsfähigkeit von CGI-Sprachen.

Ausblick

Durch die offene Integration neuer, bzw. Legacy-Technologien, wie erweiterte Datenbank-Connectivity (ODBC, OLE DB, systemeigene Treiber), Integration der Internet-Technologie (E-Mail, FTP, LDAP), Enterprise-Erweiterungen (CORBA, COM), E-Commerce-Service (Verbindung zu Standard-Online-Zahlungssystemen), ist ColdFusion für Internetanwendungen, auch auf Basis von Datenkbanken geeignet. Es handelt sich hierbei um eine kostengünstige Lösung für kleine und mittlere Firmen, die dedizierte NT-Server für den Web-Support einsetzen.

Hauptanwendungsgebiete sind E-Commerce, Business-Informationssysteme, Spiele und Dynamisches Inhalts-Publishing.
[Shelly Powers at al., 1998], [ColdFusion 1998], [Reibold 1999], [ColdFusion 1999]
 

10.2.2. WebObjects

WebObjects funktioniert nach dem gleichen Prinzip wie ColdFusion und ist gut für Software-Ingenieure geeignet, insbesondere, wenn sie bereits mit den objektorientierten Konzepten vertraut sind. Für Nicht-Programmierer ist dieses Werkzeug nicht geeignet.

WebObjects ist ein Profi-Entwicklungswerkzeug für Websites, das auf der objektorientierten Umgebung von Apple basiert. Seine Kombination aus Web-Objekten, umfassenden Web-Entwicklungswerkzeugen, Datenbankunterstützung und offener Architektur machen es möglich, Geschäftslogik unabhängig von der zugrundeliegenden Software-Implementierung zu entwickeln.

Die grafischen Werkzeuge von WebObjects haben das Potenzial, den Entwicklungsaufwand erheblich zu verkürzen, insbesondere bei der Einrichtung von Verbindungen bereits existierender Datenbanksysteme mit dem Netz. Es ist objektorientiert und kann somit ganz einfach in existierende Technologien einbezogen werden. Es handelt sich hierbei um ein WYSIWYG-Entwicklungswerkzeug.
[Shelly Powers at al., 1998]
 
 

11. Lotus Domino

Zuerst wird die Philosophie von Lotus Notes vorgestellt, dann auf den Domino-Server eingegangen. Nach einer kurzen Beschreibung, was der Domino-Server leisten kann, folgt eine ausführliche Darstellung des Domino-Prinzips. Nur kurz wird auf die Konfiguration des Domino-Servers eingegangen.

11.1. Lotus Notes

Lotus Notes wurde von dem Unternehmen Lotus Development Corporation, einer Tochtergesellschaft von IBM, im Jahre 1989 erstmals auf den Markt gebracht. Inzwischen sind die Versionen 4.6, bzw. 5.0 bereits großflächig im Einsatz.

Lotus Notes als Kommunikationsplattform und Groupware ist ein System von gemeinsamen, verteilten und mailfähigen Datenbanken.

"Gemeinsam" bedeutet, dass mehrere Anwender gleichzeitig auf die Inhalte einer Datenbank zugreifen und diese aktualisieren können. Die Datenbanken sind "verteilt", da sie auf mehreren Servern abgelegt werden können, die in regelmäßigen Intervallen aktualisierte Daten untereinander austauschen. Nach einer gewissen Zeit haben aktualisierte Daten von einem Server alle  Datenbanken der anderen (angeschlossenen) Server erreicht. Dieser Prozess wird als "Replikation" bezeichnet. "Mailfähig" heißt, dass Nachrichten und Informationen an eine oder mehrere Personen gesendet, bzw. empfangen werden können. Lotus Notes-Datenbanken können Informationen aller Art enthalten, z. B. Text, Grafiken, Sound, Video, usw.

Als Groupware bietet Lotus Notes neben der Mail-Komponente auch die Option zur Einrichtung von Workflowmechanismen, die die tägliche Arbeit erleichtern und optimieren können. Das Konzept von Lotus Notes sieht vor, dass zusammengehörende Daten in Datenbanken als "Dokumente"  abgelegt werden. Über "Ansichten" wird den Benutzern eine sich, nach festgelegten Kriterien, ergebende Auswahl angezeigt, sodass die Übersichtlichkeit innerhalb der Datenbank unterstützt wird und der Benutzer Informationen gezielt abrufen kann. Eingabeformulare ("Masken") unterstützen den Anwender bei der Erstellung von Dokumenten.

Grafische Elemente zur Benutzerführung ("Navigatoren") sind integriert. "Agenten", als zu definierten Zeiten selbständig ablaufende Programme, nehmen automatisierbare Änderungen an den Dokumenten einer Datenbank vor. Über "Zugriffskontrollisten (ACL = Access Control List)" kann die Berechtigung zum Zugriff eines Anwenders auf eine Datenbank, heruntergebrochen bis zu einzelnen Ansichten und Dokumenten, gesteuert werden. Es können unterschiedliche Zugriffsrechte verteilt werden, so dürfen z. B. "Leser" nur Dokumente einsehen. "Autoren" sind berechtigt, Dokumente zu erstellen und ihre eigenen erstellten Dokumente zu ändern, "Editoren" dürfen Dokumente erstellen und alle, auch von anderen Personen erstellte, Dokumente verändern. "Entwickler" können Veränderungen am Design der Datenbank vornehmen. Das höchste Recht haben die "Manager", die alle aufgezählten Rechte besitzen und auch die eigentliche Rechteverwaltung inne haben.

Jeder Mitarbeiter erhält eine eigene Identifikationsdatei (ID-Datei), mit der er sich gegenüber Lotus Notes als berechtigte Person ausweisen muss. Diese ID-Datei ist mit einem Paßwort versehen, sodass Datenschutzaspekte berücksichtigt werden. Die Handhabung der Lotus Notes Datenbanken ist menügestützt und bis auf wenige Ausnahmen analog der Bedienung von Windows-Anwendungen [Denning et al. 1997].

Mit LotusScript stellt Notes eine eigene, objektorientierte Programmiersprache zur Verfügung, mit der eine Anwendung an die individuelle Benutzerumgebung angepasst werden kann. Ebenso sind funktionelle Erweiterungen möglich. Bestimmte Prozesse, z. B. periodische Replikationen, können von Agenten angestoßen und überwacht werden. Desweiteren ist mit LotusScript-Programmen die automatische Übernahme von Daten aus externen, Notes-fremden Datenbanken (z. B. Oracle) machbar.

Zusätzlich zu der Möglichkeit zum Im- und Exportieren über die Zwischenablage, stellt Notes weitere Mechanismen zur Verfügung, um auf externe Daten zuzugreifen. Das sind z. B. das Einbetten von Daten (OLE – Object Linking and Embedding), der dynamische Datenaustausch (DDE – Dynamic Data Exchange), die Verbindung mit Datenbanken über die ODBC-Schnittstelle und spezifische Notes-interne Funktionen zum Abfragen von externen Datenbanken (@DdLookup, @DbCommand). Zusätzlich bietet Notes Funktionen zum Öffnen und Anzeigen von Daten, die an Notes-Dokumente angehängt, bzw. in diese eingebettet sind. [Schroeter et al. 1998]

Nachfolgend wird ein Auszug aus dem Stärken-/Schwächen-Profil von Lotus Notes, bzgl. der Datenbankanbindung an das Internet nach [Dierker et al. 1999] gegeben. Die Aufstellung ist lediglich als Orientierungshilfe zu sehen. Im konkreten Anforderungsfall muss entschieden werden, ob der Einsatz von Notes-Datenbanken sinnvoll ist. Je nach Anwendungsfall kann evtl. die ein oder andere Schwäche auch als Stärke gesehen werden. Z. B. ist ein gewisses Maß an Redundanz nötig, um bestimmte verteilte Anwendungen zu realisieren.
 
 
Stärken Schwächen
  • Flexible Datentypen – Verarbeitung von weichen und harten Daten
  • Kein exclusives Sperren (Record locking) von Datensätzen möglich
  • Zahlreiche Sortierungs- und Kategorisierungsmöglichkeiten
  • Performance bei Massendaten - bei strukturierten/harten Daten liefern traditionelle (z. B. relationale) Datenbanksysteme bessere Performance und umfangreichere Abfragemöglichkeiten
  • Volltextsuche zum schnellen Wiederfinden von Informationen, auch über mehrere Datenbanken hinweg 
  • Datenkonsistenz - zwischen Replikationsvorgängen sind die Inhalte einer verteilten Datenbank nicht notwendigerweise gleich
  • Umfangreiches, auf verschiedenen Ebenen greifendes Sicherheitskonzept
  • Datenredundanz – Redundante Datenhaltung durch Mehrfachabspeicherung der Datenbank im verteilten Umfeld
  • Plattformunabhängigkeit
  • Maximale Datenbankgröße von 4 GB
  • Gute Skalierbarkeit
  • Für komplexe mathematische Funktionen nicht optimiert
  • Hohe Ausfallsicherheit durch Server-Clustering
  •  
  • Internet – Integration
  •  
  • Objektorientierte Entwicklungsumgebung
  •  

    11.2. Lotus Domino

    Mit dem Client-Server-System Lotus Notes und dem HTTP-Server Domino existiert ein System, das den Anforderungen entspricht, existierende Datenbestände auf einfache Weise in die Internet-Darstellung zu integrieren. Darüber hinaus soll die Interaktivität zwischen dem Web-Benutzer und dem Informationsanbieter in hohem Maße möglich sein.

    Die Philosophie besteht darin, dass der HTTP-Server Domino auf die Datenbasis und die Funktionalität von Notes zugreift, diese in eine HTML-Darstellung konvertiert und dem anfordernden Browser zur Verfügung stellt. Dabei entstehen keine statischen HTML-Dokumente, sondern es werden HTML-Dokumente direkt aus der Datenbasis dynamisch (on-the-fly) generiert. Alle Leistungsmerkmale für Datenbankanwendungen werden auch ins Internet übertragen. Dazu gehört z. B. die Darstellung eines komplexen Datenbestandes nach verschiedenen Gesichtspunkten.
     

    11.2.1. Prinzip

    Domino ist eine HTTP-Server-Technologie, die den Web-Anwendern über einen Internet-Browser die Kommunikation mit Domino-Servern und somit den Zugriff auf Notes-Daten und –Anwendungen ermöglicht.

    Domino kombiniert die offene Netzwerkumgebung der Internet-Standards und –Protokolle mit den Notes-Funktionen. Somit können Internetanwendungen erstellt werden, die die Notes-Funktionalitäten, wie z. B. die Dokumentenverwaltung, die Sicherheitskonzepte und Volltext-Suchfunktionen, beinhalten.

    Domino besteht aus der HTTP-Server-Komponente und dem Domino-Modul.

    Der HTTP-Server ist die direkte Schnittstelle zum Internet. Hier gehen die URL-Anforderungen der Browser ein und von hier werden die HTML-Dokumente an den Anforderer gesandt.

    Der HTTP-Server überprüft zunächst die URL und erkennt, ob die Anforderung ein Objekt in einer Notes-Datenbank betrifft, oder eine statische HTML-Seite im Dateisystem. Gilt die Anforderung einer HTML-Datei, arbeitet Domino wie ein herkömmlicher HTTP-Server und liefert die Datei an den Web-Client.

    Gilt die Anforderung jedoch einem Objekt in einer Notes-Datenbank, wandelt das Domino-Modul die Anfrage in eine für Notes verständliche Form um und übergibt diese an den Domino-Server, der wiederum die Verbindung zur angeforderten Datenbank, bzw. Anwendung herstellt. Das Domino-Modul ist also für die Kommunikation zwischen dem Internet einerseits und dem Notes-System andererseits verantwortlich. [Schroeter et al. 1998]

    Jede Aktion des Benutzer wird grundsätzlich von Domino in sog. URL-Befehle übersetzt. Diese Befehle werden i. A. automatisch generiert, lassen sich aber auch manuell eingeben. So sind zum Einen erweiterte Funktionen zugänglich, bzw. lässt sich auf diese Weise das Arbeiten in bestimmten Situationen beschleunigen.
    Die URL-Befehle besitzen grundsätzlich folgende Syntax:
    http://[Host]/[NotesObjet]?[Aktion]&[Argument]
    Z. B. lautet der Befehl zum Öffnen der Datenbank help.nsf mit vorheriger Benutzeridentifikation
    http://www.domino.de/help.nsf?OpenDatabase&Login
    Folgende Befehle können nützlich sein.
    ?OpenServer               Ermöglicht den Zugriff auf einen Domino – Server
    ?OpenView                 Öffnen einer Ansicht
    ?OpenDocument       Öffnen eines Dokumentes
    ?DeleteDocument     Löschen des angegebenen Dokumentes
    Weitere URL-Befehle inklusive Beschreibung finden sich in [Dierker et al. 1999] Absatz 5.1.2.9 und [Axt et al. 1999] Kapitel 28.

    Die Ergebnisse der Anfrage werden durch den Domino-Server an das Domino-Modul zurückgegeben. Dort wird die spezifische Notes-Darstellung in die HTML-Darstellung konvertiert und an den HTTP-Server übergeben, der das Dokument an den anfordernden Browser schickt.
     
     
     

    Abb. 11.1: Domino-Architektur
     

    Zu bemerken ist, dass für die Darstellung der Daten im Web (theoretisch) keine statischen HTML-Dokumente notwendig sind. Das Domino-Modul konvergiert vom Domino-Server übergebene Komponenten, wie Navigationsübersichten, Ansichten, Dokumente und Verknüpfungen automatisch in das HTML-Format. Notes-Verknüpfungen und Aktionsflächen werden auf dem Web-Client zu Hyperlinks. Dateianhänge werden so umgesetzt, dass diese Dateien aus dem Web heruntergeladen werden können. Bilder in Notes werden in das GIF-Format umgesetzt.

    Diese HTML-Darstellungen werden nicht zwischengespeichert, d. h. bei jeder Anfrage aus dem Internet wird direkt auf die Notes-Datenbasis zugegriffen, das geforderte Dokument gelesen und konvertiert. Dies bedeutet zum Einen eine höchstmögliche Aktualität, zum Anderen jedoch evtl. auch einen gewissen Performance-Verlust gegenüber Funktionsweisen, die mit zwischengespeicherten Dokumenten arbeiten. Ist der Notes-Server nicht verfügbar, können folglich überhaupt keine Informationen aus dem Internet abgefragt werden.

    Sobald ein Datum in einer Notes-Datenbank abgelegt ist, steht es automatisch für den Internet-Zugriff zur Verfügung. Dies ist v. a. für räumlich getrennte Clients, die auf die Datenbanken zugreifen von Bedeutung. Zeitverzögerungen durch Replikationen entfallen.
     
     

    Abb. 11.2 Ansichtsdarstellung unter Notes
     
     
    Abb. 11.3 Ansichtsdarstellung im Web

    Die Möglichkeiten der Darstellung von Notes-Datenbanken im Internet sind begrenzt, nutzt man „nur“ die vom Domino standardmäßig durchgeführte Konvertierungen der Notes-Daten in HTML-Dokumente.

    Da Domino einen herkömmlichen HTTP-Server beinhaltet, können auch bereits bestehende Internet-Applikatioinen, HTML-Darstellungen, CGI-Programme oder Java-Applets ohne zusätzliche Anpassungen weiter genutzt werden. Domino unterstützt ebenso in Perl geschriebene Programme, sowie JavaScript-Programme. Somit ist sowohl eine Integration als auch eine Weiterentwicklung bereits bestehender Applikationen möglich. Desweiteren können somit auch optisch anspruchsvollere Designs für Notes-Datenbanken im Internet geschaffen werden.
     
     
     

    Abb. 11.4: Optisch aufbereitete Darstellung

    Im Gegenzug dienen auch bestimmte Notes-Masken als Dialoge, die vom WWW-User ausgefüllt werden und dann automatisch in der Notes-Datenbank abgelegt werden und über die interne Notes-Strukutur per Workflow weiterverarbeitet werden. [Schroeter et al. 1998]
     

    11.2.2. Konfiguration des Domino-Servers

    Bei der Konfiguration des Domino-Servers sind eine Vielzahl Einstellungen zu wählen, die jedoch die Kommunikation zum Internet nicht beeinflussen, z. B. in welches Cluster der Domino eingebunden werden soll.

    Die HTTP-Einstellungen jedoch sind für das spätere Funktionieren der Verbindung zwischen Notes und Internet verantwortlich. In diesen allgemeinen Einstellungen  werden Bedingungen zwischen Domino-Server und Web-Browser definiert. Dazu gehören u. a. auch die Portnummern für einen Zugriff mittels TCP/IP-Protokoll oder dem Sicherheitsprotokoll SSL (Secure Socket Layer).

    Hier kann auch festgelegt werden, welches HTML- oder Notes-Dokument an den aufrufenden Client als Homepage übertragen werden soll, wenn dieser im URL den Domino-Server anspricht. Dies geschieht im Feld Standard-Homepage. Standardmäßig wird der Name „default.htm“ benutzt, er kann jedoch auch geändert werden.

    In einem Feld Hostname (Standardeinstellung ist „leer“) kann der vollständige Hostname des Computers angegeben werden, auf dem Domino installiert ist. Ist das Feld leer, verwendet Domino den bei den TCP/IP-Eigenschaften des Betriebssystems angegebenen Hostnamen. Wird ein Alias-Name verwendet, muss dieser im Domainnamen-Server (DNS) definiert sein. Es kann jedoch auch eine vollständige IP-Adresse eingegeben werden, wenn der Computer nicht auf einem DNS registriert ist.

    Mit dem Feld DNS-Suche wird festgelegt, ob Domino den DNS-Hostnamen der anfordernden Clients kontrollieren soll.

    Die Einstellung Maximale Anzahl Threads legt fest, wieviel Prozesse maximal gleichzeitig aktiv sein können. Dabei ist ein Thread in diesem Fall gleichzusetzen mit der Abarbeitung einer Anfrage aus dem Internet. Ist der Höchstwert erreicht, behält Domino neue Anforderungen zurück, bis wieder ein Thread verfügbar ist. Dies kann sich für den Client in einem langsamen Serverzugriff, bzw. langen Antwortzeiten äußern.

    Weitere Einstellungen bzgl. Bildkonvertierungsformaten, Standardzeilen pro Ansicht, Mapping-Einstellungen bzgl. der Notes-Verzeichnisstruktur, der Datenbank-Protokollierung und evtl. virtuellen Servern können ebenso vorgenommen werden. Details finden sich in [Schroeter et al. 1998].

    In [Fochler et al. 1998], Kapitel 16 sind weitere Aspekte bzgl. Installation und Konfiguration eines Domino-Servers beschrieben.
     

    11.3. Domino - Web – Sicherheit

    Im Folgenden wird dargestellt, wie Domino prinzipiell den Sicherheitsaspekten gerecht wird.

    Notes als Client-Server-System bietet eine Reihe von Sicherheitsmaßnahmen, auch über verschiedene Ebenen hinweg. Diese reichen vom Server, über die Datenbanken und Dokumente bis zur Feldebene. Hinzu kommt ein Verschlüsselungssystem, das ein unbefugtes Lesen der Daten unmöglich macht.

    Da Web-Clients mit den Web-Servern aus Basis des HTTP-Protokolls kommunizieren und Daten austauschen, können sie einige der Notes-spezifischen Sicherheitsmaßnahmen, wie z. B. Verschlüsselung, nicht verstehen. Ebenfalls können keine über die Dokumentenebene hinausgehende Sicherheitsregelungen (z. B. auf Feldebene) übernommen werden, da die HTML-Syntax eine Seitenbeschreibungssprache ist.

    Hinzu kommt, dass die Authentifizierung der Web-Nutzer, wenn überhaupt, auf der Basis eines Namens und Paßwortes geschieht, während Notes dazu eine spezielle Benutzer-ID verwendet.

    Jedoch sind auch viele Sicherheitseinrichtungen mit Domino im Internet verfügbar, wodurch sich ein Vorteil gegenüber herkömmlichen Web-Servern ergibt. Die jeweils sinnvollste Sicherheitskonzeption ist vom konkreten Anwendungsfall abhängig.

    Folgende Sicherheitsregelungen sind für den Zugriff auf Notes-Datenbanken über das Internet möglich.

    Sicherheitsebenen
    Über Sicherheitsebenen (Server, Datenbank, Dokumente) kann der Kreis der Berechtigten für bestimmte Aktionen, z. B. Lesen und Schreiben von Daten, eingeschränkt werden, wobei erweiterte Befugnisse auf einer höheren Ebene nicht in Anspruch genommen werden können.

    Zugriffsrechte
    Innerhalb jeder Ebene gibt es zusätzliche Sicherheitsmechanismen, z. B. abgestufte Zugriffsrechte für Benutzer auf Datenbankebene.

    Verschlüsselung
    Bestimmte Komponenten des Domino-Systems können verschlüsselt werden. Diese Verschlüsselung kann jedoch nicht auf die Internet-Kommunikation direkt übertragen werden, deswegen wurde das SSL-Protokoll implementiert, das für eine adäquate Verschlüsselung in diesem Bereich sorgt.

    Verbergen
    Bestimmte Daten in Notes können für das Anzeigen am Web-Browser ausgeschlossen werden. Da der Web-Server keinen direkten Zugriff auf die Notes-Datenbanken hat, können diese Sicherheitsfestlegungen auch nicht umgangen werden (im Gegensatz zum Verbergen von Daten für einen Notes-Client).

    Leser- und Autorenliste
    Eine weitere, tiefere Differenzierung der Rechte ist möglich. So kann z. B. ein Benutzer, der theoretisch für die gesamte Datenbank das Recht zum Lesen hat, für ein oder mehrere Dokumente aufgrund des Autorenrechts eines anderen Benutzers keine Rechte zum Lesen dieser Daten besitzen. [Schroeter et al. 1998]

    11.4. Zusammenfassung

    Notes und Domino-Server stellen eine starke Kombination zur einfachen Integration von Notes-Datenbanken ins Internet dar, sie sind jedoch kein Universalproblemlösungsmittel für Internet-Anwendungen. Ob die Funktionalität und das Potenzial des Systems ausreichen, muss vielmehr an der konkreten Aufgabe bewertet werden.

    Anwendungsszenarien für den Einsatz von Domino-Servern sind, z. B.

    12. Interaktion im Web

    Die Interaktion im Web unterscheidet sich grundlegend von Interaktionen in klassischen Anwendungs- und Informationssystemen. Die Weitergabe von Information zwischen Web-Seiten ist nicht selbstverständlich. Hier sind spezielle Maßnahmen zur Informationsweitergabe notwendig. Im Gegensatz dazu spielt dieses Thema in klassischen Transaktionen kaum eine Rolle.

    12.1. Vergleich zu klassischen Transaktionen

    Auf die prinzipiellen Probleme beim Verwalten von Dialogabläufen wird an dieser Stelle nicht eingegangen. Der Fokus dieses Abschnittes liegt auf den Möglichkeiten, Informationen zwischen Web-Seiten weiterzugeben. Das Thema ist im Hinblick auf die Anbindung von Datenbanken an das WWW wichtig.

    Wenn man davon ausgeht, dass die Informationen des Informationssystems im WWW dynamisch aus der Datenbank ermittelt werden und dass der Nutzer Einfluss darauf hat, welche Informationen zu selektieren sind, dann benötigt man im einfachsten Fall zwei Seiten:

    Dieses Dilemma beschreibt [Assfalg et al. 1998] allgemeiner:

    Als Dialog verstehen wir die Hintereinanderreihung einzelner Dialogschritte. Traditionell ist dies im Internet das zeitlich gestaffelte Besuchen von HTML-Seiten. Eine ganz zentrale Eigenschaft des Internet-Dienstes WWW besteht darin, dass einzelne Navigationsschritte eigentlich nicht miteinander in Beziehung stehen. Jedes Verfolgen eines Hyperlinks, jeder Navigationsschritt steht dabei für sich. Sind im Rahmen einer Applikation mehrere Schritte nötig, werden z. B. diverse Web-Seiten bei der Abarbeitung einer Transaktion benötigt, so bieten Web-Server standardmäßig hierfür keine Unterstützung: Wenn die erste Seite abgeschlossen ist, muss dieser Transaktionsteil direkt festgeschrieben oder verworfen werden. Es ist nicht möglich, beispielsweise bei der fünften Seite die Aktionen, die bei der ersten Seite durchgeführt wurden, durch ein Rollback ungeschehen zu machen. Die Interaktion zwischen WWW-Client und Web-Server könnte man eher als clientlastig bezeichnen, da die Dialoghistorie der bereits "abgegrasten" Dokumente im Client-Programm mitgeführt wird. Der Server bekommt davon nichts mit, denn die Back-Funktion, wie sie in jedem WWW-Client vorhanden ist, realisiert ihre Funktionalität auf eigener Grundlage.

    Eine Möglichkeit, dieses Problem zu lösen ist die Dialogsteuerung über URL-Erweiterungen. Dabei enthält jede URL alle in dieser Sitzung noch benötigten Informationen. Einige der bekannten Internet-Suchmaschinen sind so programmiert (z. B. Altavista, HotBot, WebCrawler, InfoSeek). Die prinzipielle Vorgehensweise ist in Abb. 12.1 skizziert. Diese Art der Dialogsteuerung stößt allerdings bald auf ihre Grenzen, da hier die Länge der benötigten URLs sehr schnell wächst.
     
     
     

    Abb.12.1: Die Verweisstruktur von Altavista-Antwortdokumenten, welche die ursprüngliche Suchanfrage weiterreichen (URLs vereinfacht) [Assfalg et al. 1998]
     

    Eine weitere Möglichkeit ist die Verwendung von Cookies. Seit 1996 werden sie von allen gängigen Internet-Clients unterstützt. Eingeführt wurden Cookies von Netscape. Mit ihrer Hilfe ist sowohl eine Sitzungsverwaltung als auch die Feststellung von Benutzerinteressen möglich. Das Besondere hierbei ist, dass sie nicht nur für eine einzelne Web-Seite, sondern für ganze Pfadbereiche gelten. Zur Datenübertragung sind die Cookies in den HTTP-Header eingebettet. Die Speicherung der Cookies erfolgt auf Seiten des Clients. Sie können bei Bedarf mit einem Verfallsdatum gekennzeichnet sein.

    Ein Cookie enthält - neben anderen Informationen - im Kern Wertepaare aus "Name" und "Wert". Darüber können - ähnlich wie bei Variablen - Informationen zwischengespeichert und für spätere Verwendungen zur Verfügung gestellt werden.

    Im Umfeld der klassischen Anwendungsentwicklung spielt dieses Thema keine so große Rolle, da hier über Variablen und Parameter genügend Möglichkeiten zum Datenaustausch bestehen.

    Eine weitere Nutzungsmöglichkeit für Cookies ist die Verwaltung von Sitzungen. Während in der klassischen Anwendungsentwicklung eine feste Verbindung zwischen Client und Server besteht, bzw. der Server den Client bei jeder Anfrage wiedererkennt, ist es in der Web-Umgebung nicht mehr möglich, die Verbindung von Server-Seite zu verfolgen. Hierzu schreibt [Krause 1999]:

    Sessions haben ihren Ursprung in Begrenzungen des HTTP-Protokolls. Dieses Protokoll, das die Verbindung von Webserver und Browser steuert, ist ein sogenanntes verbindungsloses oder statusloses Protokoll. Für jedes einzelne Objekt, jede Seite, jedes Plug-In wird immer wieder neu eine Verbindung aufgebaut. Der Webserver kann also in größeren Abständen zugreifende Nutzer nicht wieder zuordnen. Er liefert aber nur Daten an irgendwelche immer wieder und irgendwann anfordernde Browser. Alle Interaktionen beruhen auf einem primitiven Frage-Antwort-Spiel (Request and Response).

    Man kann nun Cookies auch dazu nutzen, Information über eine Sitzung zu verwalten.

    Wie aus den vorangegangenen Ausführung ersichtlich wird, ist die Arbeit mit Transaktionen im klassischen Sinne im WWW nicht vorgesehen. Hier wird mit teilweise nachträglich eingeführten Erweiterungen gearbeitet, die helfen sollen, Informationen zur Sitzung zu verwalten.
     
     

    12.2. Internet Transaction Server von SAP

    12.2.1. SAP R/3

    Unter dem Begriff Internet Transaction Server (ITS) vertreibt die Firma SAP die Anbindung ihrer Standardsoftware SAP R/3 an das Internet. Dies beinhaltet mehrere Funktionen. Neben der generellen Ausführung von Auswertungen, bieten sich auch Möglichkeiten, Verbuchungstransaktionen über das Internet aufzurufen. In diesem Kapitel liegt der Schwerpunkt auf der Betrachtung der Weitergabe von Informationen innerhalb des Systems zur Steuerungen von Interaktion. Um auf dieses Thema eingehen zu können, bedarf es vorher ein paar grundsätzlicher Erläuterungen zu SAP R/3 bzw. der Verbindung Web und SAP R/3.
     

    Bei [Kemper et al. 1997] ist SAP R/3 kurz als betriebswirtschaftliches Datenbankanwendungssystem charakterisiert. Er schreibt hierzu:

    Das System SAP R/3 ist der Marktführer unter den betriebswirtschaftlichen Anwendungssystemen. Es integriert sämtliche Abläufe eines Unternehmens - und damit auch die anfallenden Daten. SAP R/3 arbeitet auf der Basis eines relationalen Datenbanksystems, in dem alle Anwendungs- und Kontrolldaten gespeichert sind. Das relationale Datenbanksystem dient somit als Integrationsplattform für alle betrieblichen Vorgänge. Dabei können die Anwender aus einer Reihe von kommerziellen relationalen Datenbankprodukten frei wählen [Kemper et al. 1997].
     

    12.2.2. Der Internet Transaction Server

    Mit dem Internet Transaction Server (ITS) bietet SAP eine Möglichkeit, das R/3-System und den Web-Server miteinander zu verbinden. Der prinzipielle Aufbau ist in Abb. 12.2 dargestellt. Das Web-Gate (W-Gate) ist für die Datenbearbeitung von eher untergeordnete Bedeutung. Es erhält bereits reine HTML-Seiten. Es ist aber dennoch wichtig, da es möglich ist, zwischen W-Gate und A-Gate einen zusätzlichen Firewall zu installieren. Das Application-Gate (A-Gate) hingegen ist die Hauptkomponente des ITS. Sie bietet die Schnittstelle zwischen W-Gate und R/3 an. Außerdem ist sie für die Umwandlung der R/3-Daten (Bildschirme, Auswertungslisten) in HTML zuständig. Dazu benötigt es zusätzliche Informationen zum Aufbau der HTML-templates. Die Erstellung der HTML-templates erfolgt separat über das SAP@WEBSTUDIO. Das Sitzungsmanagement ist ebenfalls Teil des A-Gates.

    Mit Hilfe des SAP@WEBSTUDIOs kann den einzelnen HTML-Seiten ein bestimmtes Aussehen mitgegeben werden. Dazu sind entsprechende Vorlagen im Studio zu definieren. Diese können z. B. ein Logo oder ähnliches enthalten. Das SAP@WEBSTUDIO sorgt dann dafür, dass die HTML-templates eine entsprechende Formatierung erhalten. Es dient also dazu, die Web-spezifischen Formatierungen vorzunehmen.
     
     

    Abb.12.2: Die Einbindung des Internet Transaction Servers zwischen Web-Server und SAP R/3
     

    Mit Hilfe des ITS sind nun unterschiedliche Zugriffe auf die Daten und Programme des R/3-Systems möglich. Es gibt einerseits das WebReporting, das es ermöglicht, beliebige Auswerteprogramme des R/3-Systems im Web zu nutzen. Andererseits können bestimmte Transaktionen aus dem R/3-System ebenfalls innerhalb des Web genutzt werden. Auf den zweiten Teil wird hier nicht näher eingegangen, da dieses Thema eher in den Bereich Anwendungsentwicklung geht. Im Folgenden steht das WebReporting im Mittelpunkt.
     

    Über die Aufgaben des WebReporting schreibt SAP:

    Mit dem WebReporting soll ein bestehender Report vom Web aus aufgerufen werden, seine Liste wird in ein HTML-Format konvertiert und mittels Web-Browser angezeigt. Die Web-Seite soll so aufgebaut werden, dass bei Bedarf Interaktionen möglich werden (z. B. Aufruf von Folgereports) [SAP].

    Durch diese Möglichkeiten können alle bestehenden Auswertungen (z. B. aus den diversen Informationssystemen innerhalb von R/3) nicht nur innerhalb des R/3-Systems genutzt werden. Mit dem SAP@WEBSTUDIO ist es möglich, das Aussehen zu vereinheitlichen und die Auswertungen auch im Intranet oder Internet zur Verfügung zu stellen.
     

    12.2.3. Reporting innerhalb SAP R/3

    Bevor nun auf den genauen Ablauf des WebReportings eingegangen werden kann, muss zuerst das Reporting im SAP-System selbst beschrieben werden. Diese Abläufe werden vom WebReporting vorausgesetzt. Die zur Verfügungstellung der Auswertungen basiert auf den Grundlagen der Programmentwicklung von SAP R/3.

    Die Programmiersprache innerhalb SAP R/3 ist ABAP. Ein typisches Auswertungsprogramm startet mit einem Selektionsbild. Auf diesem Bild können die Ergebnisse der Auswertung beeinflusst werden. Dazu ist es möglich, Werteinschränkungen etc. zu treffen. Nach Bestätigung des Selektionsbildes wird dann die eigentliche Auswertung gestartet und das Ergebnis am Bildschirm aufbereitet. Beide Teile der Auswertung sind innerhalb des Programms definiert. Dazu können noch weitere Steuerungen auf Eventebene kommen, von denen hier abzusehen ist. Es ist möglich, die Angaben auf einem Selektionsbild zu speichern. Damit müssen gleichlautende Abfragen nicht immer wieder neu eingegeben werden. Die Speicherung erfolgt über sogenannte Varianten. Eine Variante gehört zu genau einem Report und enthält Vorbelegungen der Felder des Selektionsbildes. Eine Variante hat einen Namen unter dem sie gespeichert ist und mit dem sie aufgerufen werden kann.

    An dieser Stelle ist noch zu erwähnen, dass es in ABAP auch die Möglichkeit gibt, mit sogenannten Funktionsbausteinen zu arbeiten. Diese stellen wiederverwendbare Funktionen dar, die an zentraler Stelle zur Verfügung stehen und bei Bedarf von allen Programmen genutzt werden können.
     

    Was muss nun getan werden, um einen solchen Report auch im Web nutzen zu können?
    Am Report selbst muss nur sehr wenig bzw. gar nichts getan werden. Es ist lediglich sicherzustellen, dass der Report durch eine Berechtigung geschützt ist. Diese Berechtigung wird im WebReporting genauso geprüft, wie im Reporting innerhalb des R/3-Systems. Der einzige Unterschied besteht darin, dass Reports ohne Berechtigung innerhalb von SAP von allen Anwendern verwendet werden können, während solche Reports im WebReporting gar nicht zulässig sind. Außerdem gibt es einige Einschränkungen, die ein Report erfüllen muss. Ansonsten ist er nicht für das WebReporting geeignet. Auf eine konkrete Aufzählung der Einschränkungen ist an dieser Stelle verzichtet worden, da zum Verständnis nähere Kenntnisse des SAP-Systems notwendig sind. Für nähere Informationen sei an [SAP] verwiesen.
     

    12.2.4 WebReporting mit dem Internet Transaction Server

    Wie funktioniert nun der Aufruf und der Ablauf eines Reports über WebReporting?
    Innerhalb der WWW-Seiten wird der Report aufgerufen. Dazu ist z. B. der Name anzugeben. Die Angabe könnte auch innerhalb einer speziellen WWW-Seite durch Auswahl erfolgen. Die Übergabe des Reportnamens und gegebenenfalls der Variante erfolgt über die URL. Innerhalb des R/3-Systems stehen nun diverse Funktionsbausteine zur Verfügung, mit denen das WebReporting möglich ist.

    Durch Aufruf des Funktionsbausteins WWW_GET_SELSCREEN über RFC (genauer gesagt über eine spezielle Variante des RFC: WebRFC) unter Angabe des Reportnamens als Parameter wird die nächste WWW-Seite erstellt. Der Funktionsbaustein WWW_GET_SELSCREEN ermittelt den Selektionsbildschirm so wie er im R/3-Systen bei Aufruf des Reports erstellt würde. Daraus wird eine HTML-Seite mit den entsprechenden Eingabefeldern generiert. Der Aufbau der Seite wird im A-Gate noch um die Informationen aus dem SAP@WEBSTUDIO ergänzt. Die endgültige HTML-Seite ist somit erstellt und wird über W-Gate und Web-Server an den Web-Browser weitergegeben. Diese HTML-Seite enthält neben den Eingabefeldern des Original-Selektionsbildes noch ein zusätzliches Eingabefeld, welches die Angabe der gewünschten Variante ermöglicht. Zusätzlich gibt es einen Button "OK", der die Bearbeitung der HTML-Seite beendet und den eigentlichen Report aufruft.

    Zum Aufruf des Reports steht wiederum ein Funktionsbaustein innerhalb des SAP-Systems zur Verfügung. Der Funktionsbaustein heißt WWW_GET_REPORT. Die Datenbeschaffung des WebReportings erfolgt über den Report aus dem R/3-System. Dieser wird mit den angegebenen Daten aus dem Selektionsbild durchgeführt. Die Durchführung über den Funktionsbaustein für das WebReporting bewirkt aber, dass die Ausgabe der Auswertung so umformatiert wird, dass sie möglichst optimal im HTML-Format anzeigbar ist. Das Ergebnis ist wiederum eine HTML-Seite, die über A-Gate, SAP@WEBSTUDIO und W-Gate an den Web-Browser und den Web-Client weitergeleitet wird.

    Die Funktionsbausteine sorgen dabei jeweils dafür, dass benötigte Tasten etc. analog dem R/3-System auch auf der Web-Seite zur Verfügung stehen. Dadurch entsteht zumindest an der Oberfläche der Eindruck, dass man sich analog des SAP-Systems in einem interaktiven System mit Transaktionsmanagement befindet.
     

    12.2.5. Zusammenfassung

    SAP bietet mit dem ITS eine Möglichkeit, generell Teile des R/3-Systems auch im Internet oder Intranet zur Verfügung zu stellen. Dabei ist selbstverständlich auch vorgesehen, dass sich der Anwender dem System gegenüber mit User und Paßwort identifizieren muss. Auf diese Identifizierung kann aber auch verzichtet werden, dann wird der User im A-Gate fest hinterlegt. Ein großer Vorteil der Lösung ist, dass viele Teile des R/3-Systems nun auch im Web zur Verfügung gestellt werden können. Gerade auch innerhalb einer Firma kann hier bei Informationsusern erheblicher Einarbeitungsaufwand gespart werden, indem einige Personen auf das SAP-System nur über die bekanntere Oberfläche des Web-Browsers zugreifen.

    Allerdings ist sowohl das WebReporting als auch die Nutzung von Transaktionen noch zu vielen Einschränkungen unterworfen. Viele Auswertungen der R/3-internen Informationssysteme dürften die Einschränkungen nicht erfüllen und so im Standard für das WebReporting nicht geeignet sein. Hier gibt es noch Handlungsbedarf.

    Auch bei den von SAP für das Internet bereitgestellten Transaktionen gibt es noch Probleme. Diese funktionieren bislang nur in einer reinen Standardumgebung auch über das WWW. Bereits veränderte Einstellungen können bewirken, dass die Transaktion so nicht genutzt werden kann. Auch hier ist noch erheblicher Handlungsbedarf. SAP hat allerdings bereits bei den letzten Versionen seines R/3-Systems erhebliche Erweiterungen in diesem Bereich vorgenommen, die mir im Detail nicht bekannt sind. U. U. ist ein Teil der genannten Probleme nicht mehr aktuell.

    Bei der Realisierung der Anbindung ist allerdings mit einigem Aufwand zu rechnen. Nach Installation des ITS können sicher viele einfache Funktionen schnell im WWW zur Verfügung gestellt werden. Neuentwicklungen bewirken allerdings, dass entsprechende Entwicklungen im R/3-System vorzunehmen sind. Entsprechende Kenntnisse der Programmierumgebung sind dazu erforderlich. Dazu kommt, dass für die Einstellungen und gegebenenfalls Programmierungen auch HTML-Kenntnisse notwendig sind. Es werden hier daher erhebliche Kenntnisse in beiden Bereichen notwendig sein.
     

     13. Datensicherheit / Firewall - Besonderheiten bei DBMS-Anbindung

    Das Thema Sicherheit wurde bereits in vorangegangenen Seminararbeiten diskutiert. Dabei ist die Funktion des Firewalls bereits genannt worden.

    Sobald eine dynamische Anbindung von Web-Seiten an Datenbanksysteme vorhanden ist, stellt sich eine Besonderheit ein. Der Web-Server benötigt nämlich zwingend Zugriff nach außen (Ausnahme: reine Intranet-Anwendung) und Zugriff auf das lokale Netz. Damit muss zwingend ein technischer Weg vom Web-Server in das lokale Netz vorhanden sein. Wäre das nicht der Fall, so könnte auch keine Datenbeschaffung aus dem (zentralen) Datenbanksystem erfolgen.

    Wichtig ist nun die Realisierung von Sicherungsmechanismen, die sicherstellen, dass niemand direkt auf das zentrale Datenbanksystem zugreifen kann. Direkt heißt in diesem Fall unter Umgehung des Web-Servers.

    Die Sicherstellung, dass das eigentliche Informations- oder Anwendungssystem vom Web-Server nur Daten bereitstellt, die auch nach außen sichtbar sein sollen, gehört zu den Prinzipien der Softwareentwicklung und soll hier nicht weiter vertieft werden. Was passiert aber, wenn jemand am eigentlichen Informations- oder Anwendungssystem vorbei versucht auf das lokale Netz zuzugreifen? Dies darf nicht geschehen. Durch die Installation eines entsprechend ausgelegten Firewalls müssen solche Zugriffe unterbunden werden.

    In diesem Zusammenhang sollen hier kurz zwei Techniken vorgestellt werden, die solche Eingriffe verhindern. Bei beiden Techniken steht der Web-Server im Mittelpunkt. Bei der ersten Technik verwendet man den Web-Server als Screened Host Firewall. Bei der zweiten Technik ist der Web-Server ein Dual-Homed Gateway.
     

    13.1. Web-Server als Screened Host Firewall

    Die Verwendung des Web-Servers als Screened Host Firewall ist in Abb. 13.1 dargestellt. Diese Art der Absicherung ist relativ einfach. Der Netzwerk-Router lässt dabei nur Verbindungen zu einem einzigen Rechner im lokalen Netz zu. Das ist der Bastion Host, der im Zusammenhang mit dem WWW vom Web-Server dargestellt wird. Damit ist der WWW-Server der einzige von außen erreichbare Rechner im lokalen Netz. Weitere Verschärfungen dieses Prinzips (z. B. beim Screened Subnet Firewall) bieten zusätzliche Funktionalitäten an. Diese spielen aber im Zusammenhang mit Zugriffen von außen keine Rolle.
     
     
    Abb.13.1: Der Web-Server als Screened Host Firewall [Assfalg et al. 1998]
     

    13.2. Dual-Homed Gateways

    Ein weiteres Konzept stellen die Dual-Homed Gateways dar. Das Prinzip ist in Abb. 13.2 dargestellt. Der Hinweis in Abb. 13.2 auf das Screened Subnet bezieht sich darauf, dass auch der Zugriff vom lokalen Netz auf das WWW über das Gateway erfolgen muss. [Assfalg et al. 1998] schreibt zu dem Konzept der Dual-Homed Gateways:

    Firewall-Konzepte auf Applikationsebene bieten sich für WWW auf der Basis von WWW-Proxy-Servern an. Proxy-Server vermitteln zwischen dem lokalen Netz und dem Internet. Aus der Sicht des lokalen Benutzers verhalten sie sich wie ein Web-Server. Nach außen hin jedoch bauen sie selbständig Verbindungen zu anderen Web-Servern auf und verhalten sich dabei wie WWW-Clients. Das entspricht dem Firewall-Konzept eines Dual-Homed Gateways.

    Eine adäquate Lösung für die Absicherung eines lokalen Netzes einerseits und der Kontrolle von WWW-Aktivitäten andererseits besteht in der Kombination des Einsatzes von WWW-Proxy-Technologie, also einer Firewall-Lösung nach dem Prinzip eines Dual-Homed Gateways und einer Firewall auf Netzwerkebene, z. B. nach dem Prinzip einer Screened Subnet Firewall. Dabei bilden WWW-Proxy-Server und Bastion-Host eine Einheit, und es wird der Zugang zum Internet sowohl für interne als auch lokale Benutzer unterbunden. Der lokale WWW-Proxy-Server, der gleichzeitig Bastion-Host ist, bildet dann den einzig möglichen Übergang zwischen dem lokalen Netz und dem Internet. Mit dieser Lösung kann einerseits der Verkehr exakt kontrolliert werden, indem jeder WWW-Zugriff an zentraler Stelle registriert wird. Andererseits ist es möglich, den Zugriff auf andere Web-Server bis auf wenige Ausnahmen generell zu erlauben.
     
     

    Abb. 13.2: WWW-Proxy-Server als "Dual-Homed Gateway" integriert in ein "Screened Subnet"
     

    13.3. Besonderheiten bei der DBMS-Anbindung

    An dieser Stelle ist noch auf ein paar Besonderheiten im Rahmen der DBMS-Anbindung einzugehen. Dazu soll hier zuerst betrachtet werden, was zu tun ist, um über das Web in ein DBMS einzubrechen. Es sind zwei Schritte notwendig: 1. Man muss sich erfolgreich mit der IP-Adresse und dem Port, an dem das DBMS lauscht, verbinden.

    2. Man muss sich am DBMS mit User und Paßwort anmelden.
     

    Welche - zum Teil sehr einfachen und trivialen - Vorkehrungen können nun getroffen werden, um den Einbruch in das DBMS zu verhindern? Im Folgenden sind einige dieser Punkte aufgezählt. Sie sind an [Greenspun 1998] angelehnt. 1. Web-Server und DBMS sollten auf unterschiedlichen Maschinen laufen und mit unterschiedlichen IP-Adressen arbeiten.

    2. Die voreingestellte Portnummer sollte möglichst nicht verwendet werden.

    3. User und Paßwort des DBMS sollten nicht dem vom Hersteller voreingestellten entsprechen.

    4. Installation eines Firewalls zum Schutz des DBMS.

    Diese Punkte hören sich trivial an, werden in der Praxis laut [Greenspun 1998] oft nicht berücksichtigt.
     

    Ein weiteres Thema ist die Datenbeschaffung von WWW-Informationssystemen.
    Im Mittelpunkt steht hier die Frage, ob ein WWW-Informationssystem eher mit einem Data Warehouse-System oder eher mit einem OLTP-System vergleichbar ist.

    Dazu sollen zuerst die Begriffe Data Warehouse und OLTP erklärt werden.

    [...] ist die Performance eine der wichtigsten Eigenschaften der Systeme, die auf der Transaktionsverarbeitung basieren. Solche Systeme werden OLTP-Systeme (OnLine Transaction Processing) genannt. Basierend auf der Performance haben die OLTP-Systeme einige weitere Eigenschaften:

    [Petkovic 1999]

    Daten eines OLTP-Systems sind dynamisch, weil sie ständig geändert werden. Die Ergebnisse der meisten Operationen auf Daten eines OLTP-Systems beziehen sich auf eine relativ kleine Datenmenge (obwohl es durchaus möglich ist, dass das Datenbanksystem für die Erstellung des Ergebnisses viele Reihen verarbeiten muss.

    In den letzten Jahren hat der Umfang der Daten, die in den operationalen Datenbanken (das sind die Datenbanken, die von OLTP-Systemen verwaltet werden) gespeichert sind, ständig zugenommen. Heutzutage gibt es viele operationale Datenbanken, die einige GB von Daten beinhalten. Trotzdem ist diese Größe wie wir gleich sehen werden, relativ klein im Vergleich zu den meisten Data Warehouses [Petkovic 1999].
     

    Data Warehousing ist der Prozeß der Integration aller Daten eines Unternehmens in eine Datenbank, die dann für ad-hoc-Abfragen und die Erstellung von Berichten verwendet werden kann. Ein Data Warehouse ist also der Speicherungsort für die Daten, die von Endbenutzern analysiert werden können, um eine Entscheidungen in bezug auf ihre Geschäftsvorgänge zu treffen.

    Im Unterschied zu OLTP-Prozessen, die operativ genannt werden, werden die Data Warehousing-Systeme informative Systeme genannt, weil durch sie die Endbenutzer die notwendige Informationen für die zukünftigen Geschäftsentscheidungen bekommen.

    Das Ziel eines Data Warehousing-Systems unterscheiden sich von den Zielen eines OLTP-Systems. Aus diesem Grund hat ein Data Warehousing-System andere Eigenschaften als ein OLTP-System. Die wichtigsten Eigenschaften eines Data Warehousing-Systems sind:

    [Petkovic 1999]
     

    Ein WWW-Informationssystem kann nun sowohl auf einem Data Warehouse-System als auch auf einem OLTP-System basieren. Es kommt letztendlich immer auf den Anwendungszweck der vorhandenen Daten an. Es kann sowohl sinnvoll sein, eine WWW-Verbindung zu OLTP-Systemen zu schaffen (z. B. Auskünfte zur Lieferbarkeit von Artikeln), als auch eine Verbindung zwischen einem Data Warehouse und dem Internet zu schaffen (z. B. statistische Auswertungen über verkaufte Produkte in einem bestimmten Zeitraum).
     
     

    13.4. Zusammenfassung

    Zusammenfassend lässt sich an dieser Stelle sagen, dass bei den Sicherheitsmaßnahmen in Zusammenhang mit Webanbindung und DBMS-Nutzung drei Teile zu berücksichtigen sind. Es ist der Web-Server und das lokale Netz als solches zu sichern. Dazu ist das DBMS selbst gegen unbefugten Zugriff (auch innerhalb des lokalen Netzes) zu sichern. Als letztes kann es sich als sinnvoll erweisen, die technische Anbindung nicht über den vom Hersteller vorgesehenen Standardweg (sprich über die vorgegebene Portnummer) zu realisieren.
     
     

    14. Zusammenfassung / Ausblick

    In der vorliegenden Ausarbeitung wurden verschiedene Möglichkeiten der Datenbankanbindung an das WWW erläutert: Jede dieser möglichen Arten der Datenbankanbindung hat Vor- und Nachteile. Diese sind in den entsprechenden Kapiteln dargestellt. Zu jeder einzelnen Möglichkeit wurde jeweils ein Beispiel präsentiert, das das vorliegende Prinzip realisiert hat.

    Anschließend wurde noch auf einzelne Sonderthemen wie den Lotus Domino, Interaktion und Datensicherheit eingegangen.

    Der Beitrag soll dabei unter anderem die Vielfalt der realisierten Möglichkeiten darstellen. Ein großer Nachteil dieser Konzepte ist meist auch die mangelnde Kompatibilität in andere Umgebungen. So stellt sich die Datenbankanbindung an das WWW zur Zeit keinesfalls so dar, dass mit einer einmaligen Entscheidung für ein Prinzip dem Thema Genüge getan ist. Bei jeder neuen Umgebung (z. B. anderer Web-Server oder anderes DBMS) kann sich wieder ein völlig anderes Bild der Möglichkeiten und auch der Vor- und Nachteile ergeben. Ursache dafür ist sicher auch die fehlende Standardisierung.

    Dieses Thema bietet also noch vielfältige Möglichkeiten der Entwicklung und Standardisierung. Dass es hier noch viel zu tun gibt beschreibt auch die folgende Darstellung:

    Waren traditionell Anwendungsentwicklung und Datenbankanwendungen getrennt, verschmischen sich heutzutage klassische Datenbankprodukte mit integrierten Anwendungsentwicklungsumgebungen, sodass die Trennlinie zwischen Datenbankteil und Anwendungsteil immer mehr verwischt wird.

    Durch die Integration von Datenspeicherungskomponenten und Anwendungsentwicklungsumgebungen müssen Internet-Lösungen nicht nur Zugriff auf die Daten ermöglichen, sondern auch die Interaktion mit dem Anwendungssystem einbeziehen.

    Bei der Anbindung von Internet-Applikationen kann man in Anlehnung an die Historie der Softwareentwicklung von Generationen sprechen. Die erste Generation wird demnach repräsentiert durch Web-Anwendungen, die rein statisch sind. Die zweite Generation wird durch Konfigurationen dargestellt, die Interfaces wie CGI und FastCGI vorsehen, bei denen Datenbankentwicklung und Anwendungsentwicklung noch völlig voneinander getrennt sind. Die dritte Generation sind Skript-Lösungen, die zumindest die Trennung der Implementation der Funktionalität von der Datenbankseite und der Anwendungsseite aufheben. Es fehlt jedoch noch immer ein Konstrukt, mit dem Dialogfolgen zueinander in Beziehung gesetzt werden können.

    Die Frage, welche der im Beitrag beschriebenen Lösungen zur Anbindung von Datenbanken den Anderen vorzuziehen ist, kann nicht allgemeingültig beantwortet werden, sondern muss vielmehr am konkreten Anwendungsfall mit all seinen Randbedingungen (z. B. Legacy-Systeme, kompletter Neuaufbau, keine oder sehr hohe Anforderung nach Aktualität, etc.) und unter Betrachtung von Kosten-/Nutzenaspekten entschieden werden.

    Die vierte Generation, und somit die Vision bzgl. der Anbindung von Datenbanken an das Internet, wäre eine Art von Web-Entwicklungsumgebung, die auch die dynamischen Aspekte einer Web-Anwendung möglicherweise graphisch interaktiv modellierbar und implementierbar machen würde. Also eine Möglichkeit, eine Folge von Dialogschritten, die sich über mehrere WWW-Seiten erstreckt, als eine in sich geschlossene Transaktion zusammenzufassen. Damit würden sich die Möglichkeiten eröffnen, Anwendungen unabhängig von den Einschränkungen zu entwickeln, die derzeit noch von den Standards wie HTML und HTTP verursacht werden [Assfalg et al. 1998].
     
     

    15. Glossar

     
    Begriff Bedeutung
    ADO ActiveX-Data-Objekt 
    Objekte, die im ASP-Umfeld zur Verfügung stehen und den Zugriff auf die Datenbankumgebung zur Verfügung stellen
    API Application Programming Interface
    ASP Active Server Page 
    Mit dem Internet Information Server ausgelieferte Programmierumgebung, die es u. a. ermöglicht, datenbankgestützte Web-Seiten zu erstellen
    Cartridges Cartridges sind Objekte oder Komponenten, die über den OAS zum Einsatz kommen.
    CGI  Common Gateway Interface 
    COM Component Object Model 
    Cookies Cookies sind Kennungen, welche Server im Zuge der Navigation den anfragenden Clients mitteilen. Ihre Gültigkeit kann sich über ganze URL-Pfadbereiche erstrecken oder auf ganz bestimmte URLs eingeschränkt sein. Auf Seiten des Servers werden Cookies in den HTTP-Header des an den Client zu übertragenen Dokumentes eingebettet.
    CORBA Common Object Request Broker Architecture 
    DataBlades Software-Module, die die Leistungsfähigkeit des Datenbankservers um ein bestimmtes Anwendungsgebiet erweitern.
    Datenbank Eine Datenbank ist eine integrierte Ansammlung von Daten, die allen Benutzern eines Anwendungsbereiches als gemeinsame Basis aktueller Informationen dient [Schlageter et al. 1999].
    DBMS Database Management System 
    Das Datenbankmanagementsystem ist ein Softwaresystem, das es ermöglicht, eine Datenbank zu definieren, Daten zu speichern, zu verändern und zu löschen, so wie Anfragen an die Datenbank zu stellen [Schlageter et al. 1999].
    DBS Database System 
    Datenbank und Datenbankmanagementsystem bilden zusammen ein Datenbanksystem [Schlageter et al. 1999]
    DCOM Distributed COM 
    DNS Domain Name Services
    Firewall Firewalls sind Schutzmaßnahmen auf Hard- oder Softwareebene, die ein lokales Netz entweder vor Zugriffen schützen oder diese zumindest aufzeichnen.
    Funktionsbaustein Innerhalb des Systems SAP R/3 werden allgemein verwendbare Funktionen als sogenannte Funktionsbausteine entwickelt und gespeichert. Diese stehen dann in der kompletten Entwicklungsumgebung zur Nutzung zur Verfügung.
    Groupware Sammelbegriff für alle Programme, die die Zusammenarbeit von Arbeitsgruppen in einem Netzwerk erlauben und erleichtern
    ID-Datei Eindeutige Identifikationsdatei für jeden Nutzer von Lotus Notes, versehen mit einem Passwort
    HTML Hypertext Markup Language 
    HTML ist eine Sprache zur Strukturierung von Hypertext-Dokumenten.
    HTTP Hypertext Transfer Protocol 
    Das HTTP-Protokoll definiert den Datentransfer zwischen WWW-Browsern und WWW-Servern.
    HTTP-Server Web-Server, der die HTTP-Anfragen eines Clients bedienen kann. 
    IDC Internet Database Connector 
    Bestandteil des Internet Information Servers, der es ermöglicht vom Web-Server aus auf Datenbanken zuzugreifen.
    IIOP Internet Inter-ORB Protocol 
    IIS Internet Information Server 
    Web-Server der Firma Microsoft.
    ITS Internet Transaction Server 
    Komponente, um für das System SAP R/3 eine Verbindung zu einem Web-Server zu schaffen.
    JDBC Java Database Connectivity
    JScript Java Script 
    Skriptsprache zu Java
    LDAP Lightweigt Directory Access Protocol 
    Legace-Systeme Bereits vorhandene Systeme, z. B. Mainfraim-Systeme 
    OAS Oracle Application Server 
    ODBC Open Database Connectivity 
    ODBC ist eine Standardschnittstelle, die den Zugriff auf Datenquellen ohne Kenntnis der jeweiligen genauen Arbeitsweise gewährt.
    OLE Object Linking and Embedding
    OLTP Online Transaction Processing
    OMG Object Management Group
    ORB Object Request Broker 
    POP Post Office Protocol
    Report-Generator Softwareprodukt, das es ermöglicht ohne Programmierkenntnisse die Inhalte von Datenbanken auszuwerten. Die Erstellung von Auswertungen und die Formatierung des Ergebnisses ist von der Oberfläche gesteuert. Lediglich die Kenntnisse über den Aufbau der Datenbanken und die Verknüpfung der Datenbanken untereinander werden vom Nutzer benötigt.
    Request (Datenbank-) Anfrage
    Skripts Skripts werden eingesetzt, um bestimmte automatisierte Aufgaben zu übernehmen.
    SSL Secure Socket Layer 
    Sicherheitsprotokoll
    Transaktion Eine Transaktion ist eine Folge von Datenverarbeitungsbefehlen, die die Datenbasis von einem konsistenten Zustand in einen anderen - nicht notwendigerweise unterschiedlichen - konsistenten Zustand überführt [Kemper et al. 1997].
    Trigger Ein Trigger ist eine benutzerdefinierte Prozedur, die automatisch bei der Erfüllung einer bestimmten Bedingung vom DBMS gestartet wird. Denkbar sind neben Überprüfungsfunktionen auch Berechnungsfunktionen.
    Variante Innerhalb des SAP R/3 Systems können zu Programmen sogenannte Varianten gepflegt werden. Varianten haben einen Namen und erlauben die Speicherung von festen Anfragemöglichkeiten innerhalb des zughörigen Programms. Dazu können mögliche Werte des Selektionsbildschirms gespeichert werden.
     
     

    16. Literaturverzeichnis

    [Assfalg et al. 1998]
    Rolf Assfalg, Udo Goebels, Heinrich Welter, Internet-Datenbanken, Konzepte, Modelle, Werkzeuge, Addison-Wesley, Bonn 1998

    [Axt et al. 1999]
    Heiko Axt, Matthias  Hertel, Martin Wagner, Lotus Domino und Notes 5, Markt & Technik, München 1999

    [ColdFusion 1998]
    Allaire Corporation, ColdFusion 4.0-Informationsbroschüre, 1998

    [ColdFusion 1999]
    Info zu ColdFusion, http://www.dli.de/cfdocs/user/ug020001.htm

    [Denning et al. 1997]
    Jens Denning, Klaus Gutperlet, Eike G. Rosenow, Lotus Domino & Notes 4., Markt & Technik, München 1997

    [Dierker et al. 1999]
    Markus Dierker, Martin Sander, Lotus Notes 4.6 und Domino, Addison-Wesley, Bonn 1998

    [Fochler et al. 1998]
    Klaus Fochler, Primoz Perc, Jörg Ungermann, Lotus Domino 4.6, Addison-Wesley, Bonn 1998

    [GDIdb]
    http://www.gdidb.com

    [Greenspun 1998]
    Philip Greenspun, Datenbankgestützte Web-Sites, Hanser, München 1998

    [Gunderloy et al. 1999]
    Mike Gunderloy, Mary Chipman, MS SQL Server 7, Planung, Installation, Konfiguration und Optimierung, Sybex Verlag, Düsseldorf 1999

    [Heede 1998]
    Dirk Heede, Evaluierung kommerzieller Volltext-Datenbanksysteme, Diplomarbeit, Uni Leipzig, 1998

    [Kemper et al. 1997]
    Professor Alfons Kemper, Ph. D. Dipl.-Inform. André Eickler, Universität Passau, Datenbanksysteme, Eine Einführung, R. Oldenburg Verlag, München 1997

    [Krause 1999]
    Jörg Krause, MS SQL Server 7.0 im Webserver, Datenbankgestützte Websites mit SQL und Active Server Pages, Hanser, München 1999

    [LDAP 1999]
    http://www.t-lan.de/GLOSSAR/BEGRIFFE/LDAP.htm

    [Oracle 1998]
    Oracle Corporation, Die richtigen Verbindungen ins nächste Jahrtausend, White Paper, 1998

    [Petkovic 1997]
    Dusan Petkovic, INFORMIX Universal Server, Das objekt-relationale Datenbanksystem mit Online-XPS und ODS, Addison-Wesley, Bonn 1997

    [Reibold 1999]
    Holger Reibold, Datenbankanbindung mit ColdFusion 4.0, ZDNet, 1999, http://www.zdnet.de/internet/artikel/java/199907/coldfusion_00-wc.html

    [Rudat 1999]
    Ulf Rudat, Moderne Anwendungsintegration in heterogenen IT-Welten, Integrata-Training, 1999

    [SAP]
    Diverse Adressen innerhalb der Internet-Seiten der SAP-AG (http://www.sap-ag.de) und des SAP-Nets (http://www-sapnet.de), insbesondere auch http://www.sap-ag.de/germany/products/r2/software/webrfc/s45teil2.htm

    [Schlageter et al. 1999]
    Gunter Schlageter, Wolfgang Wilkes, Michael Balzer, Datenbanksysteme, FernUniversität Hagen 1999

    [Schroeter et al. 1998]
    Uwe Schröter, Stephan Fügner, Das Domino Prinzip, dpunkt – Verlag für digitale Tontechnologie GmbH, Heidelberg 1998

    [Shelly Power et al. 1998]
    Shelly Powers et al., Dynamic Web Publishing, SAMS (Imprint von Markt & Technik Verlag), München 1998

    [Wagenknecht 1999]
    Achim Wagenknecht, Schnappschuß ins Web, Heft 11, c’t 1999
     

    Fast alle Hard- und Softwarebezeichnungen, die in diesem Beitrag erwähnt werden, sind gleichzeitig auch eingetragene Warenzeichen. Alle Rechte vorbehalten.

    Zurück zur Startseite

    copyright 2000, Nicole RichterGabriele Hawlena
    16.02.00/Rev.00