18.3 Architekturmuster für verteilte Systeme

Transkript

1 18.3 Architekturmuster für verteilte Systeme Master-Slave-Architektur garantierte Antwortzeiten in Echtzeitsystemen Zweischichtige Client-Server-Architektur einfache Client-Server-Systeme Zentralisierung aus Sicherheitsgründen Mehrschichtige Client-Server-Architektur bei großen Mengen von Transaktionen Verteilte Komponentenarchitektur Kombination von Ressourcen aus verschiedenen Systemen Implementierungsmodell für mehrschichtige Client-Server-Syst. Peer-to-Peer-Architektur (P2P) direkter Austausch lokaler Information Server nur zur Bekanntmachung der Clients untereinander Stand: Folie Master-Slave-Architekturen Echtzeitsysteme Prozesse zur Datenerfassung von Sensoren Prozesse zur Datenverarbeitung und Berechnung Prozesse zur Steuerung von Aktuatoren Master-Prozess MCI (Darstellung und Interaktion) Berechnung Koordination und Kommunikation der Slave-Prozesse Slave-Prozesse aufgabenspezifisch z.b. Messwerterfassung aus einer Sensoren-Gruppe z.b. Steuerung einer Aktuatoren-Gruppe Stand: Folie 18.24

2 Master-Slave-Architekturen Master Leitwartenprozessor Koordinationsund Anzeigeprozess Ampelsteuerungsprozess Slave Slave Sensordatenprozessor Sensorsteuerungsprozess Ampelsteuerungs -prozessor Sensoren und Kameras der Verkehrsüberwachung Operator-Terminals Ampeln (WLZA) und Wechselzeichen Stand: Folie Zweischichtige Client-Server-Architekturen ein einziger logischer Server und beliebig viele Clients Thin Clients: nur Präsentationsschicht Fat Clients: auch weitere Schichten der Anwendung -> Schichtenmodell 18.2 (inkonsistent zu ) Thin Präsentationsschicht Client Fat Datenverwaltungsschicht Anwendungsverarbeitungsschicht Server Datenbankschicht Stand: Folie 18.26

3 Zweischichtige Client-Server-Architekturen Thin Clients einfache Verwaltung der Clients Nutzung von Standard-Clients (z.b. Webbrowser) oft als GUI für Altsysteme hohe Belastung von Netz und Server Fat Clients mehr Verarbeitung auf dem Client-Prozessor senkt Belastung von Netz und Server kann Fähigkeiten der Clients optimal nutzen aufwendigere Verwaltung z.b. bei neuer Funktionalität Beispiel: Geldautomaten Stand: Folie Mehrschichtige Client-Server-Architekturen Verteilung der Schichten auf verschiedene Prozessoren oft dreischichtig: Client, Webanwendungsserver, Datenbankserver bessere Skalierbarkeit z.b. zusätzliche Webanwendungsserver leichtere Verwaltung Anwendungslogik zentriert in einer Schicht Beispiel: Kontoführung im Web Stand: Folie 18.28

