Melden Sie sich hier an, um auf Kommentare und die Whitepaper-Datenbank zugreifen zu können.

Kein Log-In? Dann jetzt kostenlos registrieren.

Falls Sie Ihr Passwort vergessen haben, können Sie es hier per E-Mail anfordern.

Der Zugang zur Reseller Only!-Community ist registrierten Fachhändlern, Systemhäusern und Dienstleistern vorbehalten.

Registrieren Sie sich hier, um Zugang zu diesem Bereich zu beantragen. Die Freigabe Ihres Zugangs erfolgt nach Prüfung Ihrer Anmeldung durch die Redaktion.

06.12.1996 - 

Wachsende Bedeutung für Middleware

Bei Client-Server setzt sich dreistufige Architektur durch

CW: Welche Trends sehen Sie beim Client-Server-Computing, und wie reagieren Sie als Anbieter von Middleware-Produkten darauf?

SIPPL: Wir sehen eine rasche Durchsetzung von Three-tier- Architekturen. Geschäftsregeln kommen zukünftig immer mehr weg vom fetten Client und von Datenbanken, auf denen sie im proprietären Format von Stored Procedures hinterlegt werden. Diese Konstellation war typisch für die erste Generation von Client-Server. Die Business-Logik wird statt dessen in gängigen Programmiersprachen implementiert und wandert ab zu offeneren Applikations-Servern, die den Middle-tier der dreischichtigen Architektur repräsentieren.Eine Umwälzung, die relationale Datenbanken in den siebziger Jahren brachten, bestand vor allem darin, daß sie Anwendern eine Daten-Schnittstelle boten. Ein relationales Datenbank-Management-System (RDBMS) macht Tabellen und Attribute über Namen ansprechbar, so daß beliebige Tools und Programme in der Lage sind, Datensätze zu lesen, zu ändern und zu schreiben. Object Request Broker (ORB) bieten nun innerhalb von dreistufigen Anwendung den Zugang zu Daten über Applikations-Schnittstellen an.

CW: Wird der Trend zu Three-tier-Anwendungen durch den Erfolg des Internet beschleunigt?

SIPPL: Ja, fette Clients sind wirklich nicht für das Internet geeignet. Außerdem wird dort noch schneller offensichtlich, daß die zweischichtigen Client-Server-Anwendungen der ersten Generation schlecht skalierbar sind.Es war von Anfang an keine besonders gute Idee, die ganzen SQL-Daten über das Netz hin- und herzuschicken. Die Logik gehört auf die Seite des Netzwerks, dorthin wo die Daten sind: Entweder gleich mit der Datenbank auf dieselbe Maschine oder zumindest hinter die Firewall, wo Applikationen und Daten über Hochleistungsnetzwerke verbunden werden. Das ist übrigens die Art und Weise, wie große Client-Server-Anwendungen, darunter beispielsweise R/3 von SAP, schon länger funktionieren. Dieses Modell setzt sich jetzt generell durch.

CW: Das Web bietet selbst eine dreistufige Architektur an, in der der Web-Server inklusive Erwei- terung - beispielsweise in Form von Common-Gateway-Interface-(CGI-)Scripts - die mittlere Schicht repräsentiert. Wie sehen Sie die Zukunft des Web als Applikationsplattform, insbesondere da ja Net- scape in die nächste Version des Browsers Visigenics ORB "Visibroker für Java" integrieren wird?

SIPPL: Das Hypertext Transfer Protocol (HTTP) hat auch weiterhin eine Berechtigung. Es wird sich allerdings auf das Browsen durch Hypertexte beschränken. Wenn Anwender für geschäftliche Zwecke Verbindung zu einem Server aufnehmen, dann werden sie dies zukünftig über Java-Applets tun, die IIOP-Nachrichten über das Netz schicken. Kurz gesagt: HTTP ist für das Browsen im Web, das Internet Inter-ORB Protocol für Business.

