(architektur: = anfang, ursprung + tectum = haus, dach) 9 ...€¦ · book book1 = librarymanager....
TRANSCRIPT
![Page 1: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/1.jpg)
Vorlesung Wintersemester 2008 / 09
Technische Universität München
Institut für Informatik
Lehrstuhl von Prof. Dr. Manfred Broy
Dr. Klaus Bergner, Prof. Dr. Manfred Broy, Dr. Marc Sihling
Softwarearchitektur(Architektur: αρχή = Anfang, Ursprung + tectum = Haus, Dach)
9. Betriebliche Informationssysteme – Teil 2
![Page 2: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/2.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.2
Inhalt
� Rekapitulation Teil 1
� Schichtenarchitekturen
� Datenhaltungsschicht
� Anwendungsschicht
� Aufgaben und Charakteristika
� Dienste und Middleware
� Literaturhinweise
![Page 3: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/3.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.3
Inhalt
� Rekapitulation Teil 1
� Schichtenarchitekturen
� Datenhaltungsschicht
� Anwendungsschicht
� Aufgaben und Charakteristika
� Dienste und Middleware
� Literaturhinweise
![Page 4: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/4.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.4
Logische Schichtenarchitektur
Die Aspekte der fachlichen und technischen Architektur werden vier Schichten zugeordnet. Die Unterstützungsschicht bietet querschnittliche Funktionalität.
FachlicheKomponenten
Datenlayoutzu Objekten
Workflows zuProzessen
GUIs zuAktivitäten
![Page 5: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/5.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.8
Aufgaben der Anwendungsschicht
� Zugriff auf Anwendungsfunktionalität
� Geschäftsobjekte inklusive Daten und Operationen
� Sonstige Funktionalität und Anwendungsdienste
� Basis für darauf aufbauende Schichten
� Unterschiedliche Präsentationen (Multi-Channel Presentation)
� Voraussetzungen für Ansteuerung durch Steuerungsschicht
� Einfaches Programmiermodell für Anwendungsprogrammierer
� Verstecken der Datenhaltungsschicht vor anderen Schichten
� Kapselung proprietärer technischer Dienste der Anwendungsschichthinter Schnittstellen
� Transaktionen als Mittel für Programmierer, so zu entwickeln, als gäbe es nur einen Benutzer und keine Parallelität
![Page 6: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/6.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.9
Aufgabe der Anwendungsschicht
� Anwendungsschicht kümmert sich um technische Belange mit Hilfe dedizierter Manager für technische Dienste.
� Anwendungsschnittstelle stellt uniforme Sicht auf fachliche und technische Komponenten dar.
Datenhaltungsschnittstelle
OODBMS
Hostwrapperobjektrelationaler
Wrapper
HostRDBMS
Datenhaltungs-bzw. Integrations-
Schicht
AnwendungsschichtGeschäftsobjekte
Anwendungsschnittstelle
Fachl. M
anager
Fachl. M
anager
Fachl. M
anager
Security
Mgr
Query M
anager
Nam
ingMgr
Tran
sactionsM.
![Page 7: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/7.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.10
Fragen bei der Realisierung der Anwendungsschicht
1. Wie gestaltet man die Schnittstellen und Implementierung?� Interface-Oriented Design von Komponenten und Abhängigkeiten� Objektorientierte vs. Service-Orientierte Schnittstellen
2. Wie findet und verknüpft man Komponenten?� Service Locator, Komponenten-Infrastrukturen� Middleware für Naming etc.
3. Wie schreibt man transaktionalen Anwendungscode?� Schreiben von Transaktionen� Transaktionsmanager (z.B. JTA, CORBA Transaction Service)
4. Wie kommunzieren entfernte Komponenten miteinander?� Synchrone Kommunikation (z.B. RPC, CORBA, RMI)� Asynchrone Kommunikation über Messaging (z.B. JNDI)� Transaktionales Messaging
5. Welche andere Dienste kann die Anwendungsschicht bieten?� Beispiel CORBA Services
![Page 8: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/8.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.11
Komponenten und Schnittstellen aus Facharchitektur
![Page 9: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/9.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.12
Interface-Oriented Design: Schnittstelle und Implementierung
Einstiegüber Manager
Navigationauf Interfaces
Mehrfach-Ableitung
„kleine“Hilfsklassen
Erzeugung oder Finden
Zugriff aufInterface
Zugriff aufImplementierung(ggf. auch ohneZugriff auf IF)
Einfach-Vererbung
Alternativ-Implementierung
![Page 10: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/10.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.13
Interface-Oriented Design: Abhängigkeiten zwischen Komponenten
„Normale“Abhängigkeit
Basis-komponente
abhängigeKomponente
Schnittstellen-abhängigkeit
Schnittstellen-Ableitung
Implementierungs-Vererbung/Abhggkt.
![Page 11: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/11.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.14
OSGi als Komponenten-Infrastruktur
SS 2008Prof. Dr. Andreas Rausch 2.14
![Page 12: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/12.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.15
Überblick über die OSGi-Architektur
SS 2008Prof. Dr. Andreas Rausch 2.15
Komponenten verwaltenund konfigurieren
Basisplattform kapseln
Dienste bereitstellenund verschalten
![Page 13: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/13.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.16
Verwaltung von Komponenten in OSGi–Bundles
SS 2008Prof. Dr. Andreas Rausch 2.16
![Page 14: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/14.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.17
Zustand von OSGi-Bundles
SS 2008Prof. Dr. Andreas Rausch 2.17
![Page 15: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/15.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.18
Nutzung von Bundles innerhalb von OSGi
SS 2008Prof. Dr. Andreas Rausch 2.18
![Page 16: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/16.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.19
Services als Anwendungs-Bausteine
![Page 17: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/17.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.20
Objektorientierte vs. Service-Orientierte Schnittstellen
Objekt-Orientierung
� Ziele� Geschäftsobjekte und fachliche
Funktionalität umsetzen
� Einfache und effiziente Implementierung
� Eigenschaften� Objektidentität
� Eigens definierte Typen
� Feingranulare Schnittstelle- Attributzugriff und Management
einzelner Assoziationen
- Einfache, beliebig kombinierbare fachliche Operationen
Service-Orientierung
� Ziele� Kontextlose, für sich stehende
Geschäftstransaktionen umsetzen
� Optimierte Kommunikation, möglichst wenige Aufrufe
� Eigenschaften� Fachliche Identifikatoren
� Verwendung von Standardtypen
� Grobgranulare Schnittstelle- Übergabe von Objektgeflechten als
Structures / Value Objects
- Wenige, komplexe Operationen(entsprechend Anwendungsfällen)
![Page 18: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/18.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.21
Objektorientierung vs. Service-Orientierung - Beispiel
Service-Schnittstelle Objektorientierte Anwendungsschnittstelle
Session Facade(z.B. als EJB Session Bean)
![Page 19: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/19.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.22
Value Objects
� Serialisierbare Daten-Objekte ohne weitere Funktionalität� nur Attribute und ggf. get/set-Methoden
� Spiegeln Ausschnitte der Struktur der Geschäftsobjekte
� Ziele und Eigenschaften+ Minimierung der Anzahl der Übertragungen über Netzwerke
+ Abkürzung langer Parameterlisten
+ Leichte Abbildung auf unterschiedliche Programmiersprachen und Formate (z.B. als CORBA-Structs oder XML-Strukturen)
- Zusätzliche Komplexität durch zusätzliche Klassen (� Generierung)
� Implementierung� Zusammenfassung von Objekten anhand von Aggregationsbeziehungen
� Value Objects enthalten typischerweise (nicht änderbare) ID zur eindeutigen Abbildung auf Geschäftsobjekte
![Page 20: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/20.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.23
Value Object - Beispiel
[nach Bi02]
![Page 21: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/21.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.24
Value Object Assembler
:Client:ValueObjectAssembler
:BusinessObject1
:BusinessObject2
:ValueObject
Z.B. eine Session Facadeoder ein Business Object
![Page 22: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/22.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.25
Transaktions-Management
Transaction tx1 = taMgr.newTransaction();
…
try {
tx1.begin();
Reader reader1 = readerManager.findReader("Huber");
reader1.setFirstName("Otto");
Book book1 = libraryManager.findBookByISBN("1-2345-6789-0");
book1.borrow(reader1);
tx1.commit();
} catch Exception e {
…
}
book1
book2book3
reader2
Geschäftsobjekte
Transaktions-Cache tx1
book1'
reader1'
reader1
Transaktions-Cache tx2
reader1''
reader2''…
tx1 tx2
Commit schlägt fehl insbesondere bei Konflikt mit anderer Transaktion.
![Page 23: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/23.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.26
Transaktionsmanagement – keine heile Welt
� Meist können Architektur und verwendete Middleware die ACID-Prinzipien nicht vollständig garantieren.� Transaktionsmodi verletzen Isolation
- Serializable: vollständige Isolation, geringste Performance
- Repeatable Read: Anzahl der Objekte kann sich ändern, neue Objekte aus anderen TA-Commits kommen dazu (Phantom Reads)
- Read Committed: mehrfaches Lesen eines Objekts kann unterschiedliche Werte ergeben (Nonrepeatable Reads)
- Read Uncommitted: keine Isolation, keine TA-Caches, höchste Performance; inkonsistente Zwischenstände sichtbar (Dirty Reads)
� Keine Atomarität bei verteilten Transaktionen- Siehe letzte Vorlesung.
� Anwendungscode muss auf Eigenheiten beim Transaktions-management Rücksicht nehmen
- Transaktionskontext möglich klein halten …
![Page 24: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/24.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.27
Anti-Beispiel: MasterList
� Transaktionsgesteuertes eCommerce-System
� Fachliche Funktionalität� Bearbeiter erzeugen und bearbeiten Aufträge
� Aufträge werden in eine MasterList eingetragen
� Transaktion für Erstellen eines neuen Auftrags und Einfügen in MasterList
� Problem� Viele parallele Transaktionen gehen schief
� Lösung� Verhindern, dass immer auch MasterList in Transaktionskontext gerät
� Attribut numberOfOrders streichen
� Richtung der Verweise umkehren
![Page 25: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/25.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.28
Middleware zum Transaktionsmanagement
� Stand-Alone-Systeme� Eigene Schnittstellen zum TA-Management
� Keine Teilnahme an verteilten Transaktionen
� Beispiele: einfache RDBMS, ODBMS
� Standardisierte Transaktions-Infrastrukturen� Implementieren Standard-Schnittstellen wie JTA, CORBA OTS
� Kommunizieren über Standard-Protokolle wie XA
� Teilnahme an verteilten Transaktionen in den Rollen:- Transaktionskoordinator
- Transaktionale Ressource
� Beispiele: RDBMS, ODBMS, Message Services, Application Server
![Page 26: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/26.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.29
Client-Managed vs. Container-Managed Transactions
Client-Managed
� Transaktionsklammern werden explizit gesetzt
� Transaktionen über Factoryerzeugen oder bekommen
� begin, commit, abort
� Vor-/Nachteile+ Feingranulare Steuerung möglich
- Mehr Möglichkeiten für Fehler
Container-Managed
� Transaktionsklammern werden konfigurationsgesteuert gesetzt
� Transaktionen werden durch Container / AOP injiziert
� Geeignet insbesondere für Service-Schnittstellen
� Vor-/Nachteile+ Einheitlichkeit, Einfachheit
- Starres Schema
Insgesamt gilt: Ein System sollte möglichst nur eine einzige, einheitliche Strategie für das Transaktionsmanagement haben.
![Page 27: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/27.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.30
Finden von Komponenten und Diensten
� Service Locator
� Zentrale Anlaufstelle, um Manager oder Dienste zu finden
� Kapselt Middleware für Naming, Trading oder Verzeichnisdienste
� Kann zusätzliche Aufgaben übernehmen (z.B. Caching)
� Verschalten durch Komponenten selbst
� Nur erforderlich, wenn Anwendungswissen erforderlich ist
� Verschalten durch eigenen Service oder Container
� Dependency Injection stellt Unabhängigkeit der Komponenten sicher
� Container kann Zugriff auf Verzeichnisdienste übernehmen
Service bzw.Komponente
Service Locator
Cache
JNDI
COS Naming
COS Trader
registriertsich
findetandere
![Page 28: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/28.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.31
Middleware für Naming, Directory, Trading
� Naming Service� Binden von Namen an Objekte� Finden von benannten Objekten� Beispiel: COS Naming Service
� Directory Service� Zusätzlich hierarchische Kontexte (Directories) und Namens-Pfade� Zusätzlich Attribute zu Objekten� Beispiel: JNDI-Schnittstelle, ActiveDirectory, LDAP-Server
� Trading Service� Erlaubt es, Kriterien für Objekte und Dienste anzugeben� Beispiel: Gib mir Service, der
- Interface BankingService implementiert- Verfügbarkeit 95% hat
� Beispiele:- COS Trader für CORBA Objects- UDDI für Web-Services im Kontext von Unternehmensdiensten
![Page 29: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/29.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.32
Beispiel: Schnittstelle Naming Service
interface NamingContext {
// Definiere neues Binding zwischen n und obj. void bind (in Name n, in Object obj);
// Binde existierenden Namen n an anderes Objekt obj.void rebind (in Name n, in Object obj);
// Lösche Binding von n.void unbind (in Name n);
// Finde an Namen n gebundenes Objekt.Object resolve (in Name n);
// Erzeuge neuen (leeren) Namenskontext.NamingContext new_context ();
// Zerstöre Namenskontext.void destroy ();
// Weitere Methoden (z.B. zum Auflisten) nicht gezeigt...
}
![Page 30: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/30.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.33
Konfigurationsgesteuerte Verschaltung durch Container
<bean id="logfactory"
class="org.apache.commons.logging.LogFactory"
factory-method="getFactory">
</bean>
<bean id="objectmodelmanager">
...
</bean>
<bean id="xmlfileiolog" factory-bean="logfactory" factory-method="getInstance">
<constructor-arg>
<value>com.foursoft.fourever.xmlfileio</value>
</constructor-arg>
</bean>
<bean id="xmlfileiomanager" class="com.foursoft.fourever.xmlfileio.impl.XML
FileIOManagerImpl"
factory-method="createInstance"
destroy-method="destroy">
<constructor-arg>
<ref bean="xmlfileiolog"/>
</constructor-arg>
<constructor-arg>
<ref bean="objectmodelmanager"/>
</constructor-arg>
</bean>
Konfigurationsdateien dieser Art
definieren in einem XML-Format
deklarativ die Verschaltung der
diversen Komponenten
(also den „Glue“)
Komponenten werden über
Factories erzeugt (hier nun endlich
die Komp.-implementierung)
Erst nach Berücksichtigung aller
Abhängigkeiten entscheidet
Spring über die Reihenfolge der
Initialisierung aller Komponenten
Spring stellt weiterhin einen
„Application Context“ zur
Verfügung, über den nach
Komponenten gesucht werden
kann („dependency lookup“)
![Page 31: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/31.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.34
Verteilungssicht der Anwendungsschicht
� Unter einer gemeinsamen Anwendungsschnittstelle ist die räumliche Verteilung der Anwendungsobjekte transparent.
� Technische Mechanismen müssen daher in geeigneter Form kommunizieren (z.B. Transaction Manager, Security Manager, Query Manager).
Anwendungsschnittstelle
Rechner X Rechner Y
Middleware
Middleware
![Page 32: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/32.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.35
Synchrone Kommunikation
� Sender und Empfänger blockieren beim Ausführen der Operationen zum Senden bzw. Empfangen.
� Eigenschaften:� Enge Kopplung von Sender und Empfänger.
� Empfänger muss bereitstehen: Wenigrobust, nicht gut skalierbar.
� Einfaches Programmiermodell für Anwendungs-programmierer (keine parallele Ausführung).
� Hohe Abhängigkeit insbesondere im Fehlerfall.
� Voraussetzung: � Sichere und schnelle Netzverbindungen sind
verfügbar.
� Empfangender Prozess ist verfügbar.
Prof. Dr. Andreas Rausch SS 2008 2.35
![Page 33: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/33.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.36
Synchrone entfernte Kommunikation
� Entfernte Methodenaufrufe über Stubs und Skeletons
� Middleware� Remote Procedure Calls (RPC) für prozedurale Sprachen
� CORBA ORB / IIOP als objektorientierte Variante
� RMI und andere proprietäre Verfahren
� SOAP/WSDL als standardisierte XML-basierte Variante
� Implementierung� Stubs und Skeletons explizit codieren und generieren
� Container-gesteuert hinzukonfigurieren
![Page 34: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/34.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.37
Marshalling und Unmarshalling
� Unter Marshalling versteht man die Transformation von Daten in ein Übertragungsformat.
� Unter Unmarshalling versteht man die Rücktransformation eines Zeichen-oder Bytestroms in Daten einer konkreten Programmiersprache.
� Verantwortlich für die Aufgabe sind Stubs und Skeletons der Middleware.
� Ebenfalls möglich in speziellen Infrastrukturen: Verschicken von Objekten mit Methoden (erfordert gleichartige Laufzeitumgebung).
![Page 35: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/35.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.38
Der entfernte Prozeduraufruf (RPC)
� Ermöglicht einem Clientprozess den entfernten Aufruf einer Prozedur auf einem Serverprozess.
� Die Kommunikation erfolgt nach dem Anfrage-/Antwort-Prinzip.� Das Modell setzt auf verschiedenen Hilfsprozeduren auf.
Prof. Dr. Andreas Rausch SS 2008
Clientprozess
Clientprozedur
Stub Prozedur
Serverprozess
Serverprozedur
Skeleton Prozedur
2.38
![Page 36: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/36.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.39
Der entfernte Methodenaufruf (RMI)
� Ermöglicht es einem Objekt, Methoden auf einem entfernten Objekt aufzurufen.
� Die Kommunikation erfolgt nach dem Anfrage-/Antwort-Prinzip.� Modell setzt auf dem Proxy Pattern auf.
Prof. Dr. Andreas Rausch SS 2008
Clientprozess
Clientobjekt
Stub
Serverprozess
Serverobjekt
Server-Skeleton
2.39
![Page 37: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/37.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.40
Entwicklungsprozess bei „manuellem“ RMI
![Page 38: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/38.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.41
Konfiguration eines RMI-Servers mit Spring-Container
<bean id=„libraryService“
class=„LibraryServiceImpl"> … </bean>
<bean class="org.springframework.
remoting.rmi.RmiServiceExporter">
<property name="serviceName„
value=„RMILibraryService"/>
<property name="service„
ref=„libraryService"/>
<property name="serviceInterface" value="example.LibraryService"/>
<property name="registryPort„
value="1199"/>
</bean>
Lokaler Service
Server-Mechanismus
Name desRemote Service
Zugrundeliegenderlokaler Service
Zugrundeliegendeslokales Interface
RMI-technischeKonfiguration (Port)
Lokaler Service als POJO
Erstellung RMI-Server durch Konfiguration
![Page 39: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/39.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.42
Konfiguration des zugehörigen Clients mit Spring
public class Client {
private LibraryService l;
public void setLibraryService(
LibraryService ls) { l = ls; } …
<bean class="example.Client">
<property name=“libraryService“
ref=“libraryService"/>
</bean>
<bean id="libraryService"
class="org.springframework.
remoting.rmi.RmiProxyFactoryBean">
<property name="serviceInterface"
value="example.LibraryService"/>
<property name="serviceUrl" value=
"rmi://HOST:1199/RMILibraryService"/>
</bean>
Client erhältLibraryService …
… via DependencyInjection von Container
Client-Mechanismus
ZugrundeliegendesInterface
RMI-technischeKonfiguration (Server)
![Page 40: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/40.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.43
CORBA ORB als weiteres Beispiel für Middleware
� Ortstransparenz� Entfernte Objekte über netz-eindeutige Identifikatoren bereitstellen� Transparente Vermittelung von Aufrufen zwischen Objekten in
verschiedenen Prozessen an unterschiedlichen Orten� Kontexte weiterreichen (Transaktionen, Sicherheit)
� Statische und dynamische Methodenaufrufe:� Methodenaufrufe statisch beim Kompilieren definieren oder dynamisch
zur Laufzeit „entdecken“
� Freie Wahl von Programmiersprachen:� Sprache der Aufrufe unabhängig von Implementationssprache des
Servers durch Trennung von Schnittstelle und Implementierung� Sprachenunabhängige Datentypen
� Selbstbeschreibendes System:� Interface Repository als Verzeichnis der Schnittstellen, die von Servern
angebotene Methoden und deren Parameter beschreiben (in IDL)
![Page 41: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/41.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.44
Synchrone Kommunikation
� Sender und Empfänger blockieren beim Ausführen der Operationen zum Senden bzw. Empfangen.
� Eigenschaften:� Enge Kopplung von Sender und Empfänger.
� Empfänger muss bereitstehen: Wenigrobust, nicht gut skalierbar.
� Einfaches Programmiermodell für Anwendungs-programmierer (keine parallele Ausführung).
� Hohe Abhängigkeit insbesondere im Fehlerfall.
� Voraussetzung: � Sichere und schnelle Netzverbindungen sind
verfügbar.
� Empfangender Prozess ist verfügbar.
Prof. Dr. Andreas Rausch SS 2008 2.44
![Page 42: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/42.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.45
Asynchrone Kommunikation
� Sender ist nicht blockiert; der Prozess kann nach dem Senden derNachricht sofort weiterarbeiten.
� Antworten sind optional:� Der Sender erhält bei Gelegenheit das Ergebnis asynchron.� Der Sender holt sich bei Gelegenheit aktiv das Ergebnis.
� Eigenschaften:� Lose Koppelung von Prozessen.� Empfänger muss beim Senden
nicht empfangsbereit sein.� Komplizierter zu implementieren,
dafür robuster und skalierbarer.
� Realisierung über Warteschlangen(Message Queuing).
� Es gibt unterschiedliche MEPs(Message Exchange Patterns).
Prof. Dr. Andreas Rausch SS 2008 2.45
![Page 43: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/43.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.46
Message Queuing, Message Passing, Messaging
� Message Queuing ist ein Programmiermodell zum asynchronen Transport von Daten zwischen Prozessen.
� Die Daten werden innerhalb von Nachrichten (Messages) übertragen.
� Message Passing arbeitet auf der Basis von Warteschlangen:
� Nachrichten werden vom Sender in eine Warteschlange gelegt
� und werden an den Empfänger weitergeleitet.
� Die Warteschlange arbeitet nach dem FIFO-Prinzip.
Prof. Dr. Andreas Rausch SS 2008
Sender Empfänger
Warteschlange
Nachricht Nachricht
2.46
![Page 44: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/44.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.47
Message-Queuing-Varianten
� Point-to-point: Die Nachrichtenübertragung findet zwischen zwei festgelegten Servern statt. Message Exchange Patterns sind� One-Way-Pattern: Sender schickt Nachricht an Empfänger.� Request-Reply-Pattern: Analog zu synchroner Kommunikation (Sender
wartet nach Senden auf Antwort), über zwei One-Way-Nachrichtenrealisierbar.
� Request-Callback-Pattern: Sender spezifiziert Callback-Funktion, die zum Empfang aufgerufen wird und arbeitet erstmal weiter.
� Broadcasting: Eine Nachricht wird an viele Server versendet. � Publish-Subscribe-Pattern: Empfänger melden sich explizit an.
Prof. Dr. Andreas Rausch SS 2008 2.47
![Page 45: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/45.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.48
Request-Reply-Modell
� Das Verschicken einer Nachricht (Request) und das Empfangen einer Antwortnachricht (Reply) erfolgen als eine Einheit: Nur wenn beide erfolgreich ablaufen, war auch die Kommunikation erfolgreich.
� Ermöglicht eine (fachlich gesehen) synchrone Kommunikation über eine (technisch gesehen) asynchrone Middleware.
� Eine mögliche Umsetzung erfolgt über unterschiedliche Warteschlangen für Request- und Reply-Nachrichten.
Prof. Dr. Andreas Rausch SS 2008
Sender Empfänger
Verwalter
Sende-
nachricht
Antwort-
nachricht
Reply-
Warteschlange
Request-
Warteschlange
2.48
![Page 46: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/46.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.49
Publish-Subscribe-Modell
� Prozesse erhalten Rollen als Publisher bzw. Subscriber.� Subscriber abonnieren Nachrichten zu einem Thema.� Publisher veröffentlichen Nachrichten zu einem Thema.� Broker übernehmen die Vermittlung.� Eine mögliche Realisierung erfolgt durch themenspezifische
Warteschlangen.
Prof. Dr. Andreas Rausch SS 2008
Publisher
Vermittler (Broker)
Warteschlange zu
Thema a
Warteschlange zu
Thema b
Subscriber
Subscriber
Nachricht b
Thema b
Nachricht b
Thema a
2.49
![Page 47: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/47.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.50
Beispiel für Empfangen einer asynchronen Nachricht mit JMS
Class Client {
…
subscriber = jmsSession.
createTopicSubscriber(topic);
subscriber.setMessageListener(
new Listener());
…
}
class Listener implements MessageListener {
void onMessage(Message msg){
if(msg instanceof TextMessage) {
… handle TextMessage …
}
}
Client registriertsich als Empfänger …
… und spezifiziertCallback-Objekt
asynchron (vom Thread des JMS-Servers) gerufeneCallback-Methode Unterschiedliche
Nachrichtenarten möglichz.B. Text, XML, Objekt
![Page 48: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/48.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.51
Asynchrone entfernte Kommunikation über Nachrichten
� Queues und Topics können auf Wunsch persistent gehalten werden
� Transaktionales Messaging stellt sicher, dass Nachrichten ankommen
� Wann asynchrone Kommunikation in betrieblichen Infosystemen?� Unidirektionale Nachrichten � Notifikation von Clients
� Erhöhte Parallelität � Sender muss nicht warten
� Erhöhte Performanz � Tuning von Message Queues einfach, Vermeidung des schwergewichtigen Two-Phase-Commit
p1 p2DB1DB2
DB3
Transaktionskontext 1 Transaktionskontext 2
![Page 49: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/49.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.52
Zwischenzustände und Kompensation
� Möglichkeit 1:� TA1: Vorfall anstoßen
- Auf Zielsystem Betrag auf Zielkonto verbuchen.
- Abbuchungsnachricht für Quellkonto verschicken.
� TA2: Nachricht bearbeiten- Auf Quellsystem Abbuchungs-
nachricht empfangen.
- Betrag von Quellkonto abbuchen.
� Möglichkeit 2:� TA1: Vorfall anstoßen
- Auf Quellsystem Betrag X von Quellkonto abbuchen.
- Verbuchungsnachricht für Zielkonto verschicken.
� TA2: Nachricht bearbeiten- Auf Zielsystem Verbuchungs-
nachricht empfangen.
- Betrag X auf Zielkonto verbuchen.
� Nachteile des asynchronen transaktionalen Messaging: ACID verletzt� Nicht Atomar und nicht Isoliert: Fachlich relevante „Zwischenzustände“ können
entstehen und müssen beim Anwendungsentwurf berücksichtigt werden.
� Rollback von Geschäftsvorfällen durch Entwickler zu lösen: Kompensations-Aktionen müssen entworfen werden.
� Beispiel: Überweisung eines Geldbetrags von Quellkonto zu Zielkonto, Quell- und Zielkonto werden auf zwei Systemen verwaltet.
![Page 50: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/50.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.53
Middleware zum Messaging
� Oft als Integrations-Middleware verwendet� Systeme bieten Adapter oder folgen Standards
� Persistente Speicherung der Nachrichten in Standard-Datenbanken
� Implementierungsvarianten� als Dienst in Application Server integriert
� als Standalone-System
� als Enterprise Service Bus (ESB)
� Bekannteste Standards und Vertreter� CORBA Event Service, CORBA Notification Service
� Java Messaging Service (JMS)
� Microsoft Message Queue
� IBM MQSeries
� Sopera ESB
![Page 51: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/51.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.54
Message Oriented Middleware (MOM)
� Ist die Middleware-Technologie zum Message-Queuing-Programmiermodell.
� MOM bietet neben der rein asynchronen Kommunikation weitere Mechanismen und Dienste:� Unterstützung der verschiedenen Messaging-Modelle� Warteschlangenverwaltung, Verbindungsmanagement� Quality-of-Service Zusicherungen (QoS)
Prof. Dr. Andreas Rausch SS 2008
Empfänger
Middleware Protokoll (proprietär)
Protokollstack
Warteschlangen-
verwalter
Sender
Zugriffs-
schnittstelle
Warteschlangen
Zugriffs-
schnittstelle
2.54
![Page 52: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/52.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.55
ESBs als allgemeine Kommunikationsinfrastruktur
� ESBs sind als grundlegende Integrationsinfrastruktur für die Verbindung von Anwendungen und Services gedacht
� Unterstützung unterschiedlicher Protokolle und Schnittstellen� synchrone Service-Aufrufe� asynchrones Messaging
� Spezifikation von Regelnfür Routing und Daten-transformation
� Verwaltung der Servicesund Regeln in einemRepository
� Überwachung, Proto-kollierung, Debugging
� Zusatzdienste wieWorkflow-Management
![Page 53: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/53.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.59
Object Management Architecture und CORBA Services
Object Request Broker (ORB)
Application
Objects
CORBAfacilitiesVertical Common Facilities
Horizontal Common Facilities
CORBAservicesNaming
Trader
Life Cicle
Transaction
Concurrency
Licensing
TelecommunicationUser
Interface
![Page 54: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/54.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.60
Basisdienste bei CORBA
� Life Cycle Service stellt Operationen zur Erzeugung, zum Kopieren, Verschieben und Löschen von Objekten bereit.
� Collection Service ermöglicht es, Objekte in Gruppen zu manipulieren. (Arrays, Bäume, Stacks, ...)
� Relationship Service ermöglicht die Definition von Beziehungen zwischen Objekten.
� Property Service erlaubt es, einem Objekt dynamisch eine Eigenschaft zuzuweisen (z. B. einen Titel oder ein Datum).
� Concurrency Control Service ermöglicht Objekten den Zugriff auf gemeinschaftlich genutzte Ressourcen mit Hilfe von Sperren (Locks).
� Security Service stellt Sicherheitsmechanismen bereit. Er unterstützt z. B. Authentifizierung und Zugriffskontrolle.
� Time Service stellt z. B. Interfaces zur Verfügung, um sich in einer verteilten Umgebung miteinander zu synchronisieren oder zeitabhängige Ereignisse zu definieren.
� Licensing Service erlaubt es, die Nutzungsdauer von Komponenten zu messen und entsprechend abzurechnen.
![Page 55: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/55.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.61
Basisdienste bei J2EE
![Page 56: (Architektur: = Anfang, Ursprung + tectum = Haus, Dach) 9 ...€¦ · Book book1 = libraryManager. findBookByISBN("1-2345-6789-0"); book1.borrow(reader1); tx1.commit();} catch Exception](https://reader033.vdocuments.mx/reader033/viewer/2022060609/60600450ba037c3ba7548bf9/html5/thumbnails/56.jpg)
Softwarearchitektur verteilter Systeme – 9. Betriebliche Informationssysteme - Teil 2 9.62
Literaturhinweise
� [Bi02] Adam Bien: J2EE Patterns, Addison-Wesley, 2002.
� [EJB3] Sun Microsystems: J2EE Website. http://java.sun.com/j2ee, 2005.
� [jBPM] jBPM WfE Homepage, http://www.jboss.com/products/jbpm
� [Sie02] J. Siegel, An Overview Of CORBA 3.0, Object Management Group, 2002.
� [Spr05] Rob Harrop, Jan Machacek: Pro Spring, apress, 2005.� [Spring] Spring Framework Homepage, http://www.springframe-
work.org
� [WfMC] Workflow Management Coalition Homepage, http://www.wfmc.org