FWP Aktuelle Technologien zur Entwicklung verteilter Java-Anwendungen. Sommersemester Michael Theis, Lehrbeauftragter 1

Transkript

1 FWP Aktuelle Technologien zur Entwicklung verteilter Java-Anwendungen Sommersemester Michael Theis, Lehrbeauftragter 1

2 Wer braucht schon einen Architekten? 2

3 Applikationen benötigen andere Systeme (Consumer) Applikationen unterstützen andere Systeme (Provider) Web UI (HTTP/HTML) Remote Service Interfaces (RMI) Enterprise Application Mainframe based Applications (JCA) Relational Databases (JDBC/JPA) Remote Service Interfaces (RMI) Message-based Interfaces (JMS) Web Service Interfaces (HTTP/SOAP) Message-based Interfaces (JMS) Wie wollen Sie diese Komplexität ohne Architektur bewältigen? 3

4 4

5 Horizontale technische Schichten Vertikale fachliche Schichten Fachmodul A Fachmodul B Fachmodul C Fachmodul D Präsentation Geschäftslogik Enterprise Application Integration 5

6 Wohldefinierte Schnittstellen zwischen den Schichten Zyklenfreie, gerichtete Abhängigkeiten zwischen den Schichten Getrennte Verantwortlichkeiten Lose Kopplung / Hohe Kohäsion Verteilung der Schichten auf verschiedene Lokationen möglich Jede Schicht hat eigenen Namensraum (in Java: Packages) 6

7 Präsentation (Presentation*) Interaktion zwischen Anwendung und Benutzer Anzeige und Bearbeitung von Informationen Geschäftslogik (Business, Domain*) Kern der Anwendungen bestehend aus Diensten in einer Serviceschicht (Service Layer) und Domänenmodell (Domain Model) Integration (Integration, Data Source*) Integration externer Ressourcen Transformation externes Domänenmodell / internes Domänenmodell 7

8 HTTP / HTML Benutzer Benutzeroberfläche für menschliche Benutzer Beinhaltet nur Präsentationslogik Höchste Änderungshäufigkeit innerhalb der Anwendung Rich Client oder Thin Client Präsentation (Presentation) 8

9 Lokal RMI/IIOP HTTP/SOAP HTTP/REST Geschäftslogik (Business) Service Layer Service Domain Model Service Kern der Anwendung Services kapseln Geschäftslogik Lokal: Präsentationsschicht der eigenen Anwendung Entfernt: Andere Anwendungen Services operieren auf einheitlichem Domänenmodell Nutzt Integrationsschicht für Integration von externen Ressourcen Domain Object Domain Object Domain Object 9

10 JPA JCA Lokal Integration (Integration, Data Source) Resource Access Components Repository Adapter Integriert externe Ressourcen Bildet externes Domänenmodell auf internes Domänenmodell ab Kapselt Information über konkrete Integration Welche Datenbank? Welches Kommunikationsprotokoll? Welches externe System? Datenbank HOST 10

11 Domänenmodell Schichtenmodell mit 3 Schichten Bereinigtes Schichtenmodell Präsentation UI- Component Präsentation UI- Component Geschäftslogik Business Service Domain Object Geschäftslogik Business Service Domain Object Integration Integration Component Zyklische Abhängigkeit!!! Integration Integration Component 11

12 User Data base Application Core Business Service Domain Object Main frame System Adapter Port Auch: Ports & Adapter Außenwelt kommuniziert mit Applikation über Ports Applikation kommuniziert mit Außenwelt über Ports Technologiespezifische Adapter hinter Ports übersetzen Kommunikation Applikation kennt keine Details der Außenwelt Außenwelt ist simulierbar 12

13 Aufgebaut aus Komponenten 13

14 Präsentation Faces Servlet View Managed Bean FacesContext Komponenten füllen Geschäftslogik Schichten mit Leben Enterprise Entity Boundary Application Control Integration Schicht bestimmt Komponententyp Repository Adapter 14

15 Präsentation Faces Servlet View Managed Bean FacesContext Klar definierte Abhängigkeiten Geschäftslogik zwischen den Komponenten ohne Zyklen Enterprise Entity Boundary Application Control Integration Repository Adapter 15

