Daniel Gosch & Hannes Stornig. Überblick DICOM Problembeschreibung Fragestellungen Software Prototyp.

Präsentation zum Thema: "Daniel Gosch & Hannes Stornig. Überblick DICOM Problembeschreibung Fragestellungen Software Prototyp."—  Präsentation transkript:

1 Daniel Gosch & Hannes Stornig

2 Überblick DICOM Problembeschreibung Fragestellungen Software Prototyp

3 Überblick Bachelorarbeit Anforderungsbeschreibung Anforderungen an das System DICOM Problembeschreibung Fragestellungen Software Prototyp

4 Detaillierter Überblick über einzelne Probleme und Fragestellungen Lösungsansätze zu konkreten Fällen präsentieren Grundlagenforschung für ein Framework Kritische Punkte im Entwicklungsprozess

5 Framework entwickeln Persistent Fehlerfrei Verarbeitung von DICOM Files Prozesse in Transaktionen gliedern Fehlverhalten -> Rollback Konsistenter Datenstand des Framework

6 Technische Ansprüche an die Infrastruktur Applikation Server (Glasfish 3.x) Java Development Kit 1.6 Relationale Datenbank Postgres 9.x

7 Überblick DICOM Allgemein Was ist DICOM DICOM File Problembeschreibung Fragestellungen Software Prototyp

8 Medizinische Bilder für Diagnostik Art der Bildgebung Organe, Skelett, Muskel, Blutgefäße Verfahren Röntgen Magnet Resonanz Tomographie Positronen Emissions Tomographie

9 Richtlinien für digitale Medien Standard für medizinische Bilder -> Bilder in einem einheitlichen Format speichern

10 Bild (Röntgen) / Bilderserie (MRT) Liste von Datenelementen Informationen zum Patienten Identifikationsnummer Informationen zur Aufnahme DICOM Standard definiert exakt welche Informationen enthalten sein müssen bzw. welche optional sind Jedes Bild verfügt über die notwendigen Informationen

11 Überblick DICOM Problembeschreibung Programmiersprache Persistenz Queue Datenbankanforderungen Performance Fragestellungen Software Prototyp

12 JAVA Enterprise Edition Funktionalität Klassenbibliotheken des Toolkits dcm4che2 Objektorientierte Programmiersprache GNU Lizenz Eigene Laufzeitumgebung -> verschiedenen Rechenarchitekturen einsetzbar

13 Java Persistence API (JPA) -> Speicherung der Daten in eine Datenbank Daten bleiben über die Ausführungszeit des Frameworks erhalten Java Transaktion API (JTA) –> Zugriff auf Daten Gewährleistet vollständige oder keine Übertragung der Daten Rollback im Fehlverhalten Konsistenter Datenstand

14 Datenstruktur FiFo (First in First out) Verfahren Erste Datei die in die Queue aufgenommen wird ist auch die erste die diese wieder verläst Konstante Reihenfolge add() pool() peek() Queue

15 ACID Richtlinien Transaktionen müssen Atomar -> ganz oder gar nicht Konsistenz -> definierte Integritätsbedingungen (Primärschlüssel / Fremdschlüssel) Isoliert -> Transaktionen Dauerhaft -> nach Transaktionsende persistent zur Verfügung stehen

16 DICOM Files mehrere 100 MB groß Persistierung in der Datenbank Schlechte Performance Speicherung auf sekundär Datenträger Surrogaten (Platzhalterobjekte) in der Datenbank Referenz auf DICOM File Bedarfsfall Informationen nachladen

17 Überlegungen: Mehrere Referenzen auf ein DICOM File Ein und dasselbe DICOM File kommt mehrmals vor Großer Speicherbedarf Wenn ein DICOM File in mehreren Queues Queue 1Queue 2Queue 3

18 Lösung: Nur beim ersten mal ins Filesystem schreiben Surrogat bekommen beim kopieren in eine weitere Queue nur mehr eine Referenz auf das DICOM File Queue 1Queue 2Queue 3

19 Wann darf ein DICOM File gelöscht werden? afterCompletion() Methode des Transaktions-Managers Methodenaufruf nach jeder abgeschlossenen, jedoch noch nicht beendeten Transaktion Überprüfung auf Referenz in der Datenbank auf ein DICOM File Falls NEIN -> Freigabe zur Löschung

20 Überblick DICOM Problembeschreibung Fragestellungen Data Queue (DQ) Processing Node (PN) Beziehungen zwischen PN und DQ Verarbeitungsgraph Helper Processing Node Transaktionsmanagement Software Prototyp

21 Datenhaltung -> Prinzip einer Queue Umsetzung dieser wird als Data Queue bezeichnet Prototyp -> DcmQueue Data Queue kümmert sich um Datenhaltung und Reihenfolge

22 Managed die Zugriffe auf die Data Queue Repräsentiert Geschäftslogik 2 Arten Producer -> Inputseitig => Erzeugung der Data Queue bzw. Surrogaten Consumer -> Outputseitig => Verwaltung und Löschung der Data Queue bzw. Surrogaten