CW: Der von Ihnen gegründete Datenbankhersteller Informix propagiert die Datablade-API, mit der Applikationen auf den SQL-Server aufgepfropft werden. Läuft dieser Ansatz nicht dem allgemeinen Trend zu eigenständigen Applikations-Servern entgegen?

SIPPL: Bei den Datablades handelt es sich nicht um Applikationen, die typischerweise auf dem Middle-tier Platz finden müssen.

Die Datablades erweitern die Datenbank um generische Fähigkeiten. Es wird kaum jemand einfallen, eine Auftragsverwaltung als eine Sammlung von Datablades zu implementieren. Eine Sonderstellung könnte höchstens das geplante Datablade für Java bekommen.

CW: Die Applikationslogik auf dem Middle-tier steht nicht nur in Kontakt mit den Clients, sondern wird durch die Verknüpfung mehrerer Applikations-Server beliebig erweiterbar. Werden solche verteilten Business-Objekte nicht sehr schwer zu verwalten sein?

SIPPL: Wenn verteilte Business-Objekte zusammen die Applika- tion repräsentieren, dann wird Scott McNealys Lieblingsspruch "The Network is the Computer" Realität. Kurz nachdem ich 1983 Informix gegründet hatte, fragten unsere Kunden nach Tools, mit denen sie das Verhalten der Datenbank steuern und Problemen auf die Spur kommen können.Solche Werkzeuge brauchen wir nun auch für verteilte Anwendungen. Bestehende System-Management-Produkte messen beispielsweise den TCP/IP-Verkehr im Netz, können aber keine Auskunft darüber geben, welche Belastung durch welche Anwendungen entstehen.

Derartige Überwachungsfunktionen für die Entwicklung, Verteilung und Anpassung von Applikationen eröffnen uns als Hersteller einen riesigen Markt. Sie werden eine zentrale Rolle beim Three-tier-Computing spielen, entweder als Stand-alone-Produkte oder als Agents in System-Management-Frameworks.

CW: Visigenic machte sich einen Namen als Hersteller von ODBC-Treibern, vor allem auch für Unix und den Apple Macintosh. Andererseits haftete der Microsoft-Technik lange der Ruf an, daß sie nur für den Desktop konzipiert sei. Welche Folgen hat nun die Durchsetzung einer Three-tier-Architektur für Open Database Connectivity (ODBC)?

SIPPL: Mit der Version 3.0 entwickelt sich ODBC allmählich zu einer ernstzunehmenden Middleware. Das Desktop-Image dieser Treiberarchitektur kommt aber nicht von ungefähr. Ihre Einführung war für Microsoft der bequemere Weg: Oracle oder Informix konnten zu dieser Zeit bereits Client-seitige APIs vorweisen, die Gates-Company hingegen hatte diesbezüglich kaum Know-how und wollte dafür keinen Aufwand treiben. Mit ODBC endete die Schnittstelle zu den Datenbanken am Desktop. Microsoft überließ es dem Anwender, sich mit der Verwaltung und Verteilung der verschiedenen ODBC-Treiber auf den PCs herumzuschlagen.

Unsere Treiber finden mittlerweile Einsatz auf Servern mit hohem Transaktionsaufkommen. Oracle nutzt unsere ODBC-Produkte für Datenbank-Gateways. Die Tatsache, daß die Treiber auf der Server-Seite laufen, hat jedoch weniger mit ODBC 3.0 zu tun als vielmehr mit unserer Implementierung in "Visichannel". Sie erlaubt eine einfachere Verwaltung: Anstatt auf dem Client zwanzig verschiedene ODBC-Treiber einzurichten, kommt dort nur ein einheitlicher Treiber zum Einsatz, der mit den ODBC-Treibern auf dem Server kommuniziert. Beim Update eines Datenbanksystems ändert sich folglich nur der Treiber auf dem Server, am Client ist nichts anzupassen. So hätte ODBC von Anfang an funktionieren sollen.

CW: Microsoft favorisiert mittlerweile OLE DB als Nachfolger von ODBC. Macht das nicht all Ihre ODBC-Fortschritte zunichte?

SIPPL: Keineswegs. Die eben beschriebene Architektur von Visichannel erlaubt uns, die Server-seitig installierten Treiber zur Client-Seite hin um verschiedene Schnittstellen zu ergänzen. Das gilt für OLE DB genauso wie für Java Database Connectivity (JDBC).Im Falle von Java können wir entweder einen JDBC-Treiber nehmen, der auf der Visichannel-Client-Software aufsetzt, oder wir entwickeln ihn neu in Java und lassen ihn über den ORB mit dem ODBC-Treiber auf dem Server kommunizieren.

Ähnlich verhält es sich mit OLE DB. Wir geben Visual-Basic- oder C++-Programmierern eine Schnittstelle für OLE-Automation auf der Client-Seite. Die wirklich harte Arbeit, nämlich die Übersetzung der Client-Calls auf die API der jeweiligen Datenbanken, haben wir bereits geleistet. Ein weiterer Vorteil dieser Lösung besteht darin, daß Anwender nicht darauf warten müssen, bis ihre Datenbanken OLE DB unterstützen: Wir bieten ihnen diese Schnittstelle einheitlich für alle Hersteller an.

Mittelfristig Übergang zu N-tier-Architekturen

Eine Studie der Meta Group geht davon aus, daß die meisten Anwender von Two-tier-Applikationen damit beschäftigt sind, diese auf eine mehrstufige Architektur zu überführen. Auschlaggebend dafür ist der Wunsch nach besserer Skalierbarkeit.

Dies betrifft typischerweise Software, die mit Werkzeugen wie Visual Basic, Borland Delphi oder SQL Windows erstellt wurde. Die bisherige Form der Datenbankanbindung erfordert allerdings größere Umbauten, bei denen die Produktivitätsvorteile dieser visuellen Tools verlorengehen.

Trotz dieses Trends zu verteilten Anwendungen verlieren die herkömmlichen Two-tier-Tools nicht an Bedeutung. Die amerikanischen Marktforscher erklären dies damit, daß der Umstieg zu mehrstufigen Anwendungen nur schrittweise erfolgen und vorerst nur solche auf Enterprise-Level betreffen wird. Die Studie gesteht nämlich zweischichtigen Client-Server-Applikationen bis zu 150 Benutzern ausreichende Leistungsfähigkeit zu. Darüber hinaus bieten Stored Procedures die Möglichkeit, Datenbankzugriffe zu optimieren und so Performance-Einbrüche von SQL Servern abzufangen.

Dieser Ansatz ist allerdings auf Benutzerzahlen bis zu 500 beschränkt. Anwender müssen dann die Applikationslogik auf eigene Server auslagern, die sie entweder in 3GL-Sprachen oder in High-end-4GL-Tools entwickeln. Mit bis zu dreimal höheren Umsätzen können demnach die Anbieter von 4GL-Client-Server-Tools der gehobenen Kategorie schon 1997 rechnen: Betroffen sind Produkte wie Forte oder Natstar, die schon länger die Möglichkeit für N-tier-Applikationen anbieten.

Begünstigt durch den Trend zu verteilten Anwendungen wird auch die Nachfrage nach Middleware-Produkten wie Datenbank-Gateways, Messaging- und Queuing-Tools oder Object Request Brokern (ORBs). Letztere sehen die Marktforscher für die nächste Zukunft auf den Einsatz für Web-basierte Transaktionen beschränkt. Sie begründen deren bisher schwache Akzeptanz mit in der Vergangenheit schlecht definierten Standards, geringer Verbereitung von Know-how über Design solcher Awendungen und dem Mangel an Object Transaction Services, die von den meisten Anbietern erst kürzlich implementiert wurden.

Die Three-tier-Architektur des Web selbst eignet sich wie die herkömmlichen Tools vor allem für Workgroup-Anwendungen.