16 Präsentation Faces Servlet View Managed Bean FacesContext Geschäftslogik Kommunikation zwischen Schichten nur über Interfaces Enterprise Entity Boundary Application Control Integration Repository Adapter 16

17 Klare Endpunkte für Kommunikation mit der Außenwelt Präsentation Geschäftslogik Faces Servlet View Managed Bean Enterprise Entity Boundary Application FacesContext Control Klare Kommunikationspfade innerhalb der Anwendung Integration Repository Adapter 17

18 Ermöglicht Entkopplung, Kapselung und klare Trennung der Verantwortlichkeiten Erleichtert die Erstellung service-orientierter Applikationen Schafft gemeinsame Sprache zur Kommunikation des Designs Leicht umzusetzen 1 Implementierungsklasse pro Komponente 1 Interface pro Komponente (optional, aber empfehlenswert) Gruppierung in Module/Packages gemäß Konvention 18

19 Entscheidung für Designmodell zu Projektbeginn Wesentliche Modelle: Serviceorientiert (Service Oriented Architecture SOA) Domänengetrieben (Domain Driven Design DDD) Modelle können kombiniert werden, aber ein Modell sollte Hauptmodell sein 19

20 Service Oriented Architecture Services enthalten alle Logik Domänenobjekte sind dumme Datenträger Optimierung für Verteilung bestimmt internes Design Fördert Anti-Pattern Anemic Domain Model * Widerspricht objekt-orientiertem Design Domain Driven Design Domänenobjekte enthalten Daten und Logik Services enthalten nur Logik zur Orchestrierung von Domänenobjekten Fachlichkeit einziger Treiber für internes Design Verteilter Zugriff über Adapter Entspricht objekt-orientiertem Design * Martin Fowler AnemicDomainModel 20

21 21

22 Gemeinsame Patterns und Prinzipien 22

23 Don t call us, we call you! Kontrolle wandert in das verwendete Framework One important characteristic of a framework is that the methods defined by the user to tailor the framework will often be called from within the framework itself, rather than from the user's application code. The framework often plays the role of the main program in coordinating and sequencing application activity. This inversion of control gives frameworks the power to serve as extensible skeletons. The methods supplied by the user tailor the generic algorithms defined in the framework for a particular application. Designing Reusable Classes von Ralph E. Johnson und Brian Foote Journal of Object-Oriented Programming Juni/Juli 1988, S ff 23

24 Präzisierung des Inversion of Control-Patterns u.a. von Martin Fowler Ein sog. Assemblierer löst die Abhängigkeiten zwischen Objekten auf Lose gekoppelte POJOs leben in einem Inversion of Control- Container Container bestimmt Lebenszyklus der Objekte Container löst als Assemblierer die Abhängigkeiten auf 24

