Realisierung verteilter Anwendungen: Teil 8 zBeim vorigen Mal: yMultitier-Architekturen: Transaktionen zInhalt heute: yFortsetzung der Einführung zu Multitier-

Präsentation zum Thema: "Realisierung verteilter Anwendungen: Teil 8 zBeim vorigen Mal: yMultitier-Architekturen: Transaktionen zInhalt heute: yFortsetzung der Einführung zu Multitier-"—  Präsentation transkript:

1 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

2 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

3 Transaktionen in J2EE

4 Namensraumverwaltung in J2EE

5 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:

6 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

7 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 - 300 write (A, a) read (B, b) b := b + 300 write (B, b) BOT read (A, a) a := a - 300 write (A, a) BOT read (B, b) b := b + 300 write (B, b) Station S A Station S B Beendigung der globalen Transaktion erfordert commit oder abort für alle lokalen Stationen

8 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.

9 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

10 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

11 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"

12 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

13 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

14 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?"

15 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

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

17 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)

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

19 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

20 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

21 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

22 zAngaben im Deployment- Management- Fenster

23 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"

24 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

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

26 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.

27 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?

28 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)

29 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

30 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

31 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

32 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

33 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

34 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)

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

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