ppls

Object-Relation Mapping

• Datenbank: relational, Programmierung: objektorientiert -> nicht kompatibel
• Abbildung ist eine Herausforderung
• Technologien: Hibernate, Java Persistence API (JPA)

• Persistenz Schicht, zwischen Applikation und relationaler Datenbank
• Notifizierungsmechanismus zum konsistenten Abgleich
• Anforderungen:
  • CRUD Methoden
  • Transaktionen (ACID)
  • Lazy Loading (nur laden was benötigt wird)
  • Cursor - Prinzip

• Lade (große) Objekte erst, wenn sie wirklich benötigt werden
• kann auch mit Virtual Proxy umgesetzt werden

• Umsetzung per Resource File, Java Annotations, Reflections, Methoden Signaturen
• Field Injection, Constructor Injection, Setter Injection
• Problem: Wie lang kann übergebende Referenz in Objekt bestehen? Unter welchen Bedingungen kann Referenz injiziert oder ausgetauscht werden?

• eigene Laufzeitumgebung, unabhängig von anderen Microservices
• eigenes Domain Model
• Kommunikation mit anderen (REST, HTTP)
• flexibles Deployment (Docker)
• Nanoservice (wenige Zeilen Code)
• eigenes Datenbanksystem

• kein universelles Datenmodell zwischen Microservices
• vertikale Aufteilung von Funktionen und Daten

• Web Browser kommuniziert mit Web Container (HTTP)
• Web Container besteht aus Servlet und Java Server Faces
• Web Containter kommuniziert mit EJB Container
• Java Application kommuniziert mit EJB Containter (RMI)

• serverseitiges Komponentenmodell zur Realisierung der Geschäftslogik
• realisieren
  • skalierbare
  • transaktionale
  • sichere
  • und wiederverwendbare Applikationen

• Entity (Bean) - persistentes, fachliches Object
• Session Bean
  • Stateless Session Bean
  • Stateful Session Bean
  • Singleton Session Bean
• Message-driven Bean (asynchrone Kommunikation)

• Enterprise Archive (ear) - enthält .war .jar .rar
• EJB-JAR (Enterprise Java Bean Archive, jar) - enthält EJBs
• Web Application Archive (war) - Web-basierten Komponenten

• Session Bean implementiert Use Cases
• musste bis Version 2.x eine Reihe von Interfaces implementieren
• ab 3.0 durch POJO realisiert, Annotations werden verwendet

Entfernter Zugriff erfolgt mehr RMI (Remote Method Invocation).

Annotationen (Folie 28ff)

• @Stateless für Stateless Bean
• @Remote für das Interface welches Remote verwendet werden soll (die EJB implementiert dann das Interface)
• @Local für das Interface welches Lokal verwendet werden soll
• @EJB an eine Variable injiziert dann die lokale EJB in die Variable

• beliebige Zuweisung aus Pool
• Instanzvariablen können, sollten aber besser nicht belegt werden
• Geschäftslogik sollte in einem Methodenaufruf erledigt werden
• Vorteile Pooling:
  • kleine Anzahl Beans kann theoretisch größere Anzahl von Clients bedienen
  • benötigen weniger Server Ressourcen
  • Hohe Skalierbarkeit
  • Auslastung des Application Server sinkt

• haben einen Client bezogenen Zustand
• wird nicht persistent gehalten
• kein Pooling möglich

• es existiert nur eine Session
• Einsparung von Ressourcen
• nicht thread-safe
• Methoden zur Unterbindung nicht performant
• gut für gleichzeitige Lesezugriffe mit wenigen Updates

Lösung (Folie 30)

