Transaktionsmonitore und Applikationsserver

Transkript

1 Transaktionsmonitore und Applikationsserver Marc Monecke Praktische Informatik Fachbereich Elektrotechnik und Informatik Universität Siegen, D Siegen 13. Juni 2003 Zusammenfassung Geschäftsanwendungen sind große, oft verteilte Informationssysteme mit einer großen Zahl von Benutzern, heterogenen Datenverwaltungssystemen und strengen Anforderungen an Geschwindigkeit, Sicherheit und Verfügbarkeit. In dieser Vorlesung geht es um die Frage, wie solche Anwendungen technische realisiert werden können, und welche Basistechnologien dem Anwendungsentwickler die Arbeit erleichtern. Inhaltsverzeichnis 1 Motivation Anforderungen an die Entwicklung von Geschäftsanwendungen Implementierung von Geschäftsanwendungen Einfacher Ansatz Modulare Anwendung Kommando-Interpreter WWW-Schnittstelle Zentraler Applikationsprozeß Beispiel: Java Servlets und JSP Servlets Java Server Pages (JSP) Fortgeschrittene Technologien für Geschäftsanwendungen Transaktionsmonitore (TP-Monitore) Object Request Broker (ORB) Komponenten-Transaktionsmonitore Serverseitige Komponenten Schichten-Architektur Zusammenfassung 8 1

2 1 Motivation Merkmale von Geschäftsanwendungen: große Informationssysteme große Anzahl Benutzer ( ) überwiegend Datenabfrage einzelne Dateneingaben, kurze Interaktionssequenzen räumliche Verteilung: ein oder mehrere Server und viele Klienten an unterschiedlichen Standorten oft WWW-Schnittstelle Daten in mehreren, heterogenen Datenbanken gespeichert Stichwort: OLTP: On-line transaction processing 1.1 Anforderungen an die Entwicklung von Geschäftsanwendungen Bei der Entwicklung von Geschäftsanwendungen müssen viele Anforderungen berücksichtigt werden, die bei einfachen Anwendungen nicht oder nur teilweise auftreten: Mehrbenutzerfähigkeit: mehrere Benutzer arbeiten gleichzeitig Mehrprozeß-Fähigkeit (Verteilung der Anfragen und Arbeitsaufträge auf mehrere unabhängige Prozesse) Transaktionen (Kontrolle des parallelen Zugriffs auf gemeinsame Ressourcen) Benutzerverwaltung (Verwaltung von Benutzern, Benutzergruppen und ihren Rechten) Sicherheit (Zugriffsschutz, Verschlüsselung, Schutz vor Eindringlingen) Netzwerkfähigkeit (Zugriff auf die Anwendung über das Inter-/Intranet; Zugriff auf Ressourcen im Netz) Skalierbarkeit: Anpassung an wachsende Benutzerzahlen oder Datenmengen; dazu Verteilung auf mehrere Rechner ermöglichen Verfügbarkeit: Migration von Anwendungen ohne großen Aufwand auf anderen Rechner, falls der ursprüngliche ausfällt Netzanbindung: Zugriff auf die Anwendungen über das Internet möglich, etwa für Vertreter, Heimarbeiter oder Kunden Integration: Teile der Anwendung sollen separat als Bausteine des Gesamtsystems nutzbar sein; Zugriff auf Altsysteme muß möglich sein Kurze Entwicklungszyklen: Verteilte Entwicklung einzelner kleinerer Bausteine der Anwendung, die nachher zusammengesetzt werden Konfigurierbarkeit: Anpassung der Anwendung an unterschiedliche Anforderungen ohne Änderung des Quelltextes und Neuübersetzung Schrittweise Migration: Komplexe Unternehmensanwendungen werden meist in kleinen Schritten umgestellt Datenverwaltung: Anwendung muß auf Altdatenbestände zugreifen können und sollte unabhängig vom verwendeten Datenverwaltungssystem (DVS etwa bestimmtes Datenbank-Managementsystem) sein 2

3 Hersteller- und Programmiersprachen-Unabhängigkeit dies ist gerade im Hinblick auf die meist hohe Lebenserwartung von Geschäftsanwendungen wichtig, die leicht die Lebenserwartung einzelner Hersteller oder die Blütezeit einer Programmiersprache überdauern kann. 2 Implementierung von Geschäftsanwendungen 2.1 Einfacher Ansatz Ein Programm enthält GUI und Geschäftslogik, läuft auf Klientenrechner DBMS läuft in separatem Prozeß auf Server-Rechner (Abbildung 1) Nachteile: aufwendige Installation, Wartung, Konfiguration auf Klienten hoher Ressourcenbedarf auf Klientenrechnern teure Hardware viele Netzwerk-Verbindungen zwischen Klienten und Server, da während der gesamten Zeit, in der eine Anwendung läuft, die Verbindung bestehen bleibt. Die Zahl der gleichzeitig aktiven Netzwerkverbindungen ist aber stets durch das Betriebssystem begrenzt. Klient Server Anwendung DBMS Netzwerk Verbindung Abbildung 1: Einfache Architektur 2.2 Modulare Anwendung Anwendung besteht aus n einzelnen Programmen jedes implementiert einzelnen Dialog oder Teilfunktion Vorteile: geringerer Ressourcenbedarf, da einzelne Programme kleiner Anpassung des Funktionsumfangs für jeweiligen Klienten möglich geringere Anzahl Netzwerkverbindungen, da jeweils nur für aktives Teilprogramm geöffnet Nachteile: für jeden Dialogschritt wird ein Prozeß gestartet jeweils Verbindung zur Datenbank aufbauen bei jedem Programmaufruf Authentifizierung nötig Interaktionszustand (Benutzer-Identifikation, zuletzt ausgeführte Schritte) bleibt nicht erhalten 3

