Software-Engineering Grundlagen des Software-Engineering 6.2 Verteilte Anwendungen und Web-Architekturen

Transkript

1 Software-Engineering Grundlagen des Software-Engineering 6.2 Verteilte Anwendungen und Web-Architekturen Prof. Dr. Rolf Dornberger Software-Engineering: 6 Entwurfsphase (Design Phase)

2 6.2 Verteilte Anwendungen und Web-Architekturen 6.2 Verteilte Anwendungen und Web-Architekturen Grundlagen Client/Server-Systeme Schichtenarchitektur c/s-kommunikation Web-Architekturen Webserver und Web-Applikationsserver

3 6.2.1 Grundlagen Client/Server-Systeme Client/Server-Systeme (c/s-systeme): Client/Server-Systeme ermöglichen das Rollenspiel zum Austausch von Daten, Informationen und Programmen zwischen Computern, die in einem Netzwerk miteinander verbunden sind. Die möglichen Rollen sind Client (Kunde) und Server (Diener). Ein Client-Server-System besteht aus mindestens einem Client, der eine Verbindung mit einem Server (oder mehreren Servern) aufbaut. Der Client bietet die Benutzeroberfläche oder die Benutzerschnittstelle der Anwendung an. Der Server stellt die (oder zumindest eine gewisse) Funktionalität zur Verfügung

4 6.2.1 Grundlagen Client/Server-Systeme Eigenschaften: Im Vergleich zu einem Einzelplatzrechner arbeiten Client/Server-Systeme zusammen, d.h. sie nehmen eine Arbeitsaufteilung vor und kommunizieren entsprechend. Im Vergleich zu einem Host arbeiten Client/Server-Systeme föderalistisch zusammen, nicht zentralistisch. Wenn der Server in einem Client/Server-System nur Daten anbietet (z.b. ein zentraler Datenbankserver) und die Verarbeitung der Daten auf dem Client erfolgt, wird das entsprechende Client-Programm als Fat-Client bezeichnet. Ist die Funktion des Clients auf eine reine Benutzerschnittstelle reduziert, insbesondere im Intranet mittels eines Browsers, spricht man von einem Thin-Client. Die eigentliche Programmlogik liegt dann auf einem Application Server

5 6.2.1 Grundlagen Client/Server-Systeme Beispiele von Client/Server-Systemen: File-Server: Imitiert Laufwerke (unechtes Client/Server-System), bietet Dateien an und lässt geteilte Dateizugriffe zu. ähnliches Prinzip bei FTP- oder Webserver weit verbreitet Database-Server: Regelt den Zugriff auf Datenbanken. unterschiedliche Systeme Calculation-Server: Rechenintensive Aufgaben werden auf mehrere Computer verteilt (Parallelisierung, "Number Cruncher"). oftmals im technisch-wissenschaftlichen Rechnen Groupware-Server: Verwaltet wenig strukturierte Daten (z.b. Texte, Mails, Newsgroup-Einträge, Workflows...), um die Zusammenarbeit von Menschen zu begünstigen

6 6.2.1 Grundlagen Client/Server-Systeme Security-Server: Überprüft die Zugriffsberechtigungen auf Daten und Systeme mittels: Webserver: Authentifizierung: Überprüfung der vorgegebenen Identität Security Database: Verwaltung der Benutzer, Passwörter, Schlüssel Privilege Server: Verwaltung der Zugriffsrechte Geht über das Prinzip eines File-Servers hinaus und bietet dynamisch erzeugte Web- Seiten. FTP-Server: Übertragung von Files gemäss dem File Transfer Protocol. Directory-Server: Hilft dem Webserver, Ressourcen und Dienstleistungen aufzufinden. Beispiel ist der Internet-DNS (Domain Name Server). Anfrage URL <protocol>://<server>:<port>/<ressource> liefert IP-Adresse