• synchronized -> inperformant
• Alternativ `@ConcurrencyManagement?
• Vorteil: Read-Lock und Write-Lock
• Read-Lock beliebig viele, aber nicht wenn Write-Lock vorhanden
• Write-Lock nur genau einmal

• Atomicity; nicht zerlegbar; entweder ganz oder gar nicht
• Consistency; eine Transaktion hinterlässt einen konsistenten Datenbankzustand
• Isolation; nebenläufige Transaktionen beeinflussen sich nicht
• Durability; Wirkung einer erfolgreichen Transaktion bleibt dauert in der DB erhalten

• Problem: Aus einer Transaktion können weitere Methoden anderer Session Beans aufgerufen werden; Gültigkeitsbereich einer Transaktion?
• Abhängig von Transaktionsattributen
  • REQUIRED (Default) - neue Transaktion in gleicher Transaktion
  • REQUIRES_NEW - neue Transaktion in eigener Transaktion
  • MANDATORY - neue Transaktion in eigener Transaktion; wenn keine Transaktion existiert -> FEHLER

• Layer
• Peer-To-Peer
• Pipes-And-Filter
• Shared Data
• Client-Server

• Elemente können hierarchisch angeordnet sein
• Zugriff auf Funktionen erfolgt über Interfaces

• lokal
• Verteilt
• durch Mittlerkomponente

Sind zusätzliche Eigenschaften, Richtlinien und Einschränken welche sich nicht unmittelbar aus der Dekomposition ergeben.

Oft durch: Qualitätsanforderungen, technische Anforderungen, grundlegenden Architekturstil, organisatorische Rahmenbedingungen

• Qualitätseinbußen, (un)bewusst falsche oder suboptimale technische Entscheidungen
• Implementationsschulden (Code-Smells), Architekturschulden, Testschulden, Dokumentationsschulden

• Idee: Erstellung von Software durch Komposition von vorgefertigten, unabhängigen Software Komponenten
• (Zusammenbau von Systemen aus einzelnen Teilen)
• Ziel: Reduktion von Kosten und Zeit

• wird implementiert durch ein Objekt
• kann mehrere Interfaces besitzen
• weißt Abhängigkeiten aus

• besitzt eine Implementierung
• kann ein UI besitzen
• kann mehrere REST-Interfaces besitzen
• besitzt einen Datenhaushalt
• hat eine Laufzeitumgebung

• -Entwickler
• -Zusammensteller (zum Teil Endanwender)
  • Entwickelt Applikation durch (Wieder)verwendung von Komponenten
• System-Architekt
  • Setzt LFU für Komponenten auf
  • Einhaltung von Qualitätsanforderungen

Deployment ist wichtigste Eigenschaft einer Komponente!

Standardisiert Müssen standardisierten Komponentenmodell entsprechen; Vorgabe von Schnittstellen, Metadaten, Dokumentation, Zusammenstellungsart, Bereitstellung

Unabhängig Sollte ohne Abhängigkeiten auskommen; falls benötigt sollte die Abhängigkeit spezifiziert sein

Einsetzbar (deployable)Kann in LZU eingesetzt werden; liegen in Binärform vor; LZU baut auf OS auf

Dokumentiert Vollständig dokumentiert, damit Benutzer entscheiden können ob Ansprüche erfüllt sind; Beschreibung Syntax und Semantik

Zusammenstellbar Kann mit (mehreren) anderen zu höherwertigen Komposition zusammengestellt werden; Interaktion über öffentliche Schnittstellen

• Kapselung des Zustands
• Abstraktion
• Generalisierung und Spezialisierung
• Polymorphie

• Komponenten legen keine Datentypen fest
• Implementierung von Komponenten sind verschlossen
• Komponenten sind sprachunabhängig
• Komponenten sind standardisiert

Komponente:

• Binärform
• Wird in LZU deployed
• kann aus LZU entfernt werden
• Deployment während der Laufzeit

Objekt:

• Source Code
• Java: nur Kompolierung der Klasse, dann flexibles Einsetzen in Classpath möglich, keine Verlinkung

Commerciall Off-the-Shelf

• seriengefertigte Komponenten, gleichartig aufgebaut
• geringe bis gar keine Konfiguration
• vollständige Software-Lösung

• Rahmenwerk
• Definiert Software-Architektur
• Enthält Klassen, Bibliotheken und LZU
• nicht unmittelbar ausführbar, hohe Anpassung notwendig