4 2.3 Kommando-Interpreter bietet dem Anwender relevante Funktionen der Anwendung an Bedienung über Menüs oder Kommandos wird auf Server ausgeführt 1 Prozeß pro Sitzung Ablauf: 1. Verbindungsaufbau zum Server 2. Identifikation und Authentifizierung des Benutzers 3. Schleife: Funktion auswählen Parameter in Dialog oder Maske eingeben Funktion ausführen (Datenbank-Zugriffe) Ergebnis anzeigen 4. Abmelden Sitzungsende Vorteile: Sitzungsbegriff, Interaktionskontext bleibt erhalten Sitzungen werden automatisch vom Interpreter verwaltet nur einmal authentifizieren Nachteile: hohe Serverlast, weil zahlreiche, lange laufende Prozesse gleichzeitig existieren große Zahl offener Verbindungen zwischen Klienten und Server, bleiben während gesamter Sitzung offen Grenze bei 10 bis 100 parallelen Sitzungen 2.4 WWW-Schnittstelle GUI durch Browser realisiert Anwendung mit Geschäftslogik läuft auf dem Server Anwendung muß auch HTML-Seiten für das GUI generieren verschiedene Realisierungsalternativen (CGI, Applets... ) Vorteile: geringer Administrationsaufwand und Ressourcenbedarf bei den Klienten (Browser genügt) Klienten hersteller- und plattformunabhängig Nachteile: HTTP ist zustandslos Sitzungen müssen von der Anwendung realisiert werden (Cookies, URL rewriting, versteckte Werte) vgl. Vorlesung zu Servlets in ST II viele Server-Prozesse bei zahlreichen parallelen Klienten hohe Server-Last 2.5 Zentraler Applikationsprozeß besser: ein physischer Applikationsprozeß, simuliert mehrere logische Applikationsprozesse 4

5 Funktionen sind für alle Klienten gleich nur ein Programm nötig bei Anbindung an HTTP-Server: Verbindungen zwischen Klienten und HTTP-Server nur während der Datenübertragung aufgebaut nur eine Verbindung zwischen HTTP-Server und Applikationsprozeß interne Verwaltung der Zustände einzelner logischer Applikationen aufwendig: ankommende Dienstaufrufe verwalten und seriell abarbeiten oder jeweils thread für logische Applikation grundlegende Dienste wie internes Prozeßkonzept, Session-Verwaltung, Sicherheitsmechanismen nötig Verwaltungsprozeß für beliebige Applikationen: Applikationsserver 2.6 Beispiel: Java Servlets und JSP Java-Technologien wie Servlets und JSP können genutzt werden, um Geschäftsanwendungen auf Basis eines Applikationsservers zu realisieren. Allerdings werden von diesen Technologien nur wenige Basisdienste angeboten der Anwendungsentwickler muß also z.b. selbst für die Authentifizierung der Anwender und die persistente Datenverwaltung sorgen Servlets Servlets sind serverseitige Komponenten, die den HTTP-Server erweitern werden von Servlet-Container verwaltet, der an den HTTP-Server angebunden wird Klient Server Servlet Container Web Browser HTTP HTTP Server Servlet Abbildung 2: Servlets Schnittstelle zwischen Servlet und Container: standardisiertes Servlet-API Anwendung unabhängig von konkretem HTTP-Server, Servlet-Container in Java geschrieben enthalten Geschäftslogik und HTML-Generierung werden nur einmal in den Servlet-Container geladen automatische Sitzungsverwaltung keine Unterstützung für Persistenz, Transaktionen, Verteilung aber passende Java-Technologien nutzbar s. Vorlesung zu Servlets in ST II 5