7 6.2.1 Grundlagen Client/Server-Systeme Transaction-Server: Gruppiert mehrere Anfragen eines Clients in eine Arbeitseinheit (Transaktion). Diese Arbeitseinheit schlägt entweder vollständig fehl (Rollback), oder wird vollständig ausgeführt (Commit). DSM-Server (Distributed System Management): Verwaltet verteilte Systeme und deren Kommunikation. Mail-Server: Verwaltet die ein- und ausgehende s. Print-Server: Verwaltet die Druckaufträge in einem verteilten System

8 6.2.2 Schichtenarchitektur Architektur von Client/Server-Systemen: Ein oder mehrere Server bieten eine Dienstleistung für einen bis mehrere Clients aufgrund deren Anfragen an (geteilte Ressourcen). Der Server entscheidet als abgeschlossene Einheit mit wohl definiertem Zugriff über die Erfüllung der Dienstleistung. c/s-systeme bieten eine gute Skalierbarkeit: horizontale Skalierbarkeit mehr/weniger Clients vertikale Skalierbarkeit mehr/weniger Server c/s-systeme sollten unabhängig von Hardware und Betriebssystemen kombiniert werden können. c/s-architekturen bestehen aus mehreren Schichten (engl.: tier)

9 6.2.2 Schichtenarchitektur Schichtenarchitektur: Die meisten c/s-architekturen sind 2- oder 3-Schichten-Architekturen (two bzw. three tier architecture). Sind mehrere Schichten beteiligt, spricht man von einer Mehrschichten- Architektur (multi tier architecture). Bei Mehrschichten-Architektur wird die Applikation in mehrere diskrete Komponenten aufgeteilt. Meist wird eine Dreischichtenarchitektur angewendet, in der Datenbank, Anwendungslogik und Präsentation (Web-Oberfläche oder Client) eingeteilt wird. Jede dieser Komponenten kann auf einem eigenen Computer laufen. Muss aber nicht. Die 2-Schichten Architektur ist die kleinste Client-Server-Mehrschichten-Architektur, die softwareseitig als zweischichtiges System aufgebaut ist. Die Rechenkapazität wird dabei weitestgehend auf die Client-Rechner ausgelagert, um den Server zu entlasten

10 6.2.2 Schichtenarchitektur Vergleich Schichtenarchitektur: 1 Schicht (lokaler Arbeitsplatzrechner): 100% Präsentation 100% Anwendungslogik 100% Datenhaltung 2 Schichten: Client: 100% Präsentation, 0-100% Anwendungslogik Server: 100% Datenhaltung 100-0% Anwendungslogik 3 Schichten: Client: 100% Präsentation Applikations-Server: 100% Anwendungslogik Datenbank-Server: 100% Datenhaltung

11 6.2.2 Schichtenarchitektur Vor- und Nachteile einer 2-Schichten- Architektur: + weniger komplex als 3 Schichten - keine eindeutige Trennung der Geschäftsprozesse und Logik - Skalierbarkeit schwieriger, da Grenzen der Geschäftsprozesse und Logik unscharf - keine separate Installation/Wartung - schwieriger zu administrieren Vor- und Nachteile einer 3-Schichten- Architektur: - komplexer als 2 Schichten + klare Trennung vor allem der Geschäftsprozesse und Logik + Skalierbarkeit einfacher, da Teil des Konzeptes + separate Installation, Wartung und Weiterentwicklung möglich + einfacher zu administrieren, vor allem mit Thin-Clients

12 6.2.3 c/s-kommunikation Nicht-Client/Server Programme: Stand-Alone-Programme (Nicht-Client/Server Programme) im Gegensatz zu c/s- Programmen werden von den Betriebssystemen im Allgemeinen als einzelne, eigenständige Prozesse angesehen. Jeder Prozess hat seinen eigenen Speicher, seine eigenen Register und Stack-Werte. Innerhalb eines Prozesses (also eines Programms) kann auf den zugewiesenen Speicher, die entsprechenden Register und den Stack zugegriffen werden. Gegen Eingriffe von außen sind diese jedoch geschützt