4 Client-Server-Architekturen ^êåüáíéâíìê òïéáëåüáåüíáö qüáå `äáéåíë òïéáëåüáåüíáö c~í `äáéåíë ãéüêëåüáåüíáö ^åïéåçìåöéå ^åïéåçìåöéå=ãáí=^äíëóëíéãéå=e`äáéåíë=êìñéå=péêîáåéë=~ìñf oéåüéåáåíéåëáîé=^åïéåçìåöéå=ãáí=öéêáåöéê=a~íéåîéêï~äíìåö EòK_K=`çãéáäÉêF a~íéåáåíéåëáîé=^åïéåçìåöéå=çüåé=~ìñïéåçáöé=içöáâ EòK_K=_êçïëÉêF ^åïéåçìåöéå=ãáí=pí~åç~êçéêçöê~ããéå=~ìñ=çéã=`äáéåí= EòK_K=q~ÄÉääÉåâ~äâìä~íáçåF ^åïéåçìåöéå=ãáí=üçüéã=oéåüéå~ìñï~åç= EòK_K=sáëì~äáëáÉêìåÖF ãçäáäé=^åïéåçìåöéå=çüåé=ö~ê~åíáéêíé=hçååéâíáîáí í Eäçâ~äÉ=sÉê~êÄÉáíìåÖ=òïáëÅÜÉåÖÉëéÉáÅÜÉêíÉê=a~íÉåF Öêç É=^åïÉåÇìåÖÉå=ãáí=îáÉäÉå=eìåÇÉêíÉå=`äáÉåíë ^åïéåçìåöéå=ãáí=ü ìñáöéå=séê åçéêìåöéå= ÄÉá=a~íÉå=ìåÇ=ÄÉá=mêçòÉëëÉå ^åïéåçìåöéå=ãáí=a~íéå=~ìë=ãéüêéêéå=nìéääéå Stand: Folie Verteilte Komponentenarchitekturen Keine Differenzierung nach Schichten / Clients / Servern Komponenten nutzen Dienste und stellen Dienste bereit Kommunikation erfolgt über Middleware (remote procedure calls) komplexer als Client-Server-Architektur Komp. 1 Komp. 2 Komp. 3 Komp. 4 verfügbare Dienste verfügbare Dienste verfügbare Dienste verfügbare Dienste Kommunikations-Middleware Client Client Client Client Stand: Folie 18.30

5 Verteilte Komponentenarchitekturen Anwendungen mit starker Verteilung (z.b. Data Mining mit mehreren Datenbanken) in der Praxis selten wegen zwei Hauptnachteilen: hohe Komplexität => Verständnis-, Darstellungs- und Designprobleme Middleware-Standards nicht durchgesetzt => unterschiedliche Middleware unterschiedlicher Anbieter Ablösung durch serviceorientierte Architektur vgl. Kapitel 19 Stand: Folie Peer-to-Peer-Architekturen gleichberechtigte Teilnehmer keine Unterscheidung zwischen Client und Server bessere Verteilung der Rechenlast jeder Knoten im Netzwerk kann benutzt werden bessere Verteilung der Netzlast keine Umwege erforderlich dezentralisiert hoher Aufwand bei Suche über viele Peers halbzentralisiert Super-Peer als Vermittlung und zur Aufgabenverteilung Anwendung meist im PC-Bereich Informationsaustausch: Filesharing, VoIP,... Verteiltes Rechnen: Stand: Folie 18.32

6 18.4 Software als Service (SaaS) Software bereitgestellt auf Server(n) Zugriff über Web-Browser keine lokale Installation keine Bindung an bestimmte Rechner / Mobilgeräte Software verwaltet durch Anbieter keine Kosten beim Anwender kein Einfluss des Anwenders mögliche Probleme mit Datenschutz und Datensicherheit Verschiedene Finanzierungsmodelle Werbung Abonnement pay per use Stand: Folie SaaS und SOA SaaS: Bereitstellung von Funktionalität auf Servern Zugriff über das Web Server verwaltet Benutzerdaten Server verwaltet Sitzungsdaten lange Transaktionen (z.b. Dokumentbearbeitung) SOA: Struktur für Softwaresysteme Menge zustandsloser Dienste mehrere Anbieter möglich Verteilung möglich kurze Transaktionen (z.b. Aufruf und Rückgabe eines Dienstes) SaaS kann mit SOA implementiert werden, muss aber nicht Stand: Folie 18.34

7 18.4 Implementationsfaktoren für SaaS Konfigurierbarkeit Berücksichtigung spezifischer Bedürfnisse der Anwender Mandantenfähigkeit virtuelle eigene Software für Anwender saubere Trennung der Daten effiziente Nutzung der Ressourcen Skalierbarkeit Anpassung an schwer vorhersagbare Anzahl von Nutzern Änderbarkeit Annahmen über Benutzerbedürfnisse möglicherweise falsch agile Entwicklungsmethoden sinnvoll Stand: Folie Konfigurierung von Services Corporate Design des Anwenders im UI und bei Dokumentausgabe (Branding) Geschäftsregeln und Arbeitsabläufe bezüglich der Daten (z.b. Validierung) bezüglich der Nutzung (z.b. Reihenfolge der Bearbeitung) Datenbanken Erweiterung des generischen Datenmodells des Service um unternehmensspezifische Anteile Berechtigungen individuelle Konten für Mitarbeiter / Mitarbeitergruppen des Anwenders Regelungen für Zugriff auf Funktionen und Ressourcen Stand: Folie 18.36

