Kapitel 1 Applikations Architektur III

Transkript

1 Kapitel 1 Applikations Architektur III Software Engineering FS 2015 Prof. Dr. Jana Köhler jana.koehler@hslu.ch

2 Gesamtüberblick I. Software Architektur Grundbegriffe II. Prinzipien & Taktiken III. Stile und Muster IV. Sichten, Architekturentscheidungen und Dokumentation V. Bewertung von Architekturen (ATAM) VI. Beruf des IT Architekten VII. Fallstudie Fillialbestellstystem aus Modul Applikationsentwicklung 2

3 Vogel et al. 3

4 Architekturmuster A pattern for software architecture describes a particular recurring design problem that arises in specific design contexts, and presents a well-proven generic scheme for its solution. Buschmann et al: Pattern-Oriented Software Architecture Wiley

5 Stil einer Architektur Architektur-Stil als ein Muster der strukturellen Organisation einer Familie von Systemen (Vogel nach Shaw & Garlan) Fundamentale Struktur eines Software-Systems und dessen Eigenschaften Eine Menge von Komponententypen, die bestimmte Funktionen zur Laufzeit erfüllen. Eine topologische Anordnung dieser Komponenten. Eine Menge von Konnektoren, die die Kommunikation und Koordination zwischen den Komponenten regeln: Eine Menge von semantischen Einschränkungen, die bestimmen, wie Komponenten und Konnektoren miteinander verbunden werden können. 5

6 Architektur Stile (Grundlegende Muster) In der Literatur existieren unterschiedliche Auffassungen, welche grundlegenden Muster als Stil betrachtet werden Wir betrachten: 1. Schichten (Layers, Tiers) 2. Pipes & Filters 3. Verteilte Systeme a) Client/Server b) Peer-to-Peer (P2P) 4. Blackboard 5. Service-orientierte Architekturen (SOA) 6

7 1. Schichten Elemente einer Schicht besitzen einen ähnlichen Abstraktionsgrad Eine Schicht bietet nach oben Services an fungiert als Server Eine Schicht benutzt nur die Services der direkt darunterliegenden Schicht fungiert als Client Ein Durchgreifen auf tiefere Schichten zerstört die Architektur! 7

8 Vorteile und Nachteile von Schichten + Leicht verständliches Strukturkonzept + Minimiert Abhängigkeiten zwischen Komponenten + Schichten sind voneinander unabhängig in Erstellung und Betrieb + Änderungen in einer Schicht können maximal eine andere Schicht betreffen Kann die Performance eines Systems beeinträchtigen, wenn Anfragen durch mehrere Schichten weitergereicht werden müssen Änderungen im Datenmodell können alle Schichten betreffen (Datenverwaltung, Applikation, Präsentation) 8

9 Spezialfall von Schichten: N-Tier Architekturen Kann als spezielle Form der Schichtenbildung, aber auch als spezielle Client/Server Architektur angesehen werden Web Container Client Domain Container Tiers können mit ihren Nachbarn kommunizieren Bidirektionale Abhängigkeiten verletzen Top-Down Prinzip der Schichtenbildung Potentiell erhöhter Integrationsaufwand Enterprise Information System Corporate Database Oftmals Abbildung von Komponenten auf die zugrundeliegende Infrastruktur 9 Beispiel: Webbasiertes 3-Tier System

10 2. Pipes und Filters Folge von Verarbeitungseinheiten (Filter), miteinander durch Datenkanäle verbunden (Pipes) Jeder Filter gibt sein Ergebnis direkt an den nächsten Filter weiter Pipes sind keine eigenen Komponenten in der Architektur (sind Konnektoren) Datenerzeugung Datenaufbereitung Datenkompression Datenspeicherung Verschiedene Koordinationsmodelle denkbar Dezentrale/zentrale Steuerung Pipes passiv oder aktiv Datenübergabe komplett, stückchenweise, zeitversetzt 10

11 Vorteile und Nachteile von Pipes und Filters + Einfache Implementierung + Klar verständliche Struktur + Klar strukturierte Abläufe + Mächtige Pipes können entscheiden, an welche Instanz eines Filters (Load balancing) oder an welchen Filter (Kapselung) sie die Daten weitergeben Filter kennen einander nicht Folgefehler können von ihnen nicht behandelt werden 11 Konfiguration der Verarbeitungskette kann schwierig sein Filter können nur über Daten kommunizieren Gesamte Verarbeitungsinformation muss in den Daten oder der zentralen Steuerung enthalten sein