23 Verschiedene Möglichkeiten Nutzen für unser Framework im Mittelpunkt 4 Fälle Vorteile Nachteile

24 Fall 1 Kardinalität 1 zu 0 PN steht mit keiner DQ in Verbindung -> nicht möglich Objekte an die DQ zu senden Output Input

25 Fall 2 Kardinalität 1 zu 1 Jede PN ist genau mit einer DQ verbunden Jede DQ ist genau mit einer PN verbunden Kommunikation zwischen PN und DQ möglich -> komplexes Verhalten nicht möglich Output Input

26 Fall 3 Kardinalität 0…n zu 0…n Jede PN steht mit beliebig vielen DQ in Verbindung Jede DQ steht mit beliebig vielen PN in Verbindung Komplexe Kommunikation möglich -> kann jedoch schnell unübersichtlich Ausmaß annehmen => komplexe Verfahren zur Datenbewältigung Output Input

27 Fall 4 Kardinalität 1 zu 0…n Jede PN kann mit beliebig vielen DQ in Verbindung stehen Jede DQ jedoch nur mit einer PN Ausreichende Kommunikation zwischen PN und DQ -> Verhinderung zu komplexer Strukturen Output Input

28 Anzahl der DQ welche durch PN repräsentiert werden hängt von der Art der PN ab Normalfall PN hat ein oder mehrere Input und Output DQ`s PN ist für den Datenfluss zwischen den einzelnen DQ verantwortlich Jede DQ hat dabei eine genau definierte Input als auch Outputseite und steht immer mit genau einer PN in Verbindung

29 Zwei Typen von PN haben nur eine Input- bzw. eine Outputseite Jene die sich am äußeren Rand des Verarbeitungsgraphen befinden Producer PN können Daten empfangen und in den Verarbeitungsgraphen einfügen Consumer PN können Daten aus dem Verarbeitungsgraphen in ein File System speichern

30

31 Vereinigung / Merging Objekte unterschiedlicher DQ`s werden durch die HPN auf eine DQ zusammengefasst

32 Verteilung / Sharing Objekte einer DQ werden durch die HPN auf mehrere DQ`s verteilt

33 Aufteilung / Splitting Ein Objekt wird durch die HPN an unterschiedliche DQ`s gesendet und unterschiedlich verarbeitet Bsp.: ein Objekt wird anonymisiert und pseudonymisiert

34 Container Managed Transaktion (CMT) EJB Container verwaltet automatisch Transaktionen innerhalb einer EJB Klasse oder Methode Entscheidet selbstständig wann eine Transaktion beginnt bzw. diese wieder beendet wird ohne explizite Declaration Transaktionskontext wird durch den EJB Container bestimmt Jede Methode läuft unter separater Transaktion

35 Im Falle eines Fehlers Rollback System Exeption, Exeptions welche speziell dafür vorgemerkt sind oder die Methode setRollbackOnly Jederzeit konsistenter Datenstand

36

37 Container steuert Transaktionen weitgehend selbst Mittels Callback auf Verhalten des Container Einfluss nehmen @afterBeginn, @beforeCompletion und @afterCompletion Bieten Möglichkeiten Prozeduren durchzuführen die nicht automatisch vom Container durchgeführt werden

38 Überblick DICOM Problembeschreibung Fragestellungen Software Prototyp Überblick Interface DcmQueueProducerServiceRemote Interface DcmQueueConsumerServiceRemote Komponentendiagramm Sequenzdiagramm

39 Prototyp des Frameworks names DcmSPL Prototyp bietet Möglichkeit Warteschlange (Queue) erstellen Übergabe von DICOM Dummy Files an das Framework Persistierung der DICOM Dummy Files ins File System Übergibt Queue eine Referenz auf das DICOM Dummy File Bearbeitungsknoten können modular implementiert werden Konsistenten Datenstand

40 Inputseitig Methoden zur Erzeugung und Befüllung der DcmQueue creatDcmQueue() removeDcmQueue() addDcmFile() findDcmQueue()

41 Outputseitig Methoden zur Verwaltung der DcmQueue findDcmQueue() removeDcmQueue() removeDcmFile() findDcmFile() peekDcmFile() poolDcmFile()

42 EJB Client greift auf EJB`s des DcmSplService zu EJB werden mittels JPA und JTA in die relationale Datenbank geschrieben bzw. aus ihr gelesen

43 Erstellung einer neuen dcmQueue Client greift mittels Producer Remote Interface auf dcmQueueService zu dcmQueueService erzeugt neue dcmQueue Entity Manager persistiert diese in die Datenbank

44 Werner Eberling / Jan Leßner, Enterprise JavaBeans 3.1: Das EJB Praxisbuch für Ein- und Umsteiger in: Hanser Carl (Hg.) München / Wien 2011 Eric Jendrock, Ian Evans, Devika Gollapudi, Kim Haase, William Markito Oliveira, Chinmayee Srivathsa The Java EE 6 Tutorial Oracle USA 2012

45