Realisierung verteilter Anwendungen: Teil 8

Beim vorigen Mal: Multitier-Architekturen: Transaktionen

Inhalt heute: Fortsetzung der Einführung zu Multitier-

Architekturen Transaktionen und Persistenz Sicherheitsaspekte

Lernziele: Grundverständnis für die EJB-Architektur,

insbesondere Persistenz und Sicherheit

Ralf Möller, FH-Wedel

Rückblick: Transaktionen

ACID-BedingungenSerialisierbarkeit trotz NebenläufigkeitNotwendig: Verwaltung von Sperren (Locks)Notwendig: Zwei-Phasen-Sperr-Protokoll (2PL)Verklemmungserkennung und -auflösungTimeouts für "Ressourcenblockierer"Software-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 desThemas verteilteTransaktionen 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 S2

Kommunikations- netzStation S1 Station S4

Station S3

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 SA nach Konto B auf Station SB BOT

read (A, a)a := a - 300write (A, a)read (B, b)b := b + 300write (B, b)BOT

read (A, a)a := a - 300write (A, a)

BOTread (B, b)b := b + 300write (B, b)

Station SA Station SB

Beendigung der globalen Transaktion erfordert commit oder abort für alle lokalen Stationen

Zweiphasen-Commit-Protokoll2PC-Protokoll zur EOT-Behandlung in verteilten

DatenbanksystemenK KoordinatorA1 ... An 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 Ai antwortet mit einer der zwei Nachrichten:

- READY, falls Ai lokale Transaktion festschreiben kann

- FAILED, falls Ai 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

K KoordinatorA1 ... An Agenten (Stationen des verteilten Datenbanksystems)

K K K

PREPARE FAILED / READY COMMIT / ABORT ACK

A1

A2

•••

An

A1

A2

•••

An

Zustandsübergänge beim 2PC-ProtokollStart

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

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

Erleichterung der Anwendungsprogrammierung

Aufsetzen einer Transaktion: Was ist zu tun? Deklaration des Transaktionsanfangs (begin) Ausführung von Ressource-Anfragen und -Updates Deklaration des Transaktionsendes (commit)

Transaktionen können durch Bean oder durch Container aufgesetzt werden

"Aufsetzen" wird auch Demarkation genanntJ2EE bietet nur sog. "flache Transaktionen"

Nachteile von Bean-Managed-Transactions

Häufig: Bei "Programmierungenauigkeiten" wird Commit-Anweisung "versehentlich" nicht ausgeführt (etwa bei Exceptions)

Locks werden nicht zurückgegebenRessourcen werden blockiertPerformanz sinkt

Container-Managed Transactions

Aufsetzen des Transaktionskontextes pro Nachricht an Bean

Steuerung durch Bean-Kontext (Container)Der Ablauf einer ganzen Methode ist als

Transaktion (de)markiert"Commit" bzw. "abort" folgt automatisch

durch Container

Aufsetzen einer Transaktion durch Container

Anforderung der Bean muß deklariert werdenAnforderung wird beim Deployment

berücksichtigtTransaktionskontext wird automatisch pro

Methodenaufruf durchContainer aufgesetzt

"Wie kriegt denn der Container einen Methodenaufruf mit?"

Lifecycle-Methoden

Home-Interface create(...), remove(...), ... findByPrimaryKey(...), ...

Bean-Interface ejbCreate(...), ejbRemove(...), ... ejbFindByPrimaryKey(...), ...

Aufruf der Home-Interface durch Servlet Automatisch erzeugter Code ruft entsprechende

Bean-Interface-Methoden auf Signatur von entsprechenden Methoden muß gleich

sein

Bean-Methoden, vom Container aufgerufen

ejbPostCreate(...)ejbActivate()ejbPassivate()ejbLoad()ejbStore()setEntityContext(EntityContext ctx)unsetEntityContext()

Bean-Methoden, vom Container aufgerufen

ejbLoad kann so programmiert werden, daß auf mehrere Datenbasen zugegriffen wird, um die Komponente zu initialisieren

Transaktionen können sich auf mehrere Datenbasen (Ressourcen) beziehen

Container muß entsprechende Verwaltung bereitstellen (2PC)

Verteilte Transaktionen

Context

ClientTransactional

Client

T.Object

RecoverableServer

R.S.T.

Object

begin,commit

abort

2PCTr.-Service

Grundidee der Persistenz bei EJB

ACID - Eigenschaften von Transaktionen werden genutzt