12 3a. Client/Server Applikationen (Clients) werden lokal betrieben Benötigte Dienste werden zentral verwaltet und zur Verfügung gestellt (Server) Kommunikation ist einfaches Anfrage- Antwort-Schema Anfrage Antwort 12

13 Rich versus Thin Client Wie wird die Funktionalität auf Client und Server verteilt? Thin Client Nur eingeschränkte Funktionalität im Client direkt implementiert, hoch abhängig von Server Funktionalität Gmail (Web-Browser + Webserver) Rich Client Grosser Umfang lokal im Client, geringere Abhängigkeit vom Server MS Outlook (Windows Applikation + Mail Server) 13

14 Vorteile und Nachteile von Client/Server + Zentralisierung wichtiger, rechenintensiver oder sensibler Berechnungen im Server + Thin Clients einfach in Verteilung und Wartung + Rich Clients oft bei Server-Ausfall noch verwendbar Netzbelastung hoch (besonders bei Thin Clients) Verteilung der Funktionalität nicht immer einfach Grenzen der Skalierung bei sehr hohen Clientzahlen 14

15 3b. Peer-To-Peer (P2P) Gleichberechtigte, über ein Netzwerk verteilte Komponenten (Peers), die sowohl die Rolle von Clients als auch Servern wahrnehmen und sich Ressourcen teilen Eine Art von Konnektor («interpeer connection») In der Regel das Internet Keine zentrale Kontrolle, Peers sind frei in der Kommunikation (jeder mit jedem) Lokalisierung der Peers durch dezentrale Kommunikation (Peers tauschen untereinander ihre Listen bekannter Peers aus) oder einen zentralen Service 15

16 Vorteile und Nachteile von P2P + Hohe Ausfallsicherheit (kein single point of failure) + Rechenintensive Aufgaben können verteilt werden Seti@Home Auffinden und Erkennen von Peers in grossen Netzen Potentielle Gefahr des Zerfalls des P2P Netzes Nur bestimmte Gruppen von Peers kennen sich Fehlerbehandlung (Wer reagiert, wenn ein Peer seine Aufgaben falsch löst?) Keine garantierten Antwortzeiten 16

17 4. Blackboard Ursprünglich aus der Künstlichen Intelligenz zur Lösung komplexer Probleme, für die kein deterministisches Lösungsverfahren existiert Kollaborative Problemlösung durch ansonsten unabhängige Programme Keine Aufrufe zwischen den Programmen, Kommunikation nur über Blackboard Zentrale Steuerungskomponente bewertet den Lösungsfortschritt auf dem Blackboard und aktiviert die verfügbaren Programme Programme Blackboard als zentraler Datenspeicher 17

18 Vorteile und Nachteile von Blackboards + Einfache Integration komplexer Systeme + Parallelisierung der Berechnungen möglich + Moderne Variante: Tuple Space Keine Garantie der Lösungsfindung Finden der richtigen Kontrollstrategie ist schwierig Keine garantierten Antwortzeiten und Lösungen 18

19 5. Service-orientierte Architekturen Thema für Business + IT Quelle: Gartner 19

20 SOA aus Architektursicht Spezifikation der Services und der verwendeten Datenformate und Kommunikationsprotokolle Entwurf der Applikationen als Orchestrierung von Services zur Erreichung bestimmter Geschäftsziele Service provider und service consumer 20

21 Schichten in der SOA Referenzarchitektur der OG 21

22 Services in allen Schichten Quelle: Open Group, SOA Reference Model 22

23 Grundprinzipien und Technologien Vielzahl von Standards XML-basierte Datenformate SOAP/REST als wichtigste Protokolle Quelle: A.Thomas Manes, Gartner/Burton Service-orientierte Systeme Modular Verteilbar Auffindbar Austauschbar Wiederverwendbar 23

24 SOA Governance SOA Governance entscheidend für erfolgreiche Umsetzung Quelle: A.Thomas Manes, Gartner/Burton 24