8 18.4 Unterstützung der Skalierbarkeit bei SaaS jede Komponente als einfacher zustandsloser Service kann auf jedem Server laufen Benutzer kann mit mehreren Instanzen arbeiten asynchrone Kommunikation kein Warten auf Ergebnisse einer Interaktion Benutzer kann weiterarbeiten Poolbildung für Ressourcen kein Ausfall von Servern wegen fehlender Ressourcen detailliertes Sperren in der Datenbank unterhalb Datensatzebene Stand: Folie 18.37

9 19 Serviceorientierte Architektur 19.0 Einführung Lernziele Grundbegriffe 19.1 Services als wiederverwendbare Komponenten Spezifikation mit WSDL 19.2 Service-Engineering Ermittlung von Servicekandidaten Entwerfen von Serviceschnittstellen Implementierung und Bereitstellung der Services Services für Altsysteme 19.3 Software-Entwicklung mit Services Entwurf und Implementierung des Workflows Testen von Services Stand: Folie Lernziele die Grundbegriffe von Webservices, Webservicestandards und serverorientierter Architektur verstehen den serviceorientierten Engineering-Prozess für wiederverwendbare Webservices kennen Servicekomposition als Mittel der serviceorientierten Anwendungsentwicklung kennen wissen, wie Geschäftsprozessmodelle als Grundlage für den Entwurf serviceorientierter Systeme eingesetzt werden Stand: Folie 19.2

10 19.0 Service Definition an act or performance offered by one party to another. Although the process may be tied to a physical product, the performance is essentially intangible and does not normally result in ownership of any of the factors of production Wesentliche Merkmale Bereitstellung unabhängig von der Anwendung Serviceanbieter entwickeln spezifische Services Vielzahl von Benutzern von verschiedenen Anwendern Stand: Folie Serviceorientierte Architekturen Methode zur Entwicklung verteilter Systeme Services als eigenständige Komponenten Ausführung auf geografisch verteilten Rechnern verschiedener Anbieter Standards für Kommunikation und Datenaustausch SOAP: Nachrichtenaustausch WSDL: Definition von Serviceschnittstellen WS-BPEL: Standard für Workflow-Sprachen zur Definition der Komposition von Services Vorteile der SOA Services lokal oder extern (Outsourcing) Services sprachunabhängig Einbindung von Altsystemen möglich Anwender übergreifende Systeme möglich Stand: Folie 19.4

11 19.0 Serviceorientierte Architektur Service- Registrierung suchen veröffentlichen Service- Anforderer binden (SOAP) Service- Anbieter Service (WSDL) Stand: Folie Standards für Webservices XML-Technologien (XML, XSD, XSLT,...) Unterstützung (WS-Security, WS-Adressing,...) Prozess (WS-BPEL) Servicedefinition (WSDL, UDDI) Nachrichtenaustausch (SOAP) Transport (HTTP, HTTPS, SMTP,...) Stand: Folie 19.6

12 19.0 REST-konforme (RESTful) Webservices Webservicestandards schwergewichtig zu allgemein, zu ineffizient REST (REpresentational State Transfer) Übertragung von Ressourcenrepräsentationen von Server zu Client RESTful Webservices geringerer Verwaltungsaufwand Identifikation durch URI nur HTML-Methoden GET, PUT, POST, DELETE Ersatz für SOAP/WSDL wenn keine externen Services nötig keine Unterstützung für WS-Reliability, WS-Transactions etc. Stand: Folie 19.7