13 6.2.3 c/s-kommunikation Client/Server Programme: Wird eine Applikation auf mehrere Computer verteilt, muss sie auch auf mehrere Prozesse verteilt werden. Damit ein Datenaustausch zwischen diesen Prozessen möglich wird, muss ein Kommunikationskanal zur Verfügung gestellt werden. Der Mechanismus, der dies ermöglicht, wird Interprozesskommunikation (Inter Process Communication: IPC) genannt. Typische IPC-Mechanismen sind beispielsweise Socket, Named Pipe, RPC (Remote Procedure Call), ORB (Object Request Broker), MOM (Message Oriented Middleware)

14 6.2.3 c/s-kommunikation Client/Server-Kommunikation: Unter Interprozesskommunikation (inter-process communication, IPC) versteht man Methoden zum Informationsaustausch von nebenläufigen Prozessen oder Threads. Im engeren Sinne versteht man unter IPC die Kommunikation zwischen Prozessen auf demselben Computer, deren Speicherbereiche aber strikt voneinander getrennt sind (Speicherschutz). Im weiteren Sinne bezeichnet IPC aber jeden Datenaustausch in Verteilten Systemen, von Threads die sich ein Laufzeitsystem teilen bis hin zu Programmen die auf unterschiedlichen Rechnern laufen und über ein Netzwerk kommunizieren. Für die Kommunikation ist dabei eine geeignete Prozesssynchronisation notwendig, insbesondere wenn verschiedene Prozesse potentiell gleichzeitig auf dieselben Ressourcen zugreifen können. Dabei sind neben Dateien, Peripheriegeräten, etc auch andere Prozesse, mit denen kommuniziert werden soll, als Ressourcen zu verstehen. [...] [Quelle: Stand: ]

15 6.2.3 c/s-kommunikation Sockets und Named Pipes sind betriebssystemnahe Konversationsprotokolle. Sie sind neben sehr systemnaher Programmierung auch im Internet sehr wichtig. Beispielsweise stellt Java Klassen zur Verfügung, mit denen einfach auf Sockets zugegriffen werden kann. Die anderen IPC Mechanismen können selbst wiederum Sockets und Named Pipes verwenden

16 6.2.3 c/s-kommunikation RPC (Remote Procedure Call) ist eine alte, aber einfache Methode zur c/s-kommunikation. Die Schnittstellen werden mit Prozeduren, die als Interfaces implementiert sind, definiert. Das Interface wird in einer IDL Sprache definiert (Interface Definition Language). Client und Server erhalten die gleichen Interfaces. Der Client ruft die Prozeduren auf und der Server führt die entsprechenden Aktionen dazu aus. Damit ein Client seinen Server findet, muss auf dem Server muss ein Programm laufen, das auf einkommende Anfragen reagieren und die entsprechenden Prozesse auf dem Server starten kann. Dazu gibt es drei Möglichkeiten: static binding: Adresse des Servers fix im Quellcode dynamic binding: Adresse zur Laufzeit in einem Directory Server nachgefragt automatic binding: RPC-Laufzeitumgebung sucht automatisch einen Server, der das definierte Interface bereitstellt

