Realisierung verteilter Anwendungen: Teil 8 zBeim vorigen Mal: yMultitier-Architekturen: Transaktionen zInhalt heute: yFortsetzung der Einführung zu Multitier- Architekturen xTransaktionen und Persistenz xSicherheitsaspekte zLernziele: yGrundverständnis für die EJB-Architektur, insbesondere Persistenz und Sicherheit Ralf Möller, FH-Wedel

Rückblick: Transaktionen zACID-Bedingungen zSerialisierbarkeit trotz Nebenläufigkeit zNotwendig: Verwaltung von Sperren (Locks) zNotwendig: Zwei-Phasen-Sperr-Protokoll (2PL) zVerklemmungserkennung und -auflösung zTimeouts für "Ressourcenblockierer" zSoftware-Architektur J2EE

Transaktionen in J2EE

Namensraumverwaltung in J2EE

Nebenläufigkeit und Transaktionen Der erste Teil dieser Vorlesung (5 Präsentationen) baut auf der Vorlesung "P3" von Bernd Neumann an der Universität Hamburg auf. Für eine Vertiefung des Themas verteilte Transaktionen siehe Kapitel 13 aus:

Verteilte Datenbanksysteme Die zunehmende Vernetzung von Datenbanken führt zum Konzept der "verteilten Datenbank". Eine verteilte Datenbank ist eine Sammlung von Informationseinheiten, die auf mehrere über ein Kommunikationsnetz miteinander verbundene Rechner verteilt sind. Station S 2 Kommunikations- netz Station S 1 Station S 4 Station S 3

Transaktionskontrolle in verteilten Datenbanksystemen Verteilte Datenbankverwaltungssysteme (VDBMS) verwalten Transaktionen, die sich über mehrere Stationen (Rechner) erstrecken. Beispiel: Umbuchung eines Betrags von Konto A auf Station S A nach Konto B auf Station S B BOT read (A, a) a := a write (A, a) read (B, b) b := b write (B, b) BOT read (A, a) a := a write (A, a) BOT read (B, b) b := b write (B, b) Station S A Station S B Beendigung der globalen Transaktion erfordert commit oder abort für alle lokalen Stationen

Zweiphasen-Commit-Protokoll 2PC-Protokoll zur EOT-Behandlung in verteilten Datenbanksystemen KKoordinator A 1... A n Agenten (Stationen des verteilten Datenbanksystems) 1.K sendet PREPARE-Nachricht an alle Agenten, um abzufragen, ob diese ihre Transaktion festschreiben können 2.Jeder Agent A i antwortet mit einer der zwei Nachrichten: -READY, falls A i lokale Transaktion festschreiben kann -FAILED, falls A i lokale Transaktion nicht festschreiben kann 3.Wenn K READY von allen Agenten empfangen hat, sendet K COMMIT an alle Agenten und fordert damit zum Festschreiben auf. Falls nicht alle READY innerhalb Timeout-Frist empfangen wurden oder mindestens ein FAILED empfangen wurde, sendet K ABORT an alle Agenten und fordert damit zum Abbruch auf. 4.Agenten quittieren den Erhalt von Nachricht 3 mit ACK (Acknowledgement, Bestätigung) und führen entsprechende EOT- Behandlung durch.

Nachrichtenaustausch beim 2PC-Protokoll KKoordinator A 1... A n Agenten (Stationen des verteilten Datenbanksystems) KK K PREPAREFAILED / READYCOMMIT / ABORT ACK A1A1 A2A2 AnAn A1A1 A2A2 AnAn

Zustandsübergänge beim 2PC-Protokoll Start bereit abge- brochen fest- schreibend fertig EOT: Sende PREPARE an alle Agenten READY von allen Agenten empfangen: commit ins Log sende COMMIT Timeout oder FAILED empfangen: abort ins Log sende ABORT von allen ACK empfangen Koordinator wartend bereit abge- brochen festge- schrieben PREPARE empfangen und lokal alles ok: Log ausschreiben ready ins LOG sende READY COMMIT empfangen: commit ins Log sende ACK ABORT empfangen: abort ins Log sende ACK Timeout oder lokaler Fehler entdeckt: abort ins Log sende FAILED Agent

Transaktionen in der J2EE-Architektur zErleichterung der Anwendungsprogrammierung zAufsetzen einer Transaktion: Was ist zu tun? yDeklaration des Transaktionsanfangs (begin) yAusführung von Ressource-Anfragen und -Updates yDeklaration des Transaktionsendes (commit) zTransaktionen können durch Bean oder durch Container aufgesetzt werden z"Aufsetzen" wird auch Demarkation genannt zJ2EE bietet nur sog. "flache Transaktionen"

Nachteile von Bean-Managed-Transactions zHäufig: Bei "Programmierungenauigkeiten" wird Commit-Anweisung "versehentlich" nicht ausgeführt (etwa bei Exceptions) zLocks werden nicht zurückgegeben zRessourcen werden blockiert zPerformanz sinkt

Container-Managed Transactions zAufsetzen des Transaktionskontextes pro Nachricht an Bean zSteuerung durch Bean-Kontext (Container) zDer Ablauf einer ganzen Methode ist als Transaktion (de)markiert z"Commit" bzw. "abort" folgt automatisch durch Container

Aufsetzen einer Transaktion durch Container zAnforderung der Bean muß deklariert werden zAnforderung wird beim Deployment berücksichtigt zTransaktionskontext wird automatisch pro Methodenaufruf durch Container aufgesetzt z"Wie kriegt denn der Container einen Methodenaufruf mit?"