Innerhalb einer Transaktion kann mit genau einer Kopie gearbeitet werden

Diese muß vor einem Commit gespeichert werden

Eine Kopie je Transaktion

DBMS

Beans

Persistenz: Alternativen bei EJB

Bean-managedDatenzugriff muß

programmiert werden

Routinen:ejbFind, ejbLoad, ejbStore, ejbRemove, ejbCreate

Container-managedDatenzugriff wird vom

Container beim Deployment erzeugt

Automatisches Mapping nur bei einfacher Abbildung

Keine Implementierung der Methoden, sondern Beschreibung

Container-Managed Persistence am Beispiel Einträge im Deployment Descriptor

Persistente Felder: price, stock, description, vendor

Key-Felder Transaktions-

management:Angabe der Methoden, die als Transaktion ablaufen sollen

Angabenim Deployment-Management-Fenster

Container-Managed Persistence am Beispiel

ejbCreate(...): "insert into CatTable Values (...)" ejbFindLike(keyword):

"select ... where ID = $name"; ejbLoad(): "select ... where ID = $name";

price = resultset.get(" price ") ... ejbStore(): "update ... where ID = $name" ; ejbRemove(): "delete ... where ID = $name"

Container-Managed-Persistence: Nachteile

Kein Standard für OO-zu-Relational-AbbildungFinder-Methoden nur informell beschrieben,

daher nur semiautomatsiches Deployment Keine Standard-Anpassung an bestehende

Datenbank-SchemataEager loading: Gesamter Zustand wird geladenKein dirty-flag, eager writing

Security

Security Attacks Encryption Higher-level Security Services

Firewalls Authentication Access Control Non-Repudiation Security Auditing

Security Services in Object-Oriented Middleware

Security Attacks

More vital/secret data handled by distributed components.

Security: protecting data stored in and transferred between distributed components from unauthorised access.

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

Distributed components rely on messages sent and received from network

Public networks are insecure!Is client component secure?Is client component who it claims to be?Are users of calling components really who

they claim to be?

Effects of Insecurity

Confidential Data may be stolen, e.g.: corporate plans new product designs medical/financial records (e.g. access bills....)

Data may be altered, e.g.: finances made to seem better than they are results of tests, e.g. on drugs, altered examination results amended (up or down)

Need for Security

Loss of confidence: above effects may reduce confidence in systems

Claims for damages: legal developments may allow someone to sue if data on computer has not been guarded according to best practice

Loss of privacy: data legally stored on a computer may well be private to the person concerned (e.g. medical/personnel) record

Threats

Categorisation of attacks (and goals of attacks) that may be made on a system

Four main areas: leakage: information leaving system tampering: unauthorised information altering resource stealing: illegal use of resources vandalism: disturbing correct system operation

Used to specify what the system is proof, or secure, against

Methods of Attack

Eavesdropping: Obtaining message copies without authority

Masquerading: Using identity of another principle without authority

Message tampering: Intercepting and altering messages

Replaying: Storing messages and sending them later

InfiltrationLaunch of attack requires access to the

system Launched by legitimate users Launched after obtaining passwords of known

usersSubtle ways of infiltration:

Virus An unwanted program which places itself into other programs,

which are shared among computer systems, and replicates itself Worm

A computer virus capable of disrupting a computer program. Trojan horse

An apparently harmless program containing malicious logic that allows the unauthorized collection, falsification, or destruction of data

Security im J2EE-Kontext

Verschiedene Techniken zur Herstellung bzw. Gewährleistung von Sicherheit im Einsatz

Programmcode von Komponenten (Beans) sollte Anwendungsfunktionalität realisieren aber nicht Sicherheitsaspekte beinhalten Sicherheitsaspekte sind nicht-trivial Portabilität von Komponenten nur gewährleistet,

wenn Sicherheit durch Kontext (Container) unterstützt

Sicherheit und verschiedene EJB-RollenApplication Programmer (Bean provider)

Programming Style, APIsApplication Assembler (Bean composer)

Security View, Method PermissionsDeployer

Security domain, principal delegationContainer-Provider

ToolsSystem Administrator

Accounts (principals)

Diskussion

Transaktionen im J2EE-KontextSicherheit im J2EE-KontextEs wurde in dieser Vorlesung ein grober

Eindruck der Ziele und wesentlichen Ideen vermittelt

Beim nächsten Mal ...

... Encryption, Security Services undBezahlung im Internet