17 6.2.3 c/s-kommunikation ORB (Object Request Broker) wendet die Eigenschaften der objektorientierten Sicht auf die c/s-kommunikation an und erweitert damit die RPCs. Alle Funktionalitäten und Schnittstellen sind in Klassen und Objekten gegliedert und gekapselt. Die Anfragen erfolgen nun nicht mehr in Prozeduren sondern in Objekten. Der ORB ist aber nun ein eigenständiges Programm, das jeweils auf den Clients und Servern installiert sein muss. Es wartet auf entsprechende Anfragen und reagiert dementsprechend. Verschiedenste zusätzliche Dienstleistungen sind mit den ORBs nun möglich. Z.B. Life Cycle Verwaltung von Objekten, Persistenz Service zur Speicherung von Objekten in verschiedensten Systemen, Event Service (dynamische Ereignisse), Synchronisation, Security Service... Verschiedenste (kommerzielle und nicht-kommerzielle) Umsetzungen dieser Technologie gibt es: CORBA (Common Object Request Broker Architecture), EJB (Enterprise Java Beans), RMI (Remote Method Invocation), COM+ (Common Object Modell Plus),.NET,

18 6.2.3 c/s-kommunikation MOM Message Oriented Middleware) unterscheidet sich von RPC und ORB hauptsächlich darin, dass bei MOM zwischen dem Client und dem Server keine permanente Verbindung bestehen muss. Die Daten, die Client und Server austauschen, werden auf beiden Seiten solange in einer Warteschlange gehalten, bis eine Verbindung zwischen dem Client und dem Server aufgebaut ist. Die Antwort wird ebenfalls wieder über die Warteschlange zurückgegeben

19 6.2.4 Web-Architekturen Web-Architekturen: Web-Architekturen sind eine Alternative zu den klassischen Client/Server-Systemen mit ihrer c/s-schichtenarchitektur und c/s-kommunikation. Web-Architekturen sind webfähige Client/Server-Systeme. Sie bestehen mindestens aus einem Browser auf Client und einem Webserver auf dem eigentlichen Server. Die Kommunikation findet allerdings im Gegensatz zu den klassischen c/s-systemen nicht über IPC statt, sondern über HTTP über das Inter- bzw. Intranet. Web-Architekturen bieten Vorteile gegenüber den klassischen Client/Server-Systemen, indem die Anwendungen automatisch im Internet verwendet werden können. die Clients an sich installations- und wartungsfrei sind, da sie lediglich einen Browser benötigen

20 6.2.4 Web-Architekturen Webclients: HTML, HTML-Formulare, Skriptsprachen, Komponenten Webserver: Programmierbar, Verarbeitung von eingegangenen Formularen, dynamisch erzeugte HTML-Seiten, Beispiele: CGI, ASP, JSP/Servlets... Weitere Server: Webserver spricht gegebenenfalls weitere Server (Web-Applikationsserver) an, z.b. Datenbank- Server

21 6.2.5 Webserver und Web-Applikationsserver Webserver: Ein Webserver ist eine Software, die es ermöglicht, Webseiten und Dienste den Usern des Internets zur Verfügung zu stellen. Der User muss nur einen Webbrowser installiert haben. [Brockhaus]

22 6.2.5 Webserver und Web-Applikationsserver Webserver: Ein Webserver ist im engeren Sinne ein Server-Dienst, der Informationen nach dem HTTP-Protokoll zur Verfügung stellt. Die Daten werden über HTTP-URLs adressiert. Im weiteren Sinne wird der Begriff Webserver auch für den Host verwendet (dann Web-Host genannt), auf dem der Server-Dienst betrieben wird. Ein Nutzer stellt eine Anforderung, z.b. durch Anklicken eines Links in seinem Browser (Client). Der Browser leitet einen HTTP-Request an den im Link adressierten Webserver. Der Webserver liefert die adressierte Seite mitsamt eines Mime-Types zurück. Der Browser zeigt die übertragenen Daten entsprechend ihres MIME-Types an. Die Standard-Ports für Webserver sind Port 80 für HTTP und Port 443 für HTTPS (per SSL verschlüsselte HTTP-Verbindung). [Quelle: Stand: ]