25 Vorteile und Nachteile von SOA + Sehr flexible Architekturform mit einfachem Grundmodell + Systemfunktionalitäten als wiederverwendbare Assets verkapselt + Binden von Services zur Laufzeit und Lookup in Registries möglich + Vielzahl von ausgereiften Standards + Verbindung von Business und IT + Voraussetzung für Cloud, Mashups, Inhärente Komplexität offener, dezentralisierter Systeme Vielzahl schwieriger Fragestellungen Service design, Interoperabilität, Standards 25

26 Aufgabe K3: Architekturstil anwenden I. Wählen Sie einen Architekturstil aus und wenden Sie ihn auf Ihren machfolgenden Systementwurf an. II. Bilden Sie Schichten zu ihrem aktuellen Systementwurf. Verfeinern und modularisieren Sie Ihren Entwurf ggf. mit neuen Komponenten. III. Überarbeiten Sie Ihren Systementwurf unter dem Gesichtspunkt der Kopplungen, die Sie verwenden wollen. Welche Schnittstellen übergeben welche Businessobjekte? IV. Wenden Sie einen zweiten Architekturstil auf Ihren Systementwurf an bzw. auf eines der Subsysteme. Was verändert sich? 26

27 Wo können wir hier SOA und P2P und C/S Architekturen einordnen? 27

28 Architekturmuster 28

29 Architekturmuster Stellen Praxiserfahrungen zur Verfügung Werden nicht erfunden, sondern entdeckt Ein Pattern setzt (mehrere) Taktiken um Ist immer ein Kompromiss zwischen mehreren Qualitätsattributen Aufgabe des Architekten: das Pattern instanzieren Aktuellen Kontext und Constraints anwenden Sich genau überlegen, wie der Kompromiss des Patterns in der eigenen Lösung auftreten wird 29

30 Beschreibung eines Pattern Kontext Anwendungssituation, die das Problem generiert Problem die verschiedenen Kräfte, die im Problem wirken welche Problemvarianten auftreten können Qualitätsattribute, die erfüllt werden müssen Lösung Elementtypen und ihre Interaktion Topology der Elemente Constraints Erfüllungsgrad der Qualitätsattribute 30

31 Klassische Entscheidungsbereiche Layering einer Applikation Strukturierung der Businesslogik Strukturierung des (webbasierten) User Interfaces Einbindung einer Datenbank Concurrency und Transaction Management Stateful vs. Stateless 31

32 Enterprise Integration Patterns (Hohpe et al.) "Interesting applications rarely live in isolation." EAI patterns stellen Technologie-unabhängige Lösungen zur Integration von Systemen und Komponenten zur Verfügung Unsere Definition vom Anfang: Die Architektur eines Softwaresystems besteht aus seinen Strukturen, der Zerlegung in Komponenten, deren Schnittstellen und Beziehungen untereinander. 32

33 Integrationsmuster 1. File Transfer Anwendungen erzeugen Dateien für gemeinsam verwendete Daten, die ausgetauscht werden 2. Shared Database Anwendungen lesen und schreiben in eine gemeinsame Datenbank 3. Remote Procedure Invocation Anwendungen stellen Schnittstellen zur Verfügung, die extern aufrufbar sind 4. Messaging Anwendungen verwenden ein gemeinsames Messaging System für Datenaustausch und Aufruf 33

34 1. File Transfer Definition des Dateiformats und der Zeitintervalle, in denen die Dateien erzeugt und konsumiert werden Wo Dateien ablegen, wie verwalten, wie mit Änderungen im Datenformat (d.h. Dateiformat) umgehen? 34

35 Vorteile und Nachteile des File Transfer + Dateien als universelles Speichermedium + Minimale Anforderungen an Hardware/Software + Keine Kenntnisse der Applikation notwendig für Integration + Keine weitergehenden Abhängigkeiten zwischen integrierten Applikationen Synchronisation der Daten kann bei Änderungen schnell verloren gehen Ungeeignet für den sehr häufigen Austausch kleinerer Datenmengen (Dateimanagementproblem) 35

36 2. Shared Database Häufigerer Austausch von konsistenten Daten über mehrere Anwendungen Definition und Verbreitung einheitlicher Datenformate Management des Datenaustauschs über Datenbanktransaktionen gesichert Fokus auf DB Schema Definition 36

37 Vorteile und Nachteile der Shared Database + Unterstützung von Datenbankstandards in allen Entwicklungsumgebungen + Synchronisation der Daten gesichert 37 Applikationen müssen an Datenformate angepasst werden Adapter, Transformationen Einigung aller Applikationen auf ein einheitliches Format Externe Applikationen arbeiten oft nur mit ihren eigenen Formaten (Bedarf nach zusätzlichen Adaptern) Datenbank als potentieller single point of failure für alle Applikationen Performanzprobleme

38 3. Remote Procedure Invocation Integration der Funktionalität, nicht nur der Daten Applikationen arbeiten zusammen Applikationen als Komponenten, Datenzugriff gekapselt und über Funktionsschnittstellen verfügbar 38

39 Vorteile und Nachteile der Remote Procedure Invocation + Applikationen können interne Datenformate ändern + Unterschiedliche Schnittstellen können bereitgestellt werden + Einfaches Entwicklungskonzept ("Prozeduraufruf") Abstimmung und Änderung von Schnittstellen über mehrere Applikationsgrenzen kann schwierig sein Aufrechterhalten von veralteten Schnittstellen Performanz- und Zuverlässigkeitsprobleme von Remote Aufrufen ("remote" <> "local") Enge Kopplung der Applikationen ("growing knot") 39

40 4. Messaging Loose Kopplung von Systemen durch häufigen Austausch von kleinen Datenpaketen Unterschiedliche Kommunikationsstile Synchron, Asynchron, Publish-Subscribe Loose Kopplung (auch von Funktionen) trotz vielfältiger Integration mit unterschiedlichsten Austauschformaten 40

41 Vorteile und Nachteile von Messaging + Flexibelste Integrationslösung + Unterstützung durch zahlreiche Technologien + Transformation und Management der Daten innerhalb der Messaging Middleware und nicht in der Applikation Asynchrones Design von Applikationsfunktionen nicht immer einfach Testen und Debugging schwieriger Flexibilität führt zu zahlreichen Folgefragen, die gelöst werden müssen 41

42 Entscheidungen und Pattern für Messaging Wie werden Applikationen an das Messaging System gekoppelt? 42 Applikation Senden Wie wird die Message aus den Applikationsdaten aufgebaut? Wie werden notwendige Transformationen ausgeführt? Empfangen Message Welche Art von Messaging System? Wie werden die richtigen Nachrichten empfangen und an die Applikation übergeben? Message Channel Welche Art von Messaging Channel? Wie erreicht die Message den/die richtigen Empfänger?

43 Aufgabe K4: EAI Pattern anwenden I. Welches EAI Pattern dominiert zurzeit bei der Kolumbus AG? II. Wählen Sie 1-2 EAI Pattern aus und verwenden Sie es in Ihrem weiteren Systementwurf! III. Begründen Sie die Auswahl Ihres/Ihrer Pattern! 43

44 Aufgabe 1: Optionale Hausaufgabe Lesen Sie den Artikel von Pautasso et al. zu SOAP vs. REST. Welche Architekturentscheidungen helfen bei der Beurteilung der beiden Technologien? 44

45 Mehr zu Patterns

46 Arbeitsfragen 1. Was verstehen Sie unter einem Architekturstil und einem Architekturmuster? 2. Erläutern Sie bekannte Architekturstile. 3. Wie werden Architekturmuster beschrieben? 4. Erläutern Sie Beispiele für Integrationsmuster. 5. Diskutieren Sie den Unterschied zwischen Taktiken, Stilen und Mustern. 6. Welche Qualitätsattribute beeinflussen die Auswahl einer synchronen oder asynchronen Kommunkation? 7. Viele P2P Architekturen verwenden late binding der Topology. Welche Qualitätsattribute können das verlangen oder verhindern? 46

47 Arbeitsfragen (Forts.) 8. Worin unterscheiden sich Architekturpattern von Designpattern? 9. SOA beinhaltet dynamic service registry und discovery. Welche Qualitätsattribute werden dadurch positiv oder negativ beeinflusst? 10.Wie setzt die Schichtenarchitektur die folgenden Taktiken um: abstract common services, encapsulate, use an intermediary? 47