Lifecycle-Methoden zHome-Interface ycreate(...), remove(...),... yfindByPrimaryKey(...),... zBean-Interface yejbCreate(...), ejbRemove(...),... yejbFindByPrimaryKey(...),... zAufruf der Home-Interface durch Servlet zAutomatisch erzeugter Code ruft entsprechende Bean- Interface-Methoden auf zSignatur von entsprechenden Methoden muß gleich sein

Bean-Methoden, vom Container aufgerufen zejbPostCreate(...) zejbActivate() zejbPassivate() zejbLoad() zejbStore() zsetEntityContext(EntityContext ctx) zunsetEntityContext()

Bean-Methoden, vom Container aufgerufen zejbLoad kann so programmiert werden, daß auf mehrere Datenbasen zugegriffen wird, um die Komponente zu initialisieren zTransaktionen können sich auf mehrere Datenbasen (Ressourcen) beziehen zContainer muß entsprechende Verwaltung bereitstellen (2PC)

Verteilte Transaktionen Context Client Transactional Client T. Object Recoverable Server R.S. T. Object begin, commit abort 2PCTr.- Service

Grundidee der Persistenz bei EJB zACID - Eigenschaften von Transaktionen werden genutzt zInnerhalb einer Transaktion kann mit genau einer Kopie gearbeitet werden zDiese muß vor einem Commit gespeichert werden zEine Kopie je Transaktion DBMS Beans

Persistenz: Alternativen bei EJB Bean-managed zDatenzugriff muß programmiert werden zRoutinen: ejbFind, ejbLoad, ejbStore, ejbRemove, ejbCreate Container-managed zDatenzugriff wird vom Container beim Deployment erzeugt zAutomatisches Mapping nur bei einfacher Abbildung zKeine Implementierung der Methoden, sondern Beschreibung

Container-Managed Persistence am Beispiel zEinträge im Deployment Descriptor yPersistente Felder: price, stock, description, vendor yKey-Felder yTransaktions- management: Angabe der Methoden, die als Transaktion ablaufen sollen

zAngaben im Deployment- Management- Fenster

Container-Managed Persistence am Beispiel zejbCreate(...): "insert into CatTable Values (...)" zejbFindLike(keyword): "select... where ID = $name"; zejbLoad():"select... where ID = $name"; price = resultset.get(" price ")... zejbStore(): "update... where ID = $name" ; zejbRemove(): "delete... where ID = $name"

Container-Managed-Persistence: Nachteile zKein Standard für OO-zu-Relational-Abbildung zFinder-Methoden nur informell beschrieben, daher nur semiautomatsiches Deployment zKeine Standard-Anpassung an bestehende Datenbank-Schemata zEager loading: Gesamter Zustand wird geladen zKein dirty-flag, eager writing

Security zSecurity Attacks zEncryption zHigher-level Security Services yFirewalls yAuthentication yAccess Control yNon-Repudiation ySecurity Auditing zSecurity Services in Object-Oriented Middleware

Security Attacks zMore vital/secret data handled by distributed components. zSecurity: protecting data stored in and transferred between distributed components from unauthorised access. zSecurity is a non-functional requirement that cannot be added as a component but has to be built into all components.

Why are Distrib. Systems insecure? zDistributed components rely on messages sent and received from network zPublic networks are insecure! zIs client component secure? zIs client component who it claims to be? zAre users of calling components really who they claim to be?

Effects of Insecurity zConfidential Data may be stolen, e.g.: ycorporate plans ynew product designs ymedical/financial records (e.g. access bills....) zData may be altered, e.g.: yfinances made to seem better than they are yresults of tests, e.g. on drugs, altered yexamination results amended (up or down)

Need for Security zLoss of confidence: above effects may reduce confidence in systems zClaims for damages: legal developments may allow someone to sue if data on computer has not been guarded according to best practice zLoss of privacy: data legally stored on a computer may well be private to the person concerned (e.g. medical/personnel) record

Threats zCategorisation of attacks (and goals of attacks) that may be made on a system zFour main areas: yleakage: information leaving system ytampering: unauthorised information altering yresource stealing: illegal use of resources yvandalism: disturbing correct system operation zUsed to specify what the system is proof, or secure, against

Methods of Attack zEavesdropping: Obtaining message copies without authority zMasquerading: Using identity of another principle without authority zMessage tampering: Intercepting and altering messages zReplaying: Storing messages and sending them later

Infiltration zLaunch of attack requires access to the system yLaunched by legitimate users yLaunched after obtaining passwords of known users zSubtle ways of infiltration: yVirus xAn unwanted program which places itself into other programs, which are shared among computer systems, and replicates itself yWorm xA computer virus capable of disrupting a computer program. yTrojan horse xAn apparently harmless program containing malicious logic that allows the unauthorized collection, falsification, or destruction of data

Security im J2EE-Kontext zVerschiedene Techniken zur Herstellung bzw. Gewährleistung von Sicherheit im Einsatz zProgrammcode von Komponenten (Beans) sollte Anwendungsfunktionalität realisieren aber nicht Sicherheitsaspekte beinhalten ySicherheitsaspekte sind nicht-trivial yPortabilität von Komponenten nur gewährleistet, wenn Sicherheit durch Kontext (Container) unterstützt

Sicherheit und verschiedene EJB-Rollen zApplication Programmer (Bean provider) yProgramming Style, APIs zApplication Assembler (Bean composer) ySecurity View, Method Permissions zDeployer ySecurity domain, principal delegation zContainer-Provider yTools zSystem Administrator yAccounts (principals)

Diskussion zTransaktionen im J2EE-Kontext zSicherheit im J2EE-Kontext zEs wurde in dieser Vorlesung ein grober Eindruck der Ziele und wesentlichen Ideen vermittelt

Beim nächsten Mal... z... Encryption, Security Services und zBezahlung im Internet