23 6.2.5 Webserver und Web-Applikationsserver Webserver: Im typischen Umfeld einer Website liefert ein Webserver vorwiegend statische Daten wie HTML-Seiten, Stylesheets oder Bilder und Grafiken (JPG, GIF, PNG) zurück. Neben statischen Daten werden zunehmend dynamische, d.h. beim Abruf erzeugte Daten, ausgeliefert. Dies geschieht durch den Einsatz von Skripten (PHP, JSP, ASP), Server- Containern (Servlets, ASP.NET) und Webservices (Soap). [...] Auf dem Webserver werden üblicherweise alle Anfragen in einem Logfile protokolliert, aus dem mittels Logfile-Analyse Statistiken über Besucherzahlen bzw. Anzahl der Zugriffe pro Seite generiert werden können. Da HTTP ein verbindungs- und zustandsloses Protokoll ist, ist eine eindeutige Zuordnung einer Anforderung zu einem Nutzer nicht möglich. Die Angabe von Visits, Hits, Benutzer o.ä ist daher nur eingeschänkt aussagekräftig. [...] Um genauere Daten zu erhalten, werden Cookies und dynamische Seiten eingesetzt. [Quelle: Stand: ]

24 6.2.5 Webserver und Web-Applikationsserver Web-Applikationsserver: Tendenz von Informationslieferung zur Anbindung von Anwendungen geht in Richtung starke Interaktion zwischen verteilten Clients und Datenspeichern im Back-End- Bereich (e-business), beispielsweise unter Einbezug von Datenbanken und Dateisystemen. Integration von heterogenen Systemen bzw. Legacy Systemen, beispielsweise mit CORBA, COM, COM+ und EJB. schnelle Realisierung von Projekten mit Hilfe von vorgefertigten Elementen. Um dies zu ermöglichen braucht es Web-Applikationsserver, wie z.b. Tomcat (Apache Software Foundation), ColdFusion (Macromedia), WebSphere (IBM), Enhydra (Lutris)... Web-Applikationsserver besitzen die logischen Schichten: Web-Applikationsschicht (Runtime-Umgebung für die dynamische Erzeugung von Webseiten) Business-Logik-Schicht (Einsatz von verteilten Softwarekomponenten, Integration von Legacy-Systemen)

25 6.2.5 Webserver und Web-Applikationsserver Web-Applikationsserver: Ein Application Server (bzw. Web-Applikationsserver) ist ein Server in einem Computernetzwerk, auf dem eine spezielle Software-Applikation läuft. Häufig meint man dabei Software-Applikationen mit einer drei- oder mehrschichtigen Architektur, wie sie z.b. vom J2EE- oder.net-framework vorgeschlagen werden. Ziel ist es, namensgebend für dreischichtige Architektur, die drei Aufgaben Präsentation, Geschäftslogik und Datenhaltung voneinander zu trennen. Die Präsentation wird von einem Client, gerne einem Thin Client, beispielsweise von einem Web-Browser übernommen, welcher eine Oberflächendefinition z.b. in HTML oder Swing darstellt. Dafür werden oft ASP, JSP/Servlets, oder ColdFusion verwendet. Die Geschäftslogik wird nicht selten in Geschäftsprozesse (Session Bean bei J2EE) und Geschäftsobjekte aufgeteilt (Entity Beans bei J2EE) und in einer Programmiersprache wie Java, VB.NET, C#, Perl, PHP realisiert. Für die Datenhaltung wird meist eine relationale Datenbank wie z.b. MySQL, DB2 oder MS SQL Server eingesetzt. [Quelle: Stand: ]

26 Lernziele Funktionsweise von Client/Server-Systemen erklären und die wichtigsten Server und deren Aufgaben aufzählen können. Schichtenarchitektur von c/s-systemen beschreiben können. Die c/s-kommunikation erklären können, speziell RPC (Remote Procedure Call) und ORB (Object Request Brokers). Web-Architekturen beschreiben können. Die Funktionsweise von Webservern und Web-Applikationsservern sowie deren Zusammenhang mit client- und serverseitigen Web-Technologien erklären können. Funktionsweise von Verteilten Systemen erklären können