6 2.6.2 Java Server Pages (JSP) Problem: in Servlets keine Trennung zwischen Geschäftslogik und HTML- Generierung für die Benutzungsschnittstelle Code wird unübersichtlich in vielen Anwendungen überwiegt die Benutzungsschnittstelle und darin die statischen Anteile (z.b. einfaches Web-Informationssystem) Code der Geschäftslogik in HTML-Seite einbetten Anwendung als Menge von HTML-Seiten darin Code zum Erzeugen der dynamischen Anteile enthalten dieser Code in Java geschrieben dadurch Nutzung von Java-Technologien möglich (JDBC, Beans... ) aus der JSP-Seite wird ein Servlet generiert, das die Geschäftslogik und die HTML- Ausgaben enthält. Diese Aufgabe übernimmt der Servlet-Container, sofern er das JSP- API anbietet. bei komplexen Seiten auch schnell unübersichtlich, softwaretechnisch fragwürdig s. Vorlesung zu JSP in ST II 3 Fortgeschrittene Technologien für Geschäftsanwendungen 3.1 Transaktionsmonitore (TP-Monitore) Transaktionsmonitore (Transaction Processing Monitor) sind Betriebssysteme für Geschäftsanwendungen, da sie das gesamte Umfeld einer Anwendung kontrollieren: Nebenläufigkeit Transaktionen Sicherheit Persistenz stammen aus der Mainframe-Welt: leistungsfähiger Host-Rechner mit vielen dummen Terminals seit über 30 Jahren im Einsatz, z.b. CICS (IBM, seit 1968), TUXEDO (BEA) Geschäftslogik in prozeduralen Anwendungen implementiert, meist COBOL Aufruf von Prozeduren auch über Netzwerknachrichten oder Remote Procedure Calls (RPC) 3.2 Object Request Broker (ORB) Mit der Verbreitung der objektorientierten Software-Entwicklung wuchs auch der Bedarf nach einer Unterstützung für die Entwicklung objektorientierter, verteilter Geschäftsanwendungen. Funktionen in Objekten gekapselt, haben Identität Objekte im Netz verteilt, Zugriff von beliebigem Rechner aus 6

7 ORB stellt Kommunikationsinfrastruktur zur Verfügung, zum Teil auch erweiterte Dienste zum Auffinden von Objekten, für Zugriffsschutz und Transaktionen Dienste müssen vom Anwendungsentwickler explizit aufgerufen werden, stehen also nicht, wie bei TP-Monitoren, automatisch zur Verfügung Beispiel: CORBA 3.3 Komponenten-Transaktionsmonitore Component Transaction Monitor (CTM) Mischung aus TP-Monitor und ORB Betriebssystem für Geschäftsanwendungen + Verwaltung verteilter Objekte zahlreiche Produkte mit unterschiedlichen Stärken und Schwächen sorgfältig auswählen Daten und Funktionen der Geschäftsanwendung in Objekten (Geschäftsobjekten) gekapselt nötig: serverseitiges Komponentenmodell 3.4 Serverseitige Komponenten Geschäftsobjekte werden auf einem oder mehreren Servern verwaltet Klienten greifen über das Netzwerk auf die Objekte zu Verhalten zur Laufzeit beeinflußbar (konfigurierbar, customizable) Daten/Funktionen werden auf dem Server verwaltet/ausgeführt Komponentenmodell regelt Zusammenarbeit zwischen Komponenten der Geschäftsanwendung und dem CTM herstellerspezifische Komponentenmodelle erschweren die Anwendungsentwicklung und die Verbreitung der CTM Microsoft Transaction Server (MTS, 1996) mit DCOM-basiertem Komponentenmodell zahlreiche CORBA-basierte CTM Enterprise Java Beans ist dagegen ein breit akzeptierter quasi-standard Schichten-Architektur Die Schicht, in der die Geschäftslogik enthalten ist, wird auch als Middleware bezeichnet. Sie vermittelt zwischen den Klienten und den Datenverwaltungssystemen oft heterogenen Datenbank-Managementsystemen und Fremdsystemen, auf deren Daten zugegriffen werden muß (Abbildung 3). Der Entwickler der serverseitigen Komponenten muß sich nur um die zu realisierende Geschäftslogik kümmern. Alle weiteren Dienste für Kommunikation, Sicherheit, Transaktionsverarbeitung, Lastverteilung und Persistenz werden von der Middleware bereitgestellt. 7

8 Klienten Schicht (Darstellung) Klient Klient Anwendungs schicht (Geschäftslogik) Middleware Serverseitige Komponenten Datenverwaltungs schicht (Backend) DVS... DVS (DVS = Datenverwaltungssystem) Abbildung 3: 3-Schichten-Architektur Vorteile der 3-Schichten-Architektur: dünne Klienten (thin clients), da Verarbeitung hauptsächlich auf dem Server transparente Datenablage verwendete DVS sind leicht austauschbar leicht skalierbar wegen Lastverteilung in der Middleware gemeinsame Funktionen werden in serverseitigen Komponenten gekapselt und können leicht wiederverwendet werden geringerer Realisierungsaufwand, bessere Wartbarkeit 4 Zusammenfassung Geschäftsanwendungen stellen schwierige Anforderungen an den Anwendungsentwickler enthalten GUI, Geschäftslogik und Datenverwaltung Verteilung, Plattformunabhängigkeit, Persistenz, Sicherheit... Architektur und Implementierung muß angepaßt werden ( 3-Schichten- Architektur) Basistechnologien/Basissysteme erleichtern die Anwendungsentwicklung Transaktionsmonitore, serverseitige Komponentenmodelle Applikationsserver implementiert serverseitiges Komponentenmodell verwaltet Komponenten, stellt Infrastruktur und Dienste bereit (Persistenz, Transaktionen, Sicherheit... ) Beispiel für ein serverseitiges Komponentenmodell: Enterprise Java Beans 8