Das Aufkommen von Client/Server-Anwendungen ermöglichte es Anwendungsentwicklern, die Benutzerfreundlichkeit zu verbessern un die Schulungskosten zu reduzieren, indem Anwendungen mit grafischen Benutzerschnittstellen auf Plattformen wie beispielsweise Windows und OS/2 zur Verfügung gestellt wurden. Gleichzeitig ermöglichten diese Anwendungen die Flexibilität, Datenbankverwaltungsfunktionen an zuverlässige Datenbank-Server unter einer Vielzahl von Betriebssystemen und auf verschiedenen Hardwareplattformen zu delegieren.
Das Client/Server-Modell, bei dem die Anwendungslogik an Client-Workstations verteilt wird, wird im allgemeinen als zweischichtiges Client/Server-Modell bezeichnet. In dem zweischichtigen Modell wird die Anwendung in der Client-Schicht implementiert und der Datenbank-Server implementiert den Server oder die Back-End-Schicht. Wie in Direkter Datenbankzugriff bereits erwähnt, bietet DB2 Connect vollständige Unterstützung für zweischichtige Client/Server-Anwendungen, wobei es sich bei den Datenbank-Servern um DB2 für OS/390, DB2 für MVS/ESA, DB2/400 oder DB2 für VM und VSE handelt.
Mit der zunehmenden Größe der Client/Server-Anwendungen wurde deutlich, daß das zweischichtige Client/Server-Modell beträchtliche Einschränkungen aufweist. Das Verteilen von umfangreicher Geschäftslogik an Hunderte oder sogar Tausende von Client-Workstations machte die Änderungsverwaltung zu einer komplexen und kostspieligen Aufgabe. Bei jeglichen Änderungen an den Geschäftsregeln wurde es erforderlich, den Client-Teil der Anwendung zu ersetzen. Häufig mußten diese Verteilungen von Anwendungen auf allen Client-Workstations des Unternehmens gleichzeitig erfolgen, um zu gewährleisten, daß die Geschäftsregeln konsequent angewandt werden.
Eine weitere Unzulänglichkeit des zweischichtigen Client/Server-Modells, die mit zunehmender Größe deutlich wurde, besteht in der Menge der Ressourcen, die von solchen Anwendungen verbraucht werden. Das Implementieren Hunderter oder Tausender Fat Clients, wie zweischichtige Clients häufig genannt werden, erhöhte auf allen Client-Workstations den Bedarf an Verarbeitungsleistung und -kapazität. Des weiteren werden auch die Anforderungen an den Datenbank-Server stark erhöht, da jeder Client eine dedizierte Datenbankverbindung erfordert sowie die entsprechenden Ressourcen für die Aufrechterhaltung einer solchen Verbindung. Obwohl die Abhängigkeit des zweischichtigen Client/Server-Modells von der Verteilung der Geschäftslogik in gewissem Maße durch die weitreichende Verwendung gespeicherter Prozeduren reduziert werden kann, lassen sich die anderen Unzulänglichkeiten nicht so einfach beheben, ohne Änderungen an dem Modell vorzunehmen.
Im Zuge der ausufernden Kosten und Komplexität der zweischichtigen Client/Server-Anwendungen ging die Entwicklung der meisten der größten Anwendungen in Richtung mehrschichtiger Client/Server-Modelle. Im Rahmen des mehrschichtigen Modells bleibt die Rolle der Datenbankschicht unverändert. Die Client-Schicht wird jedoch durch eine oder mehrere Mittelschicht(en) ergänzt. Meistens handelt es sich jedoch um eine Schicht; daher auch die Bezeichnung dreischichtig.
Im dreischichtigen Modell dient der Client lediglich noch zur Verarbeitung von Benutzerinteraktionen und enthält keine Geschäftslogik. Die Mittelschicht besteht aus einem oder mehreren Anwendungs-Server(n). Die Aufgabe des Anwendungs-Servers besteht darin, eine zuverlässige, kostengünstige Implementierung der den Geschäftsprozessen und Geschäftsregeln zugrundeliegenden Logik zur Verfügung zu stellen. Wie bereits beim zweischichtigen Modell wird die Implementierung der Geschäftsregeln häufig durch die Verwendung von gespeicherten Prozeduren ergänzt, um die Leistung zu verbessern.
Da die Client-Workstations nicht mehr die umfangreiche Anwendungslogik implementieren, sondern lediglich noch die Benutzerinteraktionen verarbeiten, ist der Ressourcenbedarf der Client-Schicht weitaus geringer. Daraus folgt, daß die Client-Schicht im dreischichtigen Modell häufig als Thin Client bezeichnet wird. Da ein zentraler Anwendungs-Server Anforderungen von allen Clients verarbeitet, kann er darüber hinaus Ressourcen wie beispielsweise Datenbankverbindungen mit allen Clients gemeinsam benutzen. Daher muß der Datenbank-Server nicht mehr für jeden Anwendungsbenutzer eine dedizierte Verbindung verwalten.
In der Industrie gibt es heute viele Beispiele für dreischichtige Anwendungs-Server. Fast alle ERP-Lieferanten (Enterprise Resource Planning; Unternehmensressourcenplanung) implementieren ihre Anwendungen mit Hilfe des dreischichtigen Modells wie beispielsweise SAP R/3- und PeopleSoft V7-Anwendungen. Weitere Beispiele umfassen ERM-Lieferanten (Enterprise Relationship Management, Unternehmensbeziehungsverwaltung) wie beispielsweise Siebel und Vantive.
DB2 Connect Enterprise Edition-Server bieten umfangreiche Unterstützung für die Implementierung mehrschichtiger Anwendungen. Die Unterstützung durch DB2 Connect umfaßt eine Reihe unterschiedlicher APIs zur Entwicklung von Anwendungslogik (ODBC, ADO, DB2 CLI, Eingebettetes SQL, JDBC und SQLJ) sowie eine vollständige Kommunikationsinfrastruktur zur Interaktion mit Datenbank-Servern aus der DB2-Produktfamilie.
DB2 Connect unterstützt auch Implementierungen, in denen sich eine Datenbankschicht aus mehreren Datenbank-Servern der DB2-Produktfamilie zusammensetzt. Dadurch können Anwendungs-Server Transaktionen implementieren, mit deren Hilfe sich die Daten auf mehreren Datenbank-Servern durch eine einzige Transaktion aktualisieren lassen.
Die Integrität solcher verteilten Transaktionen wird durch das von DB2 Connect unterstützte Protokoll der zweiphasigen Festschreibung gewährleistet. Beispielsweise kann eine Anwendung innerhalb derselben Transaktion Daten in einer Datenbank unter DB2 für OS/390 und unter DB2 UDB auf Windows NT aktualisieren. Wenn Unterstützung für verteilte Anforderungen installiert und aktiviert wird, kann die Anwendung innerhalb derselben Transaktion eine Oracle-Datenbank lesen und eine Datenbank aus der DB2-Produktfamilie aktualisieren.
Im folgenden Diagramm werden sowohl die APIs als auch der Konnektivitätsmechanismus zwischen dem Anwendungs-Server und den Back-End-Datenbank-Servern von DB2 Connect Enterprise Edition zur Verfügung gestellt.
Die erweiterten Funktionen von DB2 Connect wie beispielsweise der Verbindungszusammenschluß (siehe Verbindungszusammenschluß) und der Verbindungskonzentrator (siehe DB2 Connect - Verbindungskonzentrator) sorgen für eine beträchtliche Reduzierung des Bedarfs an Anwendungsressourcen und eine vereinfachte Implementierung der Anwendungs-Server.
Für die Verwendung mit Anwendungs-Servern ist DB2 Connect Enterprise Edition erforderlich. Dieses Produkt ist eigenständig erhältlich oder als Teil des Produktpakets von DB2 Connect Unlimited Edition. DB2 Connect Personal Edition wird nicht unterstützt und ist für die Verwendung mit Anwendungs-Servern nicht lizenziert. Kunden, die Anwendungs-Server implementieren, sollten darüber hinaus die mit ihrem DB2 Connect-Exemplar gelieferten Vertragsbedingungen überprüfen, um zu ermitteln, wieviele Benutzerlizenzen erworben werden müssen.
Für die Implementierung von DB2 Connect in der Anwendungs-Server-Umgebung stehen zwei Methoden zur Verfügung. Installation von DB2 Connect Enterprise Edition auf:
In den meisten Fällen wird eine Kopie von DB2 Connect vorzugsweise auf demselben Server installiert wie der Anwendungs-Server selbst. Die Installation von DB2 Connect auf dem Anwendungs-Server ermöglicht die Teilnahme an Systemen für Funktionsübernahme und Lastausgleich, die der Anwendungs-Server möglicherweise implementiert. Diese Konfiguration bietet potentiell eine bessere Leistung, da ein zusätzlicher Zwischenschritt im Netz eliminiert wird, der erforderlich wird, wenn DB2 Connect auf einem anderen Server installiert ist. Des weiteren kann die Verwaltung vereinfacht werden, da kein zusätzlicher Server installiert und verwaltet werden muß.
Die Installation von DB2 Connect auf einem anderen Server ist dann eine gute Lösung, wenn DB2 Connect Enterprise Edition nicht für das Betriebssystem bzw. die Hardwareplattform zur Verfügung steht, unter dem bzw. auf der der Anwendungs-Server ausgeführt wird. Beispiel: Wenn der Anwendungs-Server auf einem Silicone Graphics (SGI)- oder SCO UnixWare-Server implementiert ist, kann DB2 Connect nur auf einem anderen Server implementiert werden, da DB2 Connect Enterprise Edition für diese Plattformen nicht verfügbar ist.