DE102004057305B4

DE102004057305B4 - Pipeline zum Datenaustausch zwischen medizinischen Bildapplikationen

Info

Publication number: DE102004057305B4
Application number: DE102004057305A
Authority: DE
Inventors: Detlef Becker; Ralph Mayr; Falk Tintemann
Original assignee: Siemens AG
Current assignee: Siemens Healthcare GmbH
Priority date: 2004-10-05
Filing date: 2004-11-26
Publication date: 2008-05-15
Anticipated expiration: 2024-11-27
Also published as: DE102004057305A1; US20060101154A1; US7673067B2

Abstract

Verfahren zum Transfer von Daten von Objekten von zumindest einer Source-Applikation (10) an zumindest eine Sink-Applikation (12), umfassend:
– Initiieren des Transfers der Daten durch einen Requester (R),
– Steuerung eines Datenstroms durch einen Serializer-Controller (SC),
– Sukzessives Verarbeiten der Daten für den Transfer durch einen Pipeline Mechanismus, was zumindest folgende Schritte umfasst:
– Zerlegen der verschiedenen Bestandteile eines Objekts im Datenstrom vor dem Transfer in einzelne Chunks, mittels einer Serializer-Funktion (S), welche eine Objektstruktur der zu übertragenden Daten kennt, und nach dem Transfer Wiederzusammensetzen der Chunks zu einem Datenstrom, mittels der Serializer-Funktion (S), und
– Ausführen der physikalischen Datenübertragung durch eine Carrier-Funktion (Ca),
wobei eine Reihenfolge der zu transferierenden Objekte auch während des Transfers dynamisch an Anforderungen der Sink-Applikation (12) angepasst werden kann.

Description

Die Erfindung bezieht sich auf ein Verfahren, eine Vorrichtung und eine Systemanordnung zum Transfer von Daten, insbesondere medizinischen Daten, wie Bilder, dreidimensionale Bildern, Videoaufnahmen, demografische Patientendaten oder Bilder verschiedener bildgebender medizinischer Geräte, zwischen einer Source-Applikation und einer Sink-Applikation. Darüber hinaus ist die Erfindung auf ein Verwalten des Datentransfers gerichtet.
Die Erfindung betrifft insbesondere einen Pipeline-Mechanismus, der zum sukzessiven Verarbeiten der Daten für den Transfer bestimmt ist und verschiedene Verarbeitungsstufen bzw. Funktionen umfasst.
Müssen zwischen zwei Applikationen große Datenvolumina ausgetauscht werden, so ist ein Datenmanagement notwendig, das einen flexiblen und einen effizienten Transfer der Daten ermöglicht.
Das hauptsächliche Anwendungsfeld der vorliegenden Erfindung liegt auf dem Gebiet der Medizintechnik. Es sind jedoch auch alle anderen Anwendungsgebiete möglich, die einen Austausch von Daten zwischen Applikationen eines Systems erfordern, wie zum Beispiel in der Prozesstechnik oder Fertigungstechnik.
Die Probleme, die bei einem oben erwähnten Datenaustausch zwischen zwei Applikationen bestehen, liegen vorwiegend in der begrenzten Zeit für den Datenaustausch, in der begrenzten Netzwerkkapazität, in einer begrenzten Netzwerkperformance, in verschiedenen Datenformaten zwischen den Applikationen und in einer begrenzt zur Verfügung stehenden Computerperformance. Neben weiteren Parametern schränken die vorstehend ge nannten Größen den Austausch großer Datenvolumina ein und können deshalb zu Problemen führen.
Ein weiteres Anforderungsprofil liegt in der Flexibilität und Konfigurierbarkeit des Datentransfermechanismus, da möglichst unterschiedliche Szenarien in dem Datenaustauschmodell abgebildet werden sollen. Beispielsweise soll es in verschiedenen Fällen möglich sein, zu bestimmen bzw. einzustellen, ob eine bestimmte Datenaustauschleistung eingehalten werden soll oder dass die Datenübertragung innerhalb einer maximalen Zeitdauer erfolgt.
Kommunizieren beispielsweise zwei PACS-Applikationen (Picture Archiving Communication System) miteinander, so müssen medizinische Bilddatenserien, die beispielsweise von einem CT (Computertomograph) oder einem Kernspingerät erfasst worden sind, an andere Applikationen an unterschiedlichen Positionen innerhalb des Netzwerkes übertragen werden.
Zu diesem Zweck wurden bisher bei Systemen nach dem Stand der Technik unterschiedliche Transfermechanismen eingesetzt, die alle auf dem DICOM-Standard basierten. Da dieser Standard doch sehr komplex ist und die bisherigen Systeme nicht flexibel genug sind, um an aktuelle und häufig wechselnde Anforderungen anpassbar zu sein, ist die mit bisherigen Systemen erreichbare Performance häufig nicht zufriedenstellend, da bisher alle Konfigurationen der beiden kommunizierenden Applikationen auf Übereinstimmung getestet werden mussten. So werden zum Verbindungszeitpunkt die von den jeweiligen Kommunikationspeers bzw. Applikationen benötigten Transfererfordernisse ausgehandelt. Während des anschließenden Transfers gibt es keine definierte Änderungs- und/oder Steuerungsmöglichkeit mehr. Dies macht bisherige Systeme sehr unflexibel.
Die Applikation, die die angeforderten Daten empfängt, hat die Daten in der Regel auch weiter zu verarbeiten. Deshalb ist es sinnvoll, wenn die empfangende Applikation auch den Transfer und/oder den Datenfluss bestimmen kann, und z.B. festlegen kann, in welcher Reihenfolge die Dateneinheiten gesendet werden sollen, dass die anschließende Weiterverarbeitung der Daten unterstützt wird. Diese Einflussmöglichkeit besteht bei bisherigen Systemen im Stand der Technik nicht.
Von da her ist es wünschenswert, ein System zu schaffen, das einen Datenaustausch zwischen zwei Applikationen ermöglicht, bei dem ein maximaler Durchsatz erreichbar ist und auch große Transfervolumina bearbeitet werden können. Weiterhin sollte es möglich sein, dass der Datentransfer unabhängig von dem Transfermedium ist, wie beispielsweise von dem Netzwerk oder der Art des Netzwerkes (z.B. TCP/IP), von seriellen Verbindungen (z.B. USB etc) oder Offline-Medien (z.B. DVD). Des Weiteren sollte ein asynchrones Verhalten möglich sein, so dass auch lang laufende Aufträge asynchron ausgeführt werden können und ein solcher Auftrag im Bedarfsfall auch gelöscht werden kann. Darüber hinaus sollte es möglich sein, das System in jegliche bestehende Systeme zu integrieren, bei denen ein Austausch von großen Datenvolumina notwendig ist. Das heißt, das System sollte einfache Schnittstellenprofile aufweisen. Weiterhin sollte es möglich sein, dass das System separat, das heißt unabhängig, von einem Datenmanagementsystem bzw. von einer Datenmanagementapplikation und einem Client erfolgt. Darüber hinaus sollte eine Status- bzw. Zustandsanzeige möglich sein, so dass alle Teilnehmer eines Datenaustauschauftrages über den Status anhängiger Datenaustauschaufträge benachrichtigt werden. Dies hat den Vorteil, dass der Anwender zusätzliche Informationen über anstehende Datenaustauschaufträge erhält und somit besser informiert ist. Auch sollte das System wahlweise einen Austausch von separaten Datenobjekten unterstützen und einen Austausch von Streaming-Daten, bei denen mehrere Datenobjekte zusammengefasst sind, und die Steuerung des Datenflusses von zumindest einem Teilnehmer ermöglichen. Weiterhin sollte berücksichtigt werden, dass der Datentransfer bzw. der Austausch von Daten im Allgemeinen sehr fehleranfällig ist, da verschiedene Fehlerquellen existieren (Fehler beim Sendesystem, Fehler beim Empfangssystem oder Fehler bei dem gewählten Datenübertragungskanal etc.). Deshalb sollte das System möglichst fehlertolerant, stark konfigurierbar und aktuelle Transfererfordernisse anpassbar sein.
Vorteilhafter Weise berücksichtigt die vorliegende Erfindung all die vorstehend genannten Punkte und Probleme und kennzeichnet sich darüber hinaus durch die vorstehend genannten Vorteile.
Sollte bisher ein Datenaustausch zwischen zwei Applikationen, die insbesondere zur Verarbeitung von medizinischen Bilddaten ausgelegt sind, erfolgen, so musste die Kommunikation bzw. der Datenaustausch von Hand vorbereitet (konfiguriert) werden, bevor er ausgeführt werden kann. Dieses Vorgehen ist fehleranfällig. In der Regel sind bisher die notwendigen Schritte nicht standardisiert.
Die US 2003/0210711 A1 beschreibt ein Verfahren und eine Vorrichtung zum Übertragen von relativ großen Dateien, wie beispielsweise Videodaten, über eine reservierte TCP/IP Verbindung. Dabei wird eine Mehrkanalpipeline innerhalb einer highspeed Verbindung zwischen einem Quelleknoten zu einem Zielknoten hergestellt. Die zu übertragenden Datei wird in Chunks vorbestimmter Größe geparst, denen eine Nummer zugeordnet wird und die über jeweils einen Pipelinekanal übertragen zu dem Zielknoten übertragen werden, wo aus den Chunks die Datei wieder zusammengesetzt wird. Dieses Verfahren hat aber den Nachteil, dass die Grösse der Chunks statisch vorbestimmt ist und somit die Datei willkürlich unterteilt wird. Daher ist es erforderlich alle Chunks zu übertragen bevor die Datei weiter verwendet werden kann.
Die US 2004/0003147 A1 beschreibt ein System zur Optimierung des Datentransfers von einer Anwendung zu einem Netzwerk-Subsystem innerhalb eines kernelbasierten Betriebssystems, wie z.B. UNIX. Dabei werden Datenblocks dynamisch in ver schiedene Größen unterteilt, je nachdem wie viel Pufferspeicher augenblicklich zur Datenübertragung zur Verfügung steht. Dieses System passt die Datengröße lediglich den Netzwerkerfordernissen an, die Anpassung hängt aber nicht von dem Inhalt der zu übertragenden Daten ab.
Die US 2002/0191785 A1 beschreibt eine Vorrichtung und ein Verfahren zum Verschlüsseln und Entschlüsseln von Daten, wobei ein digitaler Auszug in Chunks erzeugt wird. Der digitale Auszug wird dabei beim Entschlüsseln verwendet, um authentische Daten zu identifizieren. Die digitalen Auszüge oder Chunks werden dabei an die zu übertragenden verschlüsselten Daten angehängt, was die zu übertragenden Datenmenge erhöht.
Um die vorstehend genannten Nachteile nach den bisherigen Verfahren nach dem Stand der Technik zu vermeiden und die vorstehend erläuterten wünschenswerten Aspekte eines Datentransfers zu ermöglichen, hat sich die vorliegende Erfindung zur Aufgabe gesetzt, einen Weg aufzuzeigen, mit dem ein Transfer von Daten von zumindest einer Source-Applikation an zumindest eine Sink-Applikation möglich ist, wobei ein sukzessives bzw. stufenweises Verarbeiten der Daten in Bezug auf den Transfer möglich ist, so dass auch große Datenvolumina schnell und zuverlässig und mit hoher Übertragungsleistung ausgetauscht, verschiedene Datenformate verarbeitet und weitere Umwandlungen bzw. Konversionen und weitere Manipulationen auf den Daten zum Zwecke der Datenübertragung ausgeführt werden können, so dass die Daten bei der empfangenden Sink-Applikation unverändert empfangen werden können, wobei weiterhin zusätzliche Datenaustauschinformationen bereitgestellt werden können.
Diese Aufgabe wird durch die Verfahren, Vendungen und Vorrichtungen gemäß den beiliegenden Hauptansprüchen gelöst.
Insbesondere wird die Erfindung durch ein Verfahren zum Transfer von Daten, insbesondere von medizinischen Bilddaten, von zumindest einer Source-Applikation an zumindest eine Sink-Applikation gelöst, umfassend:

– Initiieren des Transfers der Daten durch einen Requester (R),
– Steuerung eines Datenstroms durch einen Serializer-Controller (SC),
– Sukzessives Verarbeiten der Daten für den Transfer durch einen Pipeline Mechanismus, was zumindest folgende Schritte umfasst:
– Zerlegen der verschiedenen Bestandteile eines Objekts im Datenstrom vor dem Transfer in einzelne Chunks, mittels einer Serializer-Funktion (S), welche eine Objektstruktur der zu übertragenden Daten kennt, und nach dem Transfer Wiederzusammensetzen der Chunks zu einem Datenstrom, mittels der Serializer-Funktion (S), und
– Ausführen der physikalischen Datenübertragung durch eine Carrier-Funktion (Ca),

Darüber hinaus wird die Erfindung auch von einem umfassenderen Verfahren gelöst, das auf ein Verwalten des Datentransfers ausgerichtet ist. Dann umfasst das Verfahren zusätzlich noch eine Controller Funktion, die eine Vorbereitungsphase für den Datentransfer steuert und/oder überwacht und ein Message System, das alle relevanten Statusinformationen bezüglich des Datentransfers sammelt und insbesondere Statusveränderungen an beteiligte Module weiterleitet.
Grundsätzlich entspricht die jeweilige Funktion in dem erfindungsgemäßen Verfahren dem jeweiligen Modul der erfindungsgemäßen Vorrichtung. Die Controller Funktion des Verfahrens entspricht somit z.B. dem Controller der erfindungsgemäßen Vorrichtung. Alle Merkmale, die in Zusammenhang mit der Vorrichtung genannt werden, sind auch auf das Verfahren zu übertragen und vice versa.
Der Controller und das Message System sind zentrale Bauteile. Sie sind vorzugsweise in einer hierarchisch höheren Ebene angeordnet, als die einzelne Komponenten der Pipeline.
Der Controller ist die zentrale Einheit und verwaltet den gesamte Transfer, angefangen von der Auswahl der Kommunikationspeers, also den Applikationen, über die Erstellung einer Kommunikationsverbindung für den Datentransfer bis hin zum Bereitstellen von Kontroll- und Überwachungsmechanismen. Der Controller ist deshalb in einer hierarchisch übergeordneten Ebene über den anderen Modulen der Pipeline und/oder auf der Ebene der Applikationen und des Message Systems eingegliedert.
Durch die zentrale Ausbildung des Controllers bzw. der Controller Funktion ist es möglich, dass die für den jeweiligen Transfer passenden und optimal ausgelegten Transferkonfigurationen verwendet werden können. So kann ein Peer andere Transfererfordernisse aufweisen, als ein anderer Peer. Des Weiteren können sich die Peers hinsichtlich den informationstechnologischen Fähigkeiten (z.B. vorhandene Installationen, Speicher etc.), den Transferbeschränkungen (z.B. nur verschlüsselte Übertragung möglich) und dem zu verarbeitenden Datenformat unterscheiden. All diese Gesichtspunkte fließen bei der Auswahl und Bestimmung der Transferkonfigurationen ein und könne so berücksichtigt werden. Damit ist eine dynamische Auslegung des Transfers möglich, der an die jeweiligen Erfordernisse der Applikationen, an die zu transferierenden Daten und/oder an Kommunikationsverbindungen angepasst ist.
Der Controller ist auch zuständig für das Initiieren des Transferverbindungsauf- und abbaus und damit für die Transfer-Infrastruktur, sowie für das Überwachen des realen Datentransfers.
Bevor der eigentliche Pipeline Mechanismus eingesetzt wird, um die Daten zu übertragen, tätigt der Controller in einer Vorbereitungsphase alle notwendigen Einstellungen und/oder Konfigurationen und dies vorzugsweise automatisch. An die Vorbereitungsphase schließt sich dann die eigentliche Transferphase an, in der die Daten über die Pipeline übertragen werden.
Das Message System sammelt und verteilt alle transferbezogenen Statuszustände und -veränderungen an alle beteiligten Komponenten bzw. Module oder Funktionen. Vorzugsweise betreffen Nachrichten, die über das Message System vermittelt werden, Statusinformationen bezüglich des Transfers und sind an die beteiligten Applikationen gerichtet. Es ist jedoch auch möglich zusätzliche Nachrichten über das Message System zu verwalten. Zusätzlich zu der Informationsvermittlung über das Message System können Daten auch direkt zwischen den beteiligten Modulen ausgetauscht werden.
Das hauptsächliche Anwendungsgebiet der vorliegenden Erfindung betrifft die Verarbeitung von medizinischen Bilddaten bzw. Bilddatenserien. Es ist jedoch auch möglich, die Erfindung auf alle weiteren Anwendungsgebiete zu übertragen, die einen Datenaustausch zwischen zwei Applikationen eines Netzwerkes erfordern, der flexibel und anpassbar sein sollte.
Der Begriff „Source-Applikation" ist als „Sender" der zu übertragenden Daten und der Begriff „Sink-Applikation" ist als „Empfänger" der übertragenen Daten zu verstehen. Der „Requester" oder die „Requester-Applikation" ist als der Initiator der Übertragung zu lesen.
Der erfindungsgemäße Pipeline Mechanismus umfasst mehrere Verarbeitungsstufen und ist nahezu vollständig symmetrisch ausgebildet, das heißt er umfasst auf der Seite der Sink-Applikation dieselben Module wie auf der Seite der Source- Applikation, nur in umgekehrter Reihenfolge. Er dient also dazu, die Daten für den Datentransfer vorzubereiten und so zu strukturieren, dass eine möglichst schnelle, anpassbare und hoch-konfigurierbare Datenübertragung von großen Datenvolumina möglich ist. Bis auf die Serializer-Controller-Funktion, die ausschließlich auf der Seite der Source-Applikation bereitgestellt ist, ist die Pipeline hinsichtlich ihrer sonstigen Module symmetrisch ausgebildet.
In der bevorzugten Ausführungsform umfasst der Pipeline-Mechanismus die Serializer-Funktion, die dazu bestimmt ist, den Datenfluss zu serialisieren, das heißt in aufeinander folgende, separate Chunks zu zerlegen, bzw. nach der Übertragung, die zerlegten Chunks wieder zu einem Datensatz zusammenzusetzen. Darüber hinaus umfasst der Pipeline-Mechanismus eine Carrier-Funktion, die auf der Ebene der Transportschicht angeordnet ist. Die Carrier-Schnittstelle ist das Bindeglied zwischen den symmetrischen Teilen der Pipeline, den beiden Teilen der Transferkette. Die Carrier-Funktion deckt die physikalische Datenübertragung ab, das heißt z.B. die Drahtverbindung oder die drahtlose Verbindung mit den entsprechenden Protokollen. Die Carrier-Funktion ist so ausgelegt, dass sie zumindest die Transportschicht des ISO-OSI-Netzwerk-Referenzmodelles umfasst. In einer alternativen, vorteilhaften Ausführungsform ist die Carrier-Funktion zusätzlich so ausgelegt, dass sie neben der Transportschicht auch die Netzwerkschicht des ISO-OSI-Referenzmodelles umfasst.
Die Carrier-Funktion weist keine Beschränkungen auf hinsichtlich des Transfermediums oder hinsichtlich des Transfermechanismus. Damit ergibt sich erfindungsgemäß der Vorteil, dass der gesamte Transfermechanismus nicht auf ein bestimmtes Transfermedium oder einem bestimmten Transfermechanismus bzw. ein bestimmtes Transportprotokoll festgelegt ist, so dass die Erfindung weitreichende Anwendungsmöglichkeiten hat und in eine Vielzahl von unterschiedlichen bestehenden Systemen integriert werden kann.
In einer vorteilhaften alternativen Ausführungsform besteht der Pipeline-Mechanismus nicht nur aus der Serializer-Funktion und der Carrier-Funktion, sondern weist zusätzlich noch eine Converter-Funktion auf, die ausgelegt ist, um unterschiedliche Datenformate zu konvertieren. Kann beispielsweise die Source-Applikation andere Datenformate verstehen bzw. verarbeiten als die Sink-Applikation, so ist es sinnvoll, in die Pipeline eine Converter-Funktion einzubauen, um die unterschiedlichen Datenformate ineinander überführen zu können. In einer bevorzugten Ausführungsform umfasst der Pipeline-Mechanismus zwei Converter, einen auf der Seite der Sink-Applikation und einen auf der Seite der Source-Applikation. Mit der Anordnung von zwei Convertern in der Pipeline ist es möglich, ein Zwischenformat für die Übertragung der Daten zu verwenden, so dass ein Sende-Datenformat in das Zwischenübertragungs-Datenformat und das Zwischenübertragungs-Datenformat in das Empfangs-Datenformat der Sink-Applikation umgewandelt wird. Diese Ausführungsform ist zwar etwas aufwändiger und komplexer, da zwei Converter beteiligt sind, bietet aber den Vorteil, dass eine Flexibilität hinsichtlich des Datentransfers erreicht wird. So können beispielsweise Bilder komprimiert übertragen werden, so dass höhere Transfer-Raten – selbst bei einem langsameren Transfermedium – erzielt werden können unter Verwendung von Kompressions-Algorithmen. In einer alternativen Ausführungsform sind nicht zwei Converter in der Pipeline enthalten, sondern nur einer. Vorteilhafter Weise ist dieser auf der Seite der Source-Applikation, so dass der Serializer der Source-Seite mit dem Converter interagieren kann. Alternativ ist es jedoch auch möglich, den Converter auf der Seite der Sink-Applikation bereitzustellen.
In einer vorteilhaften Weiterbildung der Erfindung umfasst die Pipeline eine Manipulator-Funktion, die ausgelegt ist, um verschiedene Manipulationen auf den zu transferierenden Daten durchzuführen.
Die Pipeline kann also neben der Serializer-Funktion und Carrier-Funktion optional eine Converter-Funktion und/oder eine Manipulator-Funktion umfassen. Es ist also möglich, dass die Pipeline aus einem Serializer, einem Carrier und einem Manipulator besteht.
Der Manipulator bzw. die Manipulator-Funktion muss – im Unterschied zu der Converter-Funktion – immer paarweise verwendet werden. Der Manipulator auf der Seite der Source-Applikation verhindert den Datenstrom bzw. führt auf dem Datenstrom Manipulationen aus, während der Manipulator auf der Seite der Sink-Applikation diese Manipulationen wieder rückgängig machen muss. Wichtig dabei ist, dass diese Manipulationen sowohl für die Source-Applikation als auch für die Sink-Applikation vollständig verborgen sind. Das heißt, dass ein Anwender der Source-Applikation oder ein Anwender der Sink-Applikation nichts von den Veränderungen bemerkt, die durch die Manipulator-Funktion ausgeführt werden.
Die Manipulationen, die durch die Manipulator-Funktion auf dem Datenstrom ausgeführt werden, müssen stets unabhängig von dem Datenformat sein. Des Weiteren müssen sie reversibel sein, das heißt rückgängig gemacht werden können.
Hauptsächlich wird die Manipulator-Schnittstelle verwendet, um eine Datenkompression auszuführen, sowie für eine Verschlüsselung der Daten bzw. für kryptologische Zwecke. Im Falle einer kryptographischen Verschlüsselung wird beispielsweise der kryptographische Schlüssel während des Verbindungsaufbauprozesses zwischen der Source-Applikation und der Sink-Applikation mitübertragen. Erfindungsgemäß umfasst der Pipeline-Mechanismus die Serializer-Funktion, die sowohl auf der Seite der Source-Applikation als auch auf der Seite der Sink-Applikation bereitgestellt ist. Die Serializer-Funktion auf der Source-Applikations-Seite ist dazu ausgelegt, den Datenstrom, also die verschiedenen Bestandteile eines Objektes, in Chunks zu zerlegen. Auf der Seite der Sink-Applikation ist die Serializer-Funktion ausgelegt, die bereits übertragenen einzelnen Chunks wieder zu einem Datenstrom zusammenzusetzen.
Um diese Zerlegung ausführen zu können, ist es wichtig, dass der Serializer die Objektstruktur und insbesondere die logischen Einheiten kennt. Die Objektstruktur kann auch als das Datenformat des Objektes bezeichnet werden. Eine Aufgabe der Source-Applikation ist es deshalb; Objekt-bezogen Daten zu sammeln und bereitzustellen. Üblicherweise kann ein Serializer jeweils nur ein spezielles Datenformat verarbeiten bzw. kann nur solche Objekte verarbeiten, die in diesem Format vorliegen. Es ist jedoch erfindungsgemäß vorgesehen, dass alle kompatiblen Datenformate ebenso von dem Serializer verarbeitet werden können, indem vor Ausführung der Serializer-Funktion eine Datenkonvertierung ausgeführt wird. Ein DICOM-Bild kann als ein Objekt behandelt werden. Zum erfindungsgemäßen Transfer dieses DICOM-Bildes kann das Bild in Teile bzw. Parts zerlegt werden, vorzugsweise durch Abgrenzung zwischen der Header-Information und der eigentlichen Pixel-Daten. Es ist jedoch auch möglich, dass das Objekt nicht zerlegt wird und als ein Part transferiert wird.
Der Serializer der Sink-Seite benötigt Informationen über das übertragene Objekt und/oder die Zerlegung des Objektes in Teile. Diese Informationen stellt der Serializer der Source-Seite üblicherweise zur Verfügung, indem er die Objekte und Header generiert und zumindest die Größen dieser Datenstrukturen übermittelt.
Der Serializer auf der Seite der Source-Applikation unterscheidet sich in seiner Tätigkeitsweise von derjenigen des Serializers auf der Seite der Sink-Applikation. Der Source-seitige Serializer wird durch den Serializer-Controller angetrieben, während der Sink-seitige Serializer durch die bereits transferierten Chunks angetrieben bzw. initiiert wird.
Der Serializer-Controller ist auf der Seite der Source-Applikation angeordnet. Er dient zur Steuerung und/oder Kontrolle des Datenstroms. Der Serializer-Controllers hat die Fähigkeit, ferngesteuert zu werden. Obwohl der Serializer-Controller auf der Seite der Source-Applikation angeordnet ist, wird er in der bevorzugten Ausführungsform inhaltlich nach den Anforderungen bzw. Erfordernissen der Sink-Applikation ausgelegt und/oder von der Sink-Applikation (und damit „remote") gesteuert. Der Serializer auf der Source-Seite der Pipeline greift auf die Source-Applikation zu, insbesondere greift ausschließlich der Serializer auf die Source-Applikation zu. Das Anforderungsprofil der Daten, die auf der Seite der Sink-Applikation gefordert werden, ist erfindungsgemäß Grundlage für die Auslegung des Serializer-Controllers. In einer vorteilhaften alternativen Ausführungsform der Erfindung ist der Serializer-Controller alternativ und/oder kumulativ anhand weiterer Parameter ausgelegt, insbesondere nach den Anforderungen der Source-Applikation. Der Serializer Controller ist vorzugsweise als lokale Instanz ausgebildet und unterscheidet sich von dem Controller, der zentral ausgebildet ist und zur Überwachung des gesamten Transfervorganges, einschließlich der Vorbereitungsphase, dient.
Bezogen auf das OSI-Schichtenmodell übernimmt die Carrier-Funktion Aufgaben der OSI-Transportschicht und/oder der OSI-Netzwerkschicht mit entsprechenden Protokollen. Durch die stufenweise Verarbeitung und die erfindungsgemäße Auslegung der Carrier-Funktion ist das erfindungsgemäße Vorgehen sehr flexibel und an spezifische Erfordernisse adaptierbar.
Der Requester ist erfindungsgemäß vorgesehen, um den Datentransfer zu initiieren. Die Applikation, die den Datentransfer initialisiert wird also erfindungsgemäß Requester genannt. In manchen Fällen kann also der Requester mit der Sink-Applikation oder mit der Source-Applikation übereinstimmen. In anderen Ausführungsformen kann der Requester von ei ner weiteren Applikation gebildet werden. Je nach dem von welcher Applikation der Requester gebildet wird, liegt Zieh/Pull-Szenario, ein Schieben/Push-Szenario oder ein Bewegungs/Move-Szenario vor. Der Requester kann grundsätzlich in zwei Bestandteile unterteilt werden: Einmal die Anfrage des Datentransfers an sich und zum anderen der Überwachungsteil der Anfrage.
Die vorstehend beschriebenen, erfindungsgemäßen Ausführungsformen des Verfahren können auch als Computerprogrammprodukt ausgebildet sein, mit einem von einem Computer lesbaren Medium und mit einem Computerprogramm und zugehörigen Programmcode-Mitteln, wobei der Computer nach Laden des Computerprogramms zur Durchführung des oben beschriebenen, erfindungsgemäßen Verfahrens veranlasst wird.
Eine alternative Aufgabenlösung sieht ein Speichermedium vor, das zur Speicherung des vorstehend beschriebenen, computerimplementierten Verfahrens bestimmt ist und von einem Computer lesbar ist.
Zusätzliche, vorteilhafte Ausführungsformen ergeben sich aus den Unteransprüchen.
In der folgenden detaillierten Figurenbeschreibung werden nicht einschränkend zu verstehende Ausführungsbeispiele mit deren Merkmalen und weiteren Vorteilen anhand der Zeichnung besprochen. In dieser zeigen:
1 eine übersichtsartige Darstellung von Bestandteilen gemäß einer vorteilhaften Ausführungsform der Erfindung,
2 eine schematische Darstellung von zu transferierenden Daten und einer Zerlegung einer Objektstruktur gemäß der vorteilhaften Ausführungsform der Erfindung,
3 eine schematische Darstellung eines Zustandsdiagramms für den Transfer von Daten,
4 eine übersichtsartige Darstellung von Bestandteilen eines erfindungsgemäßen Systems gemäß einer bevorzugten Ausführungsform, umfassend ein Pull-Szenario, ein Move-Szenario und ein Push-Szenario,
5 eine Übersichtsdarstellung von wesentlichen Modulen gemäß einer bevorzugten Ausführungsform der Erfindung, und
6 eine funktionalen Zusammenhang zwischen Modulen der Erfindung.
In Zusammenhang mit 1 werden die Grundlagen des erfindungsgemäßen Verfahrens und die Hauptbestandteile der erfindungsgemäßen Vorrichtung gemäß einer bevorzugten Ausführungsform der Erfindung erläutert.
Das Verfahren bzw. die Vorrichtung ist zum Datentransfer von einer im Allgemeinen mit 10 bezeichneten Source-Applikation bzw. Source an eine im Allgemeinen mit 12 bezeichnete Sink-Applikation bzw. Sink bestimmt. In der bevorzugten Ausführungsform soll der Datentransfer über ein Netzwerk erfolgen. Dies ist in 1 mit der wolkenartigen Einfassung dargestellt. In alternativen Ausführungsformen erfolgt der Datentransfer nicht über ein Netzwerk, sondern beispielsweise über eine speziell dafür vorgesehene Leitung bzw. Standleitung oder über ein anderes Online- oder Offline-Medium.
Zwischen der Source-Applikation 10 und der Sink-Applikation 12 sind erfindungsgemäß verschiedene Bauteile angeordnet, die alle Bestandteile einer erfindungsgemäßen Pipeline sind. Zusätzlich zu diesen Bauteilen ist auf der Seite der Source-Applikation ein Serializer-Controller SC vorgesehen, der einen zu transferierenden Datenstrom steuert und/oder kontrol liert. Der Serializer-Controller SC umfasst eine Schnittstelle zu einem Serializer S der das initiale Element in der Pipeline ist. Der Serializer-Controller SC ist lediglich auf der Seite der Source-Applikation 10 vorgesehen und wird allerdings von einem entfernen System (also remote), insbesondere von der Sink-Applikation 12, gesteuert. Das erste Element auf der Source Seite der Pipeline, der Serializer S, greift auf Daten der Source zu.
Die Pipeline ist in der bevorzugten Ausführungsform symmetrisch ausgebildet und umfasst zwei Pipeline-Teile: Einen Source-seitigen Teil und einen Sink-seitigen Teil. In einer alternativen Ausführungsform der Erfindung ist die Pipeline jedoch asymmetrisch ausgebildet. Darüber hinaus kann die Pipeline auch aus weniger Bestandteilen bestehen und beispielsweise nur einen Serializer S und einer Carrier Ca umfassen.
In der bevorzugten Ausführungsform umfasst die Pipeline einen Serializer S, einen Converter Co, einen Manipulator M und einen Carrier Ca. Bevorzugterweise finden sich all die vorstehenden erwähnten Bestandteile in umgekehrter Reihenfolge auf der Seite der Sink-Applikation 12 wieder.
Die Pipeline Komponenten bzw. Module nach der erfindungsgemäßen Vorrichtung, nämlich der Serializer S, der Converter Co, der Manipulator M und der Carrier Ca, und der Serializer Controller SC entsprechen inhaltlich den jeweiligen Funktionen des erfindungsgemäßen Verfahrens, nämlich der Serializer Funktion S, der Converter Funktion Co, der Manipulator Funktion M und der Carrier Funktion Ca, und der Serializer Controller Funktion SC. Die Bezugszeichen werden gleichlaufend verwendet.
Durch die erfindungsgemäße Ausbildung des Verfahrens ist eine hohe Flexibilität des Datentransfers auch bei zu Laufzeit veränderlichen Anforderungen möglich.
Hauptsächliches Anwendungsgebiet der Erfindung liegt auf dem medizinischen Sektor und der Verarbeitung von medizinischen Bilddaten, vorzugsweise im DICOM-Format. Die Erfindung ist jedoch auch auf alle anderen Formate und Objekte anwendbar.
Kommunizieren beispielsweise eine Source-Applikation 10 mit einer Sink-Applikation 12, die auf Daten desselben Datenformats aufsetzen und keine weiteren Konvertierungen und/oder Manipulationen an den Daten erfordern, so ist es möglich, eine Pipeline einzusetzen, die lediglich aus dem Serializer S und dem Carrier Ca besteht. In anderen Fällen, in denen z.B. die Source-Applikation 10 ein anderes Datenformat erfordert als die Sink-Applikation 12, an die die Daten transferiert werden sollen, so ist die erfindungsgemäße Pipeline aus dem Serializer S, dem Converter Co, dem Manipulator M und dem Carrier Ca gebildet, die auf beiden Seiten symmetrisch, aber in umgekehrter Reihenfolge, bereitgestellt sind.
Der Serializer dient dazu, den Datenstrom vor dem Datentransfer in einzelne Chunks zu zerlegen. Insbesondere durch die Zerlegung von komplexen Bilddaten in einzelne Chunks kann der Datentransfer vorteilhafterweise deutlich verbessert werden und die Performance deutlich erhöht werden.
Der Converter Co übernimmt die Funktion, die unterschiedlich vorhandenen Datenformate ineinander zu konvertieren.
Der Manipulator M dient dazu, falls erforderlich, weitere Manipulationen auf den Daten auszuführen.
Der Carrier Ca ist das letzte bzw. erste Glied in der Pipeline und übernimmt die eigentliche, physikalische Datenübertragung. Gemäß dem OSI-Schichtenmodell der ISO (International Standardisation Organisation) umfasst der Carrier Ca Aufgaben einer OSI-Transportschicht. In einer alternativen Ausführungsform umfasst der Carrier Ca neben der OSI-Transportschicht zusätzlich die Aufgaben einer OSI- Netzwerkschicht. Darüber hinaus werden die entsprechenden Protokolle zum Datenaustausch unterstützt.
Sollten bisher nach den Verfahren nach dem Stand der Technik Bilddaten, insbesondere medizinische Bilddaten, beispielsweise einer PACS-Applikation an eine andere Applikation übertragen werden, so war es erforderlich, das gesamte Bildobjekt bzw. die Bilddatenserie als Ganzes zu transferieren. Dies führte zu langen Übertragungszeiten und langen Verarbeitungszeiten. Des Weiteren war auch die Fehleranfälligkeit solcher Systeme sehr hoch, da ein Fehler bei der Übertragung grundsätzlich zu einem Fehler des Datentransfers führte.
Erfindungsgemäß kann durch die Ausbildung des Serializers S das zu übertragende Bildobjekt in einzelne Chunks zerlegt werden. Dieser Vorgang ist in 2 näher erläutert.
Die zu übertragende Objektstruktur besteht aus mehreren Teilen Part0, Part1 bis zu Partn. Diese Objektstruktur wird erfindungsgemäß in einzelne Chunks zerlegt. Beispielsweise kann ein einzelnes DICOM-Bild als ein Objekt behandelt werden. Gemäß den Header-Informationen und den Pixel-Daten wird das DICOM-Bild in einzelne Parts verarbeitet. Ein Part ist eine logische Struktur eines Objektes. Jedes Objekt hat zumindest einen Part. Wie bereits erwähnt, kann ein DICOM-Bild somit als ein zwei-elementiges Objekt verarbeitet werden, umfassend Header-Daten und Pixel-Daten.
Erfindungsgemäß wird ein Objekt in eine Vielzahl von Chunks zerlegt. Jedes Chunk umfasst Metainformationen und die Daten, die sich auf den jeweiligen Part beziehen. Die Anzahl der Chunks für ein Objekt ist abhängig von der jeweiligen Implementierung. Die zusätzliche Information, die für den Datentransfer notwendig ist, wird in den Datenfluss eingebracht. Die in den Datenfluss bzw. Datenstrom eingebrachten Metainformation kann in Chunk-Metainformationen, dem Header eines Parts oder dem Header eines Objektes etc. liegen. Die erfindungsgemäße Zerlegung eines zu übertragenden Objektes in einzelne Chunks führt dazu, dass die Funktionalität und die Performance des Datentransfers deutlich gesteigert werden kann.
Darüber hinaus ist es erfindungsgemäß möglich, dass die Reihenfolge der zu transferierenden Objekte sich verändert, in Abhängigkeit von den aktuellen Transfererfordernissen. Die Objektreihenfolge kann sich z.B. von der ursprünglichen Anfragereihenfolge unterscheiden, falls ein Quality-of-Service-Modul eine Veränderung der Reihenfolge veranlasst oder falls zumindest ein Objekt aufgrund von Sicherheitsvorschriften von dem Datentransfer ausgeschlossen ist oder in der Source 10 nicht bekannt sind.
In Zusammenhang mit 3 wird nachfolgend die Hauptfunktion des Serializer-Controllers SC erläutert. Der Serializer-Controller SC dient dazu, den zu transferierenden Datenfluss nach den Anforderungen der Sink-Applikation 12 zu steuern. Dies ist möglich, indem Befehle an den Serializer-Controller SC übermittelt werden. Die Befehle können lokal oder nicht-lokal ausgegeben werden. Insbesondere ist es möglich, die Befehle zur Steuerung des Serializer-Controllers SC direkt von der Sink-Applikation 12 aus zu geben.
Der Serializer-Controller SC ist lediglich auf der Seite der Source-Applikation 10 der Pipeline aktiv. Der Serializer-Controller SC ist damit die erste Verarbeitungsstufe auf der Seite der Source-Applikation 10 und füllt den Serializer S mit einer Input-queue bzw. mit einer Eingabefolge. Darüber hinaus steuert der Serializer-Controller SC die gesamte Transferkette.
Nachfolgend findet sich eine kurze Erläuterung der in 3 verwendeten Befehle zur Datenflusskontrolle:

set Mode:: erlaubt die Spezifikation des Transfer-Modus (kontinuierlich oder diskret).
start:: initialer Startpunkt des Transfers.
stop:: Ende oder Abbruch des Transfers.
pause:: Anhalten des laufenden Transfers.
resume:: Wiederaufnahme des Transfers nach einer Unterbrechung.
seekObject:: Setzen des logischen Object-Pointers auf das angeforderte Objekt.
seekPart:: Setzen des logischen Part-Pointers auf das angeforderte Part.

Der Serializer-Controller SC implementiert das Transfer-Status-Diagramm, das in 3 gezeigt ist. Das Status-Diagramm legt fest, in welchen Situationen welche Befehle für den Datenfluss bzw. für die Datenfluss-Steuerung gültig sind.
In 3 ist ein Status jeweils durch eine Ellipse gekennzeichnet. Der Start-Zustand ist links oben dargestellt und hat einen eingehenden Pfeil, der keinen dedizierten Startpunkt aufweist. End-Zustände sind jeweils durch eine doppelt gezogene Ellipse gekennzeichnet. Mögliche Zustandsänderungen sind durch Pfeile gekennzeichnet. Im Allgemeinen ist der Name eines Pfeils das jeweilige Kommando für den Datenfluss bzw. für die Datenfluss-Steuerung, die den jeweiligen Zustands-Übergang ausgelöst hat. Falls der Übergangs-Zustand nicht unmittelbar von einem Datenfluss-Befehl ausgelöst worden ist, sondern beispielsweise von einem weiteren Aktivierungs-Zustand oder einer Aktivierungs-Bedingung ist diese Aktivierungs-Bedingung kursiv gedruckt als Name eines Pfeils erkenntlich. Es ist auch möglich, dass ein Zustand für ein spezielles Datenfluss-Steuerungskommando keinen ausgehenden Pfeil aufweist. Dies soll verdeutlichen, dass dieser Befehl in diesem speziellen Zustand nicht erlaubt ist.
All die vorstehend erwähnten Befehle lassen sich grundsätzlich in zwei Gruppen untergliedern: Die erste Gruppe umfasst Kommandos, die unmittelbar und synchron ausgeführt werden. Zu dieser Gruppe gehören folgende Kommandos: start, stop, pause, resume und setMode. Die andere Gruppe von Kommandos bzw. Befehlen werden in einem Puffer gespeichert, in einem FIFO(First-In-First-Out)-Puffer und können nicht direkt ausgeführt werden. Zu dieser Gruppe gehören beispielsweise folgende Befehle: seekObject und seekPart. Diese Befehle können beispielsweise deshalb nicht unmittelbar ausgeführt werden, da vorhergehende Befehle noch anhängig sind. Dies ermöglicht ein asynchrones und nicht-blockierendes Verhalten. Die Größe des Puffers für Datenfluss-Steuerungsbefehle kann begrenzt sein. Das Vorsehen der erfindungsgemäßen Möglichkeit, Datenfluss-Steuerungsbefehle zu speichern bzw. in einer Queue abzuarbeiten, impliziert, dass diese Befehle teilweise ein verzögertes Reaktionsverhalten aufweisen.
Nachdem ein Part bzw. Teil übertragen worden ist, kann der nächste Part übertragen werden. Davor muss jedoch bestimmt werden, welcher Part das ist. Für Parts, die demselben Objekt angehören, ist diese Feststellung mit wenig Aufwand verbunden. Für Parts, die jedoch über eine Objektgrenze hinausgehen, sind zusätzliche Informationen für die Bestimmung notwendig, so wie beispielsweise die Granularität der Datenflusskontrolle.
In Zusammenhang mit 4 werden nachfolgend verschiedene Szenarien einer erfindungsgemäßen Ausführungsform erläutert.
Die Pipeline umfasst die Module Requester R, Source-Applikation 10 und Sink-Applikation 12.
Falls der Requester R mit der Sink-Applikation 12 übereinstimmt, handelt es sich um ein Pull-Szenario (Anforderungs-Szenario: Applikation A möchte Daten haben); falls der Requester R mit der Source-Applikation 10 übereinstimmt, handelt es sich um ein Push-Szenario (Schiebe-Szenario, bei dem die Daten an eine andere Position geschoben werden sollen); falls der Requester R von einer anderen Applikation (in 4 von Applikation C) gebildet wird, handelt es sich um ein Move-Szenario (Verschiebe Daten von A nach B). Die verschiedenen Szenarien sind in 4 abgebildet.
Im Allgemeinen stellt die Source-Applikation die Daten für den Datentransfer bereit. Dazu ist ein Mapping von den angeforderten Objekten und Objekt-Identifikatoren notwendig. In einer Vorbereitungsphase muss die Source-Applikation 10 Informationen sammeln, die für den Datentransfer notwendig sind, wie beispielsweise Objektgröße etc.
Während des Datentransfers wird die Source-Applikation 10 über den aktuellen Zustand des Datentransfers informiert und über etwaige Änderungen. Dies geschieht vorzugsweise über ein Message System 18, das zum Sammeln und zum Weiterleiten aller relevanten Transferstatusinformationen bestimmt ist.
Des Weiteren muss die Source-Applikation 10 einen Quality-of-Service (QoS) unterstützen und gegebenenfalls angeforderte Objekte neu strukturieren bzw. die Identifikatoren für diese angeforderten Objekte neu ordnen, basierend auf den angeforderten Eigenschaften.
Die Source-Applikation 10 sollte jedoch so ausgelegt sein, dass sie asynchron arbeiten kann.
Die Sink-Applikation 12 hat im Wesentlichen dieselben Anforderungen und Charakteristika, die vorstehend bei der Source-Applikation 10 erläutert worden sind. Im Unterschied zur Source-Applikation 10 hat die Sink-Applikation 12 die Möglichkeit, den Datenstrom über die Schnittstelle zum Serializer-Controller SC zu steuern. Damit kann der Transfer an die aktuellen Erfordernisse der Sink-Applikation 12 angepasst sein.
Ein weiterer Unterschied zwischen der Sink-Applikation 12 und der Source-Applikation 10 besteht darin, dass die Sink- Applikation 12 keine Aspekte hinsichtlich des QoS unterstützen muss.
Die Vorteile der erfindungsgemäßen Unterteilung der zu transferierenden Datenobjekte liegen in der Anpassbarkeit des Systems an unterschiedliche Hardware-Komponenten, sowie an bereits bestehende Software-Module. Des Weiteren kann die Performance und die Konfigurierbarkeit durch den Anwender deutlich gesteigert werden. Nachstehend soll beispielhaft erläutert werden, wie erfindungsgemäß ein DICOM-Bild von einer Source-Applikation 10 über ein langsames Netz, insbesondere ein langsames WAN (WideAreaNetwork) an eine Sink-Applikation 12 übertragen wird, wobei letztere nur JPEG-Bilder verarbeiten kann. Die erste erfindungsgemäße Verarbeitungsstufe ist der Serializer S, der das Objekt zerlegt. Da die Datenübertragung über ein langsames Transfermedium erfolgen soll, ist die nächste Verarbeitungsstufe eine Converter-Funktion Co, die aus dem DICOM-Objekt ein hochkomprimiertes zweiteiliges Objekt macht. Die sich daran anschließende Verarbeitungsstufe besteht in dem Manipulator M, der die Daten verschlüsselt, um die Datensicherheit zu gewährleisten. Die letzte Verarbeitungsstufe auf der Seite der Source 10, besteht in dem Carrier Ca, der speziell für WAN-Transfers ausgelegt ist und die Daten an die Sink 12 weiterleitet. Damit endet der source-seitige Teil der Pipeline.
Danach schließt sich der Sink-seitige Teil der Pipeline an, dessen erstes Element der Carrier Ca ist, der die Daten über das WAN empfängt. Die nächste Verarbeitungsstufe ist der Manipulator M, der den Datenstrom entschlüsselt und decodiert. Da die Sink-Applikation 12 lediglich JPEG-Bilder verarbeiten kann, muss die dritte Verarbeitungsstufe ein Converter Co sein, um das hochkomprimierte zweiteilige Objekt in ein Objekt vom JPEG-Format zu konvertieren. Das letzte Element der Pipeline muss selbstverständlich ein Serializer S sein, der diesen Objekt-Typ verarbeiten, kann.
Ein wesentlicher Vorteil des erfindungsgemäßen Vorgehens liegt darin, den Verbrauch der Ressourcen für den Transfer deutlich minimieren zu können. Vorteilhafterweise muss bei diesem Vorgehen kein zusätzlicher Speicher verwendet werden. Erfindungsgemäß erfolgt der Transfer der Daten, indem die Daten aus dem originalen Speicher gelesen und direkt in den Speicher der Sink-Applikation 12 geschrieben werden. Damit kann ein unnötige Kopieren der transferierten Daten in einen bestimmten Speicherbereich der empfangenden Applikation vermieden werden, da es einstellbar ist, wohin (in welchen Speicherbereich) die zu transferierenden Daten gesendet werden sollen.
Um den Speicher, der hauptsächlich als Array bzw. Feld von Bytes organisiert ist, effizienter zu gestalten, wird eine Wrapper-Klasse eingeführt, um die erforderliche Metainformation zu den jeweiligen Datensätzen zu sammeln. Darüber hinaus benötigt diese Speicherklasse einen Benachrichtigungsmechanismus, um die Applikationen darüber zu informieren, falls das Speicherobjekt nicht weiterverwendet wird. Dieses Vorgehen setzt voraus, dass ein Speicherobjekt jeweils vor einer ersten Anwendung und nach einer letzten Anwendung eine entsprechende Benachrichtigung sendet.
Um es zu ermöglichen, dass auch große Objekte mit einem nur sehr geringen Speicherverbrauch transferiert werden können, wird erfindungsgemäß auf die in Chunks zerlegte Übertragung der Objekte zurückgegriffen. Durch die Unterteilung des Objekts in kleinere Einheiten können auch die Speicherobjekte entsprechend kleiner sein und können von daher begrenzt werden. Die für die zu transferierenden Chunks generierten Speicherobjekte müssen demnach begrenzt werden. Dies kann erreicht werden, indem alle Speicherobjekte grundsätzlich aus einem Pool abgegriffen werden und/oder durch Begrenzung der Kapazität von Queues zwischen den unterschiedlichen Verarbeitungsstufen der Pipeline.
Vorteilhafterweise kann mit dem erfindungsgemäßen Vorgehen ein hoher Durchsatz vorwiegend von sehr großen Datenvolumina erzielt werden, die in verteilten Systemen transferiert werden sollen. Ein weiteres Hauptaugenmerk liegt in der Transparenz hinsichtlich der Adress- bzw. Positions-Information. Erfindungsgemäß wird die physikalische Positions-Information (z.B. IP-Adresse) gekapselt.
Jeder Applikation wird eineindeutig ein Identifikator zugewiesen. Die erfindungsgemäße Lösung umfasst ein Mapping in Bezug auf den jeweiligen Applikations-Identifikator. Dieses Mapping ist sehr leicht konfigurierbar.
In 5 sind die fünf Module mit ihren Rollen abgebildet, die bei einem Transfer involviert sind. Wie ersichtlich handelt es sich bei dem Message System 18 und bei einem zentralen Controller 16 um Server-seitige Komponenten, während die Source 10, die Sink 12 und der Requester R Client-seitige Komponenten darstellen. Alle Client-seitigen Komponenten haben dieselbe Struktur und können bei einem Transfer unterschiedliche Rollen einnehmen.
Der Controller 16 führt alle Funktionen aus, die zum Verwalten und Überwachen des Transfers notwendig sind. Er bestimmt insbesondere die beiden Peers, also die Source 10 und die Sink 12, über eineindeutige Identifikatoren und einem zugehörigen Repository, er wählt in Hinblick auf die beteiligten Applikationen 10, 12 und in Hinblick auf die Transfererfordernisse (z.B. physikalische Datenverbindung, installierte Funktionalität oder gefördertes Datenformat) die passenden und optimal ausgelegten Transferperameter aus, er initiiert den Verbindungsauf- und abbau und er ermöglicht eine übergeordnete Überwachung und sieht High Level Kontrollmechanismen vor.
Die drei Client-seitigen Rollen der Source 10, der Sink 12 und des Requesters R und deren Datenaustausch sind ebenfalls in 5 dargestellt. Sie arbeiten vorzugsweise auf einer Rückruf-Basis. Alle Module bzw. Komponenten werden über transfer-bezogene Statusveränderungen über das Message System 18 informiert. Der Requester R, die Source 10 und die Sink 12 können jedoch auch angeben, an welchen Statusnachrichten sie interessiert sind. Dann werden nicht alle Statusveränderunge mitgeteilt, sondern nur die von ihnen getätigte Auswahl. Dies kann das Message System 18 entlasten. Sobald ein neuer Transferauftrag eingeht, werden die beteiligten Module darüber vom Controller 16 informiert. Durch die Verwendung der einzelnen Komponenten ergibt sich vorteilhafterweise ein synergistischer Effekt.
In Hinblick auf 5 wird der Datenfluß bei einem Transferauftrag beschrieben:
Der Requester R initiiert den Transfer über den Controller 16. Der Controller 16 informiert die Source 10 und die Sink 12 über den anhängigen Transferauftrag, wobei die Sink 12 zusätzlich über weitere Informationen unterrichtet wird, die der Controller 16 von der Source 10 bei deren Information erhalten hat. Dann informiert der Controller 16 den Requester R über den Start des beauftragten Transfers und initiiert den Verbindungsaufbau zwischen der Source 10 und der Sink 12. Die Sink 12 generiert aktiv eine Verbindung für die zu transferierenden Daten und überwacht den Datenfluß, und veranlasst z.B. Starts, Unterbrechungen und Stops des Datenflusses. Im Falle einer Statusveränderung oder eines Fehlers, kann das Message System 18 und/oder der Controller 16 informiert werden. Das Message System 18 filtert und verteilt die eingegangenen Statusveränderungen an alle Komponenten bzw. Funktionen, die sich dafür angemeldet haben. Nach Beendigung des Transfers beauftragt der Controller 16 die Sink 12, die Transferverbindung zur Source 10 zu lösen.
Auf allen Clients muss der erfindungsgemäße TransferService und auf dem Server der Controller 16 installiert sein. Der TransferService leistet im Wesentlichen drei Aufgaben:

1. Nachfrage bei den beteiligten Client-Applikationen, welche Komponenten verfügbar sind, um eine Kompatibilitätsmatrix für den Transfer zu erstellen.
2. Aufbau, Abbau und Überwachen der Transferpipeline bei dem Datentransfer und
3. TransferService Übergabe des Client-seitigen Teils des Message Services.

Erfindungsgemäß ist es vorgesehen, dass der Controller 16 als Stand-alone Komponente verwendet wird. Ein einzelner Transferauftrag (z.B. „Alle Bilder des Patienten X and die Radiologie senden") kann in verschiedene Sub-Aufträge unterteilt werden, und auf einzelne Geräte aufgeteilt werden, die alle Bilder des Patienten X gespeichert haben. Diese Aufträge können parallel ausgeführt werden, sodass der Gesamtauftrag in seiner Verarbeitungszeit minimiert werden kann.
Des Weitern kann insbesondere durch die Schnittstelle zwischen der Sink 12 und dem Serializer Controller SC eine Informationsfilterung auf der Senderseite stattfinden.
Die wahlweise verwendbaren Funktionen bzw. Module S, Ca, M, Co sind austauschbar und dynamisch veränderbar. Dafür ist erfindungsgemäß jeweils ein dynamisch erweiterbares Repository vorgesehen an Serializern S, an Convertern Co, an Manipulatoren M, an Netzwerkadaptern, die unterschiedliche Netzwerkprotokolle unterstützen, und an Adaptoren, die die jeweiligen Applikationen an den TransferService anschliessen.
Erfindungsgemäß wird eine Service Schnittstelle zur Verfügung gestellt, die es ermöglicht, Eigenschaften von Source 10, Sink 12 und/oder Eigenschaften in Hinblick auf den Transfer auch zur Laufzeit zu erfragen und ggf. zu verändern und in einem Fenster auf einer Oberfläche einer Applikation 10, 12 anzuzeigen.
Durch die Vorbereitungsphase können zeitintensive Verhandlungen der beiden Kommunikationspeers zum Zeitpunkt des Verbindungsaufbaus vermieden werden. Darüber hinaus haben die Applikationen 10, 12 die Möglichkeit, die für den Transfer benötigten Ressourcen bereits im Voraus zu erfragen und ggf. anzufordern. Durch die modulartige Ausbildung des Systems ist letzteres leicht erweiterbar.
Die Transfererfordernisse, wie z.B. Datenformat und Datenstruktur sowie die Reifenfolge der zu transferierenden Objekte kann an die empfangende Applikation 12 angepasst werden.
In einer alternative Ausführungsform der Erfindung ist es vorgesehen, dass statistische Informationen in Bezug auf den Datentransfer mitgeführt werden, um für zukünftige Auswahlaufgaben zur Verfügung zu stehen.
6 zeigt die beiden interagierenden Kommunikationspeers Source 10 und Sink 12 mit den installierten Modulen und den Controller 16. Auf den beiden Clients sind neben den Transferpipeline Modulen Carier Ca, Manipulator M, Converter Co und Serializer S und auf der Seite der Source 10 noch der Serializer Controller SC auch noch jeweils ein Device Modul und Schnittstellen, eine SinkConnection und eine SourceConnection installiert.
Im Folgenden wird der erfindungsgemäße Datenfluss beschrieben:
Der Controller 16 ruft die ausgewählte Source-seitige Device und generiert eine Verbindung zur Source 10. Über diese Verbindung werden alle erforderlichen Pipeline-Module generiert und verbunden. Der Controller 16 bereitet die Sourceverbindung für den Transferauftrag vor. Diese Vorbereitung wird an die Source 10 weitergeleitet um darauf Zusatzinformationen von der Source 10 zurück zu erhalten. Daraufhin ruft der Controller 16 die ausgewählte sink-seitige Device auf, um eine Sinkverbindung zu generieren. Über diese Verbindung werden alle notwendigen Pipeline Module initialisiert und verbunden. Der Controller 16 bereitet die Sinkverbindung mit den von der Source 10 empfangenen Zusatzinformationen vor. Diese Vorbereitung wird an die Sink 12 weitergeleitet. Der Controller 16 initiiert den Verbindungsaufbau durch Übergabe einer Referenz auf die Sourceverbindung an die Sinkverbindung. Die Sinkverbindung initiiert und überwacht den Verbindungsaufbauvorgang. Das Ergebnis ist eine vollständige und ausführbare Transfer-Pipeline. Falls der Controller 16 durch Aufruf der Sinkverbindung den Transfer startet, triggert die Sinkverbindung den Serializer Controller SC auf der Sourceseite. Falls die vorstehend beschriebene Autostart-Option nicht ausgewählt wird muss die Sink 12 den Transfer über die Referenz und den Serializer Controller SC starten.
Die folgenden beiden Verfahrensschritte werden für jedes Chunk solange wiederholt bis der Transfer abgeschlossen ist:

1. Ein Chunk wird von der Source 10 genommen.
2. Nachdem es durch alle Module der Pipeline geleitet worden ist wird es an die Sink 12 gesendet.

Daraufhin wird die Verbindung von dem Controller 16 abgebaut.
Durch das erfindungsgemäße Vorgehen wird es möglich, dass gleichzeitig und/oder sogar innerhalb eines Transfers gemischte Protokolle verwendet und Konfigurationsänderungen auch während der Laufzeit durchgeführt werden können.
In einer alternativen Ausführungsform der Erfindung steuert und/oder überwacht der Controller 16 nicht nur die Vorbereitung des Datentransfers, sondern auch den Datentransfer selbst.

Claims

Verfahren zum Transfer von Daten von Objekten von zumindest einer Source-Applikation (10) an zumindest eine Sink-Applikation (12), umfassend: – Initiieren des Transfers der Daten durch einen Requester (R), – Steuerung eines Datenstroms durch einen Serializer-Controller (SC), – Sukzessives Verarbeiten der Daten für den Transfer durch einen Pipeline Mechanismus, was zumindest folgende Schritte umfasst: – Zerlegen der verschiedenen Bestandteile eines Objekts im Datenstrom vor dem Transfer in einzelne Chunks, mittels einer Serializer-Funktion (S), welche eine Objektstruktur der zu übertragenden Daten kennt, und nach dem Transfer Wiederzusammensetzen der Chunks zu einem Datenstrom, mittels der Serializer-Funktion (S), und – Ausführen der physikalischen Datenübertragung durch eine Carrier-Funktion (Ca), wobei eine Reihenfolge der zu transferierenden Objekte auch während des Transfers dynamisch an Anforderungen der Sink-Applikation (12) angepasst werden kann.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Serializer-Funktion (S) auf der Seite der Source-Applikation (10) und auf der Seite der Sink-Applikation (12) bereitgestellt ist und dazu bestimmt ist, den Datenstrom in einzelne Chunks zu zerlegen und seitens der Sink-Applikation (12) die Chunks wieder zu einem Datenstrom zusammenzusetzen.
Verfahren nach zumindest einem der Ansprüche 1 oder 2, dadurch gekennzeichnet, dass der Serializer-Controller (SC) auf der Seite der Source-Applikation (10) angeordnet ist und/oder von der Sink-Applikation (12) gesteuert wird, so dass eine Transfer-Datenstruktur und/oder ein Transfer-Datenformat auch während dem Transfer dynamisch an Anforderungen der Sink-Applikation (12) angepasst werden können.
Verfahren nach zumindest einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass die Carrier-Funktion (Ca) Aufgaben einer OSI-Transportschicht oder einer OSI-Transport- und Netzwerkschicht abdeckt und/oder entsprechende Protokolle unterstützt.
Verfahren nach zumindest einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass der Pipeline-Mechanismus seitens der Source-Applikation (10) und seitens der Sink-Applikation (12) symmetrisch ausgebildet ist.
Verfahren nach zumindest einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass der Pipeline-Mechanismus zusätzlich eine Converter-Funktion (Co) umfasst, die dazu bestimmt ist, unterschiedliche Datenformate zu konvertieren.
Verfahren nach zumindest einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass der Pipeline-Mechanismus zusätzlich eine Manipulator-Funktion (M) umfasst, die dazu bestimmt ist, unterschiedliche Manipulationen auf den Daten durchzuführen.
Verfahren nach zumindest einem der vorstehenden Ansprüche, dadurch gekennzeichnet, dass der Requester (R) aus der Source-Applikation (10), der Sink-Applikation (12) und/oder einer weiteren Applikation gebildet wird.
Verwendung des Verfahrens nach zumindest einem der vorstehenden Ansprüche zum Verwalten des Datentransfers mit: – einer zentralen Controller-Funktion (16), die eine Vorbereitung des Datentransfers steuert und/oder überwacht, und/oder die Source-Applikation (10) und Sink-Applikation (12) für den jeweiligen Datentransfer und/oder die passenden Funktionen (S, Co, M, Ca) für den Pipeline-Mechanismus bestimmt, den Auf- und Abbau der Pipeline steuert und/oder überwacht und/oder Konfigurationen für den Datentransfer an Transfererfordernisse anpasst und/oder mit – einem zentralen Message System (18), das alle relevanten Statusinformationen bezüglich des Datentransfers sammelt und/oder Statusveränderungen an beteiligte Module weiterleitet.
Vorrichtung zum Transfer von Daten von Objekten von zumindest einer Source-Applikation (10) an zumindest eine Sink-Applikation (12), umfassend: – einen Requester (R), der den Transfer der Daten initiiert und – einen Serializer-Controller (SC), der einen Datenstrom steuert, – eine Pipeline, die zum sukzessiven Verarbeiten der Daten für den Transfer bestimmt ist und die zumindest folgendes umfasst: – einen Serializer (S), welcher eine Objektstruktur der zu übertragenden Daten kennt, der dazu bestimmt ist, die verschiedenen Bestandteile eines Objekts im Datenstrom vor dem Transfer in einzelne Chunks zu zerlegen und nach dem Transfer die Chunks wieder zu einem Datenstrom zusammenzusetzen, – einem Carrier (Ca), der dazu bestimmt ist, die physikalische Datenübertragung auszuführen, wobei eine Reihenfolge der zu transferierenden Objekte auch während des Transfers dynamisch an Anforderungen der Sink-Applikation (12) angepasst werden kann.
Vorrichtung nach Anspruch 10, dadurch gekennzeichnet, dass der Serializer (S) auf der Seite der Source-Applikation (10) und auf der Seite der Sink-Applikation (12) bereitgestellt ist und dazu bestimmt ist, den Datenstrom in einzelne Chunks zu zerlegen und seitens der Sink-Applikation (12) die Chunks wieder zu einem Datenstrom zusammenzusetzen.
Vorrichtung nach zumindest einem der Ansprüche 10 oder 11, dadurch gekennzeichnet, dass der Serializer-Controller (SC) auf der Seite der Source-Applikation (10) angeordnet ist und/oder nach Anforderungen der Sink-Applikation (12) aktiviert wird.
Vorrichtung nach zumindest einem der vorstehenden Ansprüche 10 bis 12, dadurch gekennzeichnet, dass der Carrier (Ca) Aufgaben einer OSI-Transportschicht oder einer OSI-Transport- und Netzwerkschicht abdeckt und/oder entsprechende Protokolle unterstützt.
Vorrichtung nach zumindest einem der vorstehenden Ansprüche 10 bis 13, dadurch gekennzeichnet, dass die Pipeline seitens der Source-Applikation (10) und seitens der Sink-Applikation (12) symmetrisch ausgebildet ist.
Vorrichtung nach zumindest einem der vorstehenden Ansprüche 10 bis 14, dadurch gekennzeichnet, dass die Pipeline zusätzlich einen Converter (Co) umfasst, der dazu bestimmt ist, unterschiedliche Datenformate zu konvertieren.
Vorrichtung nach zumindest einem der vorstehenden Ansprüche 10 bis 15, dadurch gekennzeichnet, dass die Pipeline zusätzlich einen Manipulator (M) umfasst, der dazu bestimmt ist, unterschiedliche Manipulationen auf den Daten durchzuführen.
Vorrichtung nach zumindest einem der vorstehenden Ansprüche 10 bis 16, dadurch gekennzeichnet, dass der Requester (R) aus der Source-Applikation (10), der Sink-Applikation (12) und/oder einer weiteren Applikation gebildet wird.
Verwendung der Vorrichtung nach zumindest einem der vorstehenden Ansprüche 10 bis 17 zum Verwalten des Datentransfers, mit: – einem zentralen Controller (16), der eine Vorbereitung des Datentransfers steuert und/oder überwacht, und/oder die Source-Applikation (10) und Sink-Applikation (12) für den jeweiligen Datentransfer und/oder die passenden Module (S, Co, M, Ca) für die Pipeline bestimmt, den Auf- und Abbau der Pipeline steuert und/oder überwacht und/oder Konfigurationen für den Datentransfer an Transfererfordernisse anpasst und/oder mit – einem zentralen Message System (18), das dazu bestimmt ist, alle relevanten Statusinformationen bezüglich des Datentransfers zu sammeln und/oder Statusveränderungen an beteiligte Module weiterzuleiten.
Verfahren zum Verwalten eines Datentransfers von Objekten von zumindest einer Source-Applikation (10) an zumindest eine Sink-Applikation (12), umfassend: – Steuerung und/oder Überwachung eines Datenstroms durch einen Serializer-Controller (SC), – Sukzessives Verarbeiten der Daten für den Transfer durch einen Pipeline Mechanismus, was zumindest folgende Schritte umfasst: – Zerlegen der verschiedenen Bestandteile eines Objekts im Datenstrom vor dem Transfer in einzelne Chunks, mittels einer Serializer-Funktion (S), welche eine Objektstruktur der zu übertragenden Daten kennt, und nach dem Transfer Wiederzusammensetzen der Chunks zu einem Datenstrom, mittels der Serializer-Funktion (S), und – Ausführen der physikalischen Datenübertragung durch eine Carrier-Funktion (Ca), wobei der Datentransfer verwaltet wird durch: – eine zentrale Controller-Funktion (16), die eine Vorbereitung des Datentransfers steuert und/oder überwacht, und/oder die Source-Applikation (10) und Sink-Applikation (12) für den jeweiligen Datentransfer und/oder die passenden Funktionen (S, Co, M, Ca) für den Pipeline Mechanismus bestimmt, den Auf- und Abbau der Pipeline steuert und/oder überwacht und/oder Konfigurationen für den Datentransfer an Transfererfordernisse anpasst und mit – einem Message System (18), das zentral fungiert und alle relevanten Statusinformationen bezüglich des Datentransfers sammelt und insbesondere Statusveränderungen an beteiligte Funktionen weiterleitet, und wobei eine Reihenfolge der zu transferierenden Objekte auch während des Transfers dynamisch an Anforderungen der Sink-Applikation (12) angepasst werden kann.
Verfahren nach Anspruch 19 dadurch gekennzeichnet, dass das Verfahren zumindest einen Requester (R) umfasst, der den Transfer der Daten initiiert.
Verfahren nach zumindest einem der Ansprüche 19 oder 20, dadurch gekennzeichnet, dass die Controller-Funktion (16), in einer hierarchisch übergeordneten Ebene über den anderen Funktionen (S, Co, M, Ca, SC) der Pipeline und/oder auf der Ebene der Applikationen (10, 12) und des Message Systems (18) eingegliedert ist und zumindest einen Überwachungsmechanismus für den Datentransfer bereitstellt.
Vorrichtung zum Verwalten eines Datentransfers von Objekten von zumindest einer Source-Applikation (10) an zumindest eine Sink-Applikation (12), umfassend: – zumindest einen Serializer-Controller (SC), der den Datentransfer steuert und/oder überwacht – eine Pipeline, die zum sukzessiven Verarbeiten der Daten für den Transfer bestimmt ist und zumindest folgendes umfasst: – zumindest einen Serializer (S), welcher eine Objektstruktur der zu übertragenden Daten kennt, der dazu bestimmt ist, die verschiedenen Bestandteile eines Objekts in einem Datenstrom vor dem Transfer in einzelne Chunks zu zerlegen und nach dem Transfer die Chunks wieder zu einem Datenstrom zusammenzusetzen, – zumindest einen Carrier (Ca), der dazu bestimmt ist, die physikalische Datenübertragung auszuführen, wobei der Datentransfer verwaltet wird mit: – einem zentralen Controller (16), der eine Vorbereitung des Datentransfers steuert und/oder überwacht, und/oder die Source-Applikation (10) und Sink-Applikation (12) für den jeweiligen Datentransfer und/oder die passenden Module (S, Co, M, Ca) der Pipeline bestimmt, den Auf- und Abbau der Pipeline steuert und/oder überwacht und/oder Konfigurationen für den Datentransfer an Transfererfordernisse anpasst und mit – einem Message System (18), das zentral fungiert und alle relevanten Statusinformationen bezüglich des Datentransfers sammelt und/oder Statusveränderungen an beteiligte Module weiterleitet, und wobei eine Reihenfolge der zu transferierenden Objekte auch während des Transfers dynamisch an Anforderungen der Sink-Applikation (12) angepasst werden kann.
Vorrichtung nach Anspruch 22, dadurch gekennzeichnet, dass die Vorrichtung zumindest einen Requester (R) umfasst, der den Transfer der Daten initiiert.
Vorrichtung nach zumindest einem der Ansprüche 22 oder 23, dadurch gekennzeichnet, dass der Controller (16), in einer hierarchisch übergeordneten Ebene über den anderen Modulen (S, Co, M, Ca, SC) der Pipeline und/oder auf der Ebene der Applikationen (10, 12) und des Message Systems (18) eingegliedert ist und zumindest einen Überwachungsmechanismus für den Datentransfer bereitstellt.