25 Implementierungsklasse des Service public class ServiceImpl implements Service public void dosomething() { // Hier wird etwas gemacht } } Interface des Service public interface Service { public void dosomething(); } Consumer ist abhängig vom Service-Interface public class Consumer { private Service service;... public void useservice() { this.service.dosomething(); } 25

26 Traditionell Consumer erzeugt Objekt von ServiceImpl und initialisiert damit Feld service: public class Consumer { private Service service = new ServiceImpl(); Consumer wird abhängig von konkreter Implementierung Mit Dependency Injection Consumer markiert Feld service als Ziel für Dependency Injection: public class Consumer private Service service; Container erkennt annotiertes Feld, erzeugt ein Objekt von ServiceImpl und injiziert Referenz in Feld service Consumer kennt nicht die konkrete Implementierung 26

27 Gemeinsame Patterns und Prinzipien 27

28 Aspekt AOP Proxy Advice Pointcut quellmethode() zielmethode() Methodenaufruf (= Joinpoint) Target Object 28

29 EJB-Container verwendet AOP für Transaktionsmanagement, Zugriffskontrolle und Remoting JAX-WS verwendet AOP für das Mapping von Methodenaufrufen mit Parametern auf SOAP-Nachrichten und umgekehrt JPA verwendet AOP für die Zustandsüberwachung von Entities 29

30 Gemeinsame Patterns und Prinzipien 30

31 Einfaches Prinzip zur Erleichterung der Programmierung übernommen aus RUBY Standardmäßig verwendet die Laufzeitumgebung sinnvolle Voreinstellungen Nur im davon abweichenden Fall muss eine Konfiguration vorgenommen werden 31

32 Stateless Session Beans oder Managed Beans werden unter dem einfachen Klassennamen registriert, falls nichts anderes angegeben Methodenaufrufe eines Enterprise Java Beans laufen immer in einem transaktionalen Kontext (TRANSACTION_REQUIRED) Die Java Persistence Architecture (JPA) mappt automatisch Klassennamen von Entitäten auf Tabellennamen und Feldnamen auf Spaltennamen 32

33 33

34 Verteilung Transaktionen Persistenz Sicherheit Regelt Kommunikation verteilter Anwendung Steuern Zugriff auf transaktionale Ressourcen Stellen Datenkonsistenz sicher Bietet die dauerhafte Speicherung von Daten Bildet Domänenmodell auf relationales Datenmodell ab Schützt die Anwendung vor unberechtigten Zugriffen 34

35 Verteilung 35

36 Don t distribute your objects! Quelle: Martin Fowler Patterns of EAA 36

37 Das Netzwerk ist zuverlässig Latenz[zeit] ist 0 Bandbreite ist unendlich Das Netzwerk ist sicher [Netzwerk-]Topologie ändert sich nicht Es gibt nur einen Administrator Transportkosten sind 0 Das Netzwerk ist homogen Quelle: Peter Deutsch, James Gosling Fallacies of Distributed Computing 37

38 Komplexität Rechner Prozess Rechner Prozess App Rechner Prozess App Prozess Rechner Prozess App Rechner Prozess App App App App Grad der Verteilung 38

39 Skalierbarkeit Ausfallsicherheit Technologiegrenzen Unterschiedliche Standorte Bereitstellung von Diensten für externe Consumer Komposition eigener Dienste aus Diensten externer Provider 39

40 File Transfer Gemeinsame Datenbank Remote Procedure Call Messaging 40

41 Import Anwendungen tauschen Informationen über Dateien aus Anforderungen bestimmen Häufigkeit des Austausches Export App 1 App 2 Gemeinsame Daten 41

42 Anwendungen tauschen Informationen über gemeinsame Tabellen aus Datenbank-Schema bestimmt Datenformat Anwendung 1 Anwendung 2 Anwendung 3 Gemeinsame Daten 42

43 Skeleton Anwendungen kapseln ihre Daten und stellen Interfaces für den Zugriff zur Verfügung Austausch der Informationen erfolgt über synchronen entfernten Methodenaufruf Anforderung mit Eingabeparametern Stub App 1 App 2 Antwort mit Rückgabewert 43

44 Häufiger, unmittelbarer, zuverlässiger und asynchroner Austausch von Nachrichten Flexibelste Integration, erfordert aber Umdenken Messaging System Anforderung Anforderungskanal Anforderung Sender Endpunkt Endpunkt Empfänger Antwort Antwortkanal Antwort 44

45 Transaktionen 45

46 Atomicity Eine Transaktion wird entweder ganz oder gar nicht ausgeführt Consistency Eine Transaktion überführt eine transaktionale Ressource von einem bestehenden konsistenten Zustand in einen neuen konsistenten Zustand Isolation Das Ergebnis einer Transaktion darf für andere Transaktionen solange nicht sichtbar sein, bis diese Transaktion erfolgreich abgeschlossen worden ist. Durability Das Ergebnis einer erfolgreich abgeschlossenen Transaktion muss dauerhaft erhalten bleiben und Abstürze jeder Art überstehen. 46

47 Isolationsgrad Durchsatz Serializable Wiederholte Lesezugriffe liefern gleiche Sätze und gleiche Ergebnismengen Schreib-, Lese- und Bereichsoperationen verursachen Sperren Repeatable reads Wiederholte Lesezugriffe liefern gleiche Sätze aber unterschiedliche Ergebnismengen möglich (Phantom Read) Schreib- und Leseoperationen verursachen Sperren Read committed Lesezugriffe liefern nur committete Sätze Schreiboperationen verursachen Sperren Read uncommitted Lesezugriffe liefern nicht committete Sätze Keine Sperren 47

48 Begin Transaktion beginnt Commit Transaktion endet erfolgreich Beteiligte transaktionale Ressourcen werden verändert Rollback Transaktion bricht nach Fehler ab Beteiligte transaktionale Ressourcen bleiben unverändert 48

49 Bei Aufrufen entfernter Anwendungen wird der Transaktionskontext mit übertragen Aufgerufene Methode kann die die Transaktion des Aufrufers teilen (muss aber nicht) Koordination der Transaktionen übernimmt der aufrufende Container (Applikationsserver) Umsetzung teilweise aufwändig bzw. unmöglich 49

50 ACID skaliert nur bis zu einem gewissen Grad ACID bei verteilten Datenspeichern nur schwierig umzusetzen Verfügbarkeit, Fehlertoleranz und Performance wichtiger als Konsistenz und Isolation BASE ersetzt ACID bei hochskalierenden Datenspeichern Basically Available Soft State Eventual Consistency 50

51 Starke Konsistenz Isolation Fokus auf Commit ACID Konservativ (pessimistisch) Harte Strukturen, lassen sich nur schwer weiterentwickeln BASE Schwache Konsistenz Hohe Verfügbarkeit Best Effort Aggressiv (optimistisch) Weiche Strukturen, lassen sich leicht weiterentwickeln Quelle: Dr. Eric A. Brewer, Towards Robust Distributed Systems PODC Keynote

52 Availability Jeder Client kann immer Lesen und Schreiben CA Relationale Datenbanken Nur 2 Ziele sind erreichbar! AP Cassandra CouchDB Riak Alle Clients sehen die gleichen Daten Consistency CP BigTable, MongoDB Memcache, Redis Partition Tolerance Das System arbeitet erwartungsgemäß trotz Verteilung über mehrere Netzwerk-Partitionen 52

53 Security 53

54 Authentisierung (Wer bin ich?) Identifizierung eines Objekts und die Überprüfung der Identität Identität entspricht Benutzername Identifizierung erfolgt über Credentials Passwort Zertifikat Biometrische Eigenschaften Autorisierung (Was darf ich?) Überprüfung von Berechtigungen eines angemeldeten Benutzers bezogen auf geschützte Ressourcen Berechtigungen entsprechen Rollen oder Gruppen 54

55 Bei Aufrufen entfernter Anwendungen wird der Securitykontext mit übertragen Aufgerufene Methode läuft im gleichen Securitykontext wie der Aufrufer Benutzer muss sich nicht erneut anmelden (Single Sign-On/SSO) Beteiligte Container (Application Server) müssen einander trauen Umsetzung teilweise aufwändig 55

56 Persistenz 56

57 Spalte Klasse feld 1 feld 2 Vererbung Primärschlüssel Tabelle PK PK Zeile Klasse feld 1 feld 2 Komposition 1 Klasse feld 1 feld 2 1..* ORM Beziehungen Indizes Constraints Tabelle PK PK FK FK 57

58 Mapping muss programmiert werden Zugriff auf die Datenbank mit SQL muss programmiert werden Klasse Klasse DAO ORM JDBC DataSource SQL Tabelle Tabelle Tabelle Klasse 58

59 Persistente Klassen werden mit Mapping-Annotationen versehen und mit Datasource verknüpft Persistenzframework führt Mapping durch und generiert SQL zur Laufzeit Klasse Klasse JPA ORM JDBC DataSource SQL Tabelle Tabelle Tabelle Klasse Annotationen Persistence.xml 59

60 Enterprise Application Enterprise Application RDBMS RDBMS NoSQL Relationale Datenbanken stoßen zunehmen an ihre Grenzen Ablage der Daten in einem Datenspeicher nicht mehr zeitgemäß / sinnvoll Moderne Applikationen stützen sich je nach Anforderungen auf unterschiedliche Datenbanken Kenntnisse über alternative Datenspeicher erforderlich NoSQL 60

61 61

62 62

63 Martin Fowler: Patterns of Enterprise Application Architecture Addison Wesley 2003; ISBN Adam Bien: Real World Java EE Patterns: Rethinking Best Practices press.adam-bien.com September 2012; ISBN Gregor Hohpe, Bobby Wolfe Enterprise Integration Patterns Addison Wesley, 2004, ISBN: Eric Evans: Domain Driven Design: Tackling Complexity in the Heart of Software Addison Wesley 2004; ISBN

64 Michael Theis Lehrbeauftragter Hochschule München mobile web 64