DE102006051189A1

DE102006051189A1 - Verfahren und System zum Ausführen und Konfigurieren von Applikationen abhängig von einer Einsatzumgebung

Info

Publication number: DE102006051189A1
Application number: DE102006051189A
Authority: DE
Inventors: Detlef Becker; Karlheinz Dorn; Hans-Martin von Dr. Stockhausen
Original assignee: Siemens AG
Current assignee: Siemens AG
Priority date: 2006-10-30
Filing date: 2006-10-30
Publication date: 2008-05-08
Also published as: CN101174219A; US20080141234A1

Abstract

Die Erfindung ist auf Verfahren zum Erstellen und Ausführen zumindest einer Applikation in Abhängigkeit von einer Einsatzumgebung gerichtet. Ein Verfahren weist bezüglich der Erstellung die folgenden Schritte auf: Bereitstellen einer Menge von Modulen, in denen jeweils zumindest eine Funktionalität zum Erstellen der Applikation implementiert ist, Auswahl von für die jeweilige Applikation benötigten Funktionalitäten und Konfigurieren der ausgewählten Funktionalitäten zu einer Applikation, wobei die Module bereits als compilierter ausführbarer Programmcode vorliegen und zumindest bestimmte Module für unterschiedliche Einsatzumgebungen ausgelegt sind und wobei Module automatisch ausgewählt werden und die Applikation so konfiguriert wird, dass zur Laufzeit zu unterschiedlich erkannten Einsatzumgebungen passende Module dynamisch zusammenschaltbar sind, ohne dass die Applikation neu compiliert werden muss.

Description

Die Erfindung liegt auf dem Gebiet der Applikations- und/oder Taskflow-Verwaltung, insbesondere im medizintechnischen Bereich.
Die Erfindung betrifft insbesondere ein Verfahren und System zum Konfigurieren und Ausführen einer Applikation bei variabler Einsatzumgebung und einen Ansatz zur Programmierung solcher Konfigurationen.
Auf dem Gebiet der Applikations-Entwicklung von medizinischen Imaging-Applikationen ist es beim heutigen Stand der Technik vorgesehen, eine Applikation nahezu ausschließlich monolithisch zu erstellen und somit einen Applikationsblock vorzusehen, der den entsprechend bei notwendigen Änderungen (neue Updates, neue Versionen etc.) immer wieder geändert werden muss. Dies führt zu einem erhöhten Aufwand bei der Erstellung der Applikation und bei deren Wartung. Darüber hinaus sind diese monolithisch-basierten Systeme relativ fehleranfällig. Bei den bisherigen Applikationssystemen ist es häufig vorgesehen, eine Applikation aus einzelnen Bibliotheken zusammen zu "linken" und innerhalb eines Executables zur Ausführung zu bringen.
Soll nun eine solche Applikation geändert werden bzw. soll sie an andere Einsatzumgebungen oder an andere Deployments oder an eine andere zugrunde liegende Architektur angepasst werden, so sind in der Regel relativ umfangreiche Anpassungs-Maßnahmen notwendig. Insbesondere ist es notwendig, einen neuen Sourcecode zu erstellen, der nochmals übersetzt (compiliert) werden muss, um eine ausführbare Datei (Executable) zu erhalten. Dieses bisherige Vorgehen ist nachteiligerweise relativ zeit- und arbeitsaufwendig.
Die heutige Software-Technologie ist nicht hinreichend flexibel, um sich, insbesondere ohne Änderungen an Programmen und damit dem Vorhalten mehrerer Programmversionen, an unterschiedliche Einsatzumgebungen, wie insbesondere Deployments, anzupassen. Unter Einsatzumgebung ist hierbei die Gesamtheit aller Rahmbedingungen zu verstehen, die ein bestimmtes Programm beim Beginn und während seiner Ausführung vorfinden kann. Darunter sind insbesondere Deployments, also beabsichtigte, vorab bestimmte Strategien des Ablaufens von Programmkomponenten auf bestimmten Rechnern und die Verteilung der einzelnen Komponenten auf den Rechnern zur Laufzeit, aber darüber hinaus oder alternativ auch solche Größen wie Leistungsfähigkeit des Rechners (z.B. Operationen pro Zeiteinheit), Standort, Verbindung zu einem Daten liefernden Netzwerk etc. zu verstehen. Im Bereich der Medizintechnik beispielsweise besteht das von der Firma Siemens entwickelte System „syngo"^® aus einer Reihe von Einzelapplikationen, die in der Lage sind, mit medizinischen Daten wie beispielsweise Bilddaten aus Computer-Tomographen etc. umzugehen und diese zu prozessieren. Jedoch können diese monolithischen Programme sich nicht der gewünschten Einsatzumgebung anpassen, so dass verschiedene Varianten der Programme vorgehalten werden müssen. Daher müssen beispielsweise verschiedene Arten von Zugriffen implementiert werden, wie etwa zustandsbehaftete (stateful) Zugriffe bei festen Netzwerkverbindungen oder lokaler Ausführung, während Web-Zugriffe, bedingt durch das verwendete HTTP-Protokoll, zustandsfreie (stateless) Zugriffe erfordern. Entsprechend mussten verschiedene Versionen dieser monolithischen Programme für Desktop und Web-Einsatz programmiert werden.
Auch die Abfolge verschiedener Applikationen innerhalb eines Taskflows, sofern ein Taskflow implementiert war, bestand lediglich in einer statischen Aneinanderreihung vorgegebener Applikationen, welche vorab festgelegt wurden und nicht durch die Gegebenheiten des konkreten Einsatzes modifiziert werden konnten.
Schließlich ist es derzeit ebenfalls nur sehr eingeschränkt möglich oder sogar unmöglich, einen Taskflow, beispielsweise einen klinischen Taskflow, während der Bearbeitung zu unterbrechen, an einem anderen Ort fortzusetzen, und gegebenenfalls darüber hinaus an dem ursprünglichen Ort abzuschließen, weil keine Adaption der Applikationen an die sich ändernden Umgebungen möglich war.
Bisherige Lösungsansätze beinhalteten eine Trennung zwischen den verschiedenen Varianten von Applikationen, beispielsweise zwischen Desktop und Web-Applikationen. Es mussten daher zwei verschiedene Applikations-Architekturen und Quellcode-Stämme entwickelt und gepflegt werden, wenn eine Applikation sowohl für Desktop- als auch im Web-Einsatz war bzw. auf Computern sehr unterschiedlicher Hardware-Konfigurationen oder mit/ohne Netzwerkzugriff vorgesehen war. Geschäfts-Prozesse für die medizinische Bildgebung, die aus solchen Einzel-Applikationen bestanden, gab es aufgrund der Limitationen in der Regel nicht.
Die vorliegende Erfindung hat sich deshalb zur Aufgabe gestellt, einen Weg aufzuzeigen, mit dem es möglich ist, den Entwicklungsprozess für Applikationen im medizinischen Umfeld zu erleichtern und insbesondere beschleunigen zu können und der die Flexibilität bei der Erstellung der Applikationen erhöht, und der eine flexible Anpassung von Taskflow-Applikationen, auch zeitdynamisch, ohne Neuprogrammierung an die Einsatzumgebungen, insbesondere Deployments, gestattet.
Diese Aufgabe wird durch Verfahren und ein System gemäß den beiliegenden unabhängigen Ansprüchen gelöst.
Die vorliegende Erfindung wird nachstehend im Hinblick auf ein Verfahren beschrieben. Hierbei erwähnte Vorteile, Merkmale und alternative Ausführungsformen sind ebenso auf das andere beanspruchte Verfahren, auf ein System oder auf ein Produkt anzuwenden. Dementsprechend können diese gegenständlichen Ansprüche ebenfalls mit den Merkmalen weitergebildet sein, die in Zusammenhang mit einem der Verfahren beschrieben oder beansprucht worden sind und umgekehrt.
Die Aufgabe wird insbesondere durch ein Verfahren zum Erstellen einer modularen Applikation gelöst, mit folgenden Verfahrensschritten:

– Bereitstellen einer Menge von Modulen, in denen jeweils zumindest eine Funktionalität zum Erstellen der Applikation implementiert ist,
– Auswahl von für die jeweilige Applikation benötigten Funktionalitäten, und
– Konfigurieren der ausgewählten Funktionalitäten zu einer Applikation,

Unter einer Einsatzumgebung sind all jene Aspekte außerhalb einer Applikation zu verstehen, die auf das Laufzeitverhalten der Applikation oder ihre Wechselwirkung mit der Hardware oder anderen Applikationen innerhalb des Zielrechners bzw. Clients Einfluss nehmen. Beispiele für Aspekte der Einsatzumgebung sind die Rechenleistung des Zielrechners, der zur Verfügung stehende Speicherplatz, seien dies Festplatten, optische Platten oder Hauptspeicherplatz, die vorhandenen Grafikausgabefähigkeiten bzw. -optionen, Netzwerkeinbindung, der Standort des Gerätes und/oder die Verwendung des Zielrechners. Die Rechenleistung kann maßgeblich in das Laufzeitverhalten des Zielrechners bei der Ausführung einer Applikation hineinwirken, ebenso wie der insgesamt zur Verfügung stehende Speicherplatz. Grafikausgabeoptionen, insbesondere bei grafischen Coprozessoren, wie sie Stand der Technik sind, beeinflussen ebenfalls die Ausgabemöglichkeiten von Applikationen, sei es hinsichtlich der Auflösung, der Farbigkeit oder der Möglichkeit zur dreidimensionalen Darstellung von Daten. Die Netzwerkeinbindung, das heißt Geschwindigkeit, Art und Zustand einer Verbindung des Zielrechners mit dem Netzwerk kann ebenfalls mit der Ausführung der Applikation interferieren. Der Standort des Zielrechners, beispielsweise innerhalb einer vorgegebenen Umgebung einer Klinik oder mobil zum Verwenden für zuhause, nimmt ebenfalls Einfluss auf die Ausführung von Applikationen. Darüber hinaus kann die Einsatzumgebung eine Deploymentstrategie für den Zielrechner umfassen.
Die Verwendung des Rechners ist schließlich eine Meta-Größe, die trotzdem Einfluss auf die Applikation haben kann, da beispielsweise von mehreren Personen verwendete Zielrechner eine Ressourcenaufteilung erfahren, bzw. Varianten von Applikationen den unterschiedlichen Verwendungszwecken Rechnung tragen können. In einer Ausführungsform wird der Begriff „Zielrechner" als Synonym zum Begriff „Client" verwendet.
Die erfindungsgemäße Lösung basiert auf einer n-schichtigen Systemarchitektur, die aus unterschiedlichen Komponenten bestehen, die ihrerseits unterschiedlichen Schichten zugeordnet sind. Die Trennung der Softwareschichten legt beispielsweise fest, welche Anteile der Applikation auf einem Server und welche Anteile der Applikation auf einem Client ausgeführt werden sollen. Erfindungsgemäß ist es möglich, eine dynamische Verschaltung der Module zu gewährleisten, so dass die Applikation sowohl in einem Web-Deployment als auch in einem Desktop-Deployment eingesetzt werden kann, ohne dass eine Änderung und eine erneute Compilierung notwendig sind. Die Einsatzumgebung umfasst somit einen Online-Modus oder einen Offline-Modus und/oder unterschiedliche Deployments.
Vorzugsweise umfasst die Applikation jeweils Module in einem Frontend (Präsentationsschicht) und in einem Backend (Geschäftlogik), wobei zumindest jeweils ein Modul aus dem Frontend mit zumindest einem Modul aus dem Backend über Datenpfade verschaltet werden kann.
Durch den erfindungsgemäß modularen Aufbau, umfassend eine Vielzahl von Modulen zur Erstellung der Applikationen, ist es vorteilhafter Weise einfach und schnell möglich, die Menge der Module zu erweitern und/oder durch andere zu ersetzen, ohne dass weitere Änderungen notwendig sind. So kann beispielsweise eine neue Version eines einzelnen Moduls ausgeliefert werden, ohne dass es erforderlich ist, die gesamte Applikation neu compilieren zu müssen.
Bei den "Modulen" handelt es sich um Applikationen, Applikations-Komponenten oder sonstige Teilmodule, die als ausführbarer Programmcode vorliegen und somit bereits übersetzt sind. Der Inhalt dieser Module ist in keiner Weise beschränkt und kann auf unterschiedlichste Funktionalitäten bezogen sein, wie beispielsweise eine Viewing-Modalität, eine Reporting-Modalität, ein Volume-Modul, ein 3D-Modul, ein Transfer-Modul etc. Die Module können vorzugsweise voneinander getrennt und funktional unabhängig sein. Sie können bausteinartig mit anderen Modulen kombiniert werden. Darüber hinaus ist es möglich, dass ein Modul jeweils in verschiedenen Versionen vorliegt. Erfindungsgemäß wird automatisch die Version zur Erstellung der Applikation verwendet, die kompatibel zu den anderen zu verwendenden Modulen bzw. Schichten ist, insbesondere kann die Schicht darüber die jeweils passende Version des Moduls einer darunter liegenden Schicht wählen. Das Zusammenschalten der ausgewählten Module erfolgt vorzugsweise dynamisch, so dass hier auch konfigurierbare Parameter mit einfließen können. Die Module können zur Laufzeit aufgerufen und/oder zur Compilezeit von der Applikation – in der Regel durch Aufruf – eingebunden werden. Darüber hinaus ist es möglich, einzelne Module (z.B. aus einem spezifisch ausgewählten Toolkit, umfassend eine Menge von Business-Komponenten) gegeneinander auszutauschen, sogar in unterschiedlichen Versionen und ohne, dass das gesamte Toolkit neu übersetzt werden muss (wie es bei den heute bekannten Libraries der Fall ist). Vorzugsweise sind die Funktionalitäten, Module und/oder Services bzw. bereit gestellten Dienstleistungen gekapselt.
In der bevorzugten Ausführungsform basiert die erfindungsgemäße Lösung auf der von der Firma Microsoft entwickelten .NET-Technologie unter Berücksichtigung des und erfindungsgemäßen Konzeptes, basierend auf einer Komponenten-Architektur. Damit wird es möglich, medizinische Applikationen sehr einfach und schnell zu generieren, die in unterschiedlichen Einsatzumgebungen (z. B. Desktop-Einsatz oder Web-Einsatz) und in unterschiedlichen Versionen eingesetzt werden können. Vorteilhafterweise muss sich der Applikations-Entwicklungs-Ingenieur nicht um die unterschiedlichen Versionen der jeweiligen Module kümmern. Die Module garantieren darüber hinaus, dass eine Applikation sehr schnell generiert werden kann. Dies ist insbesondere im Rahmen eines so genannten Rapid-Application-Development (RAD) ein wichtiger Vorteil.
Die erfindungsgemäß generierten Applikationen können in einem weiteren Schritt zu einem Taskflow verschaltet werden und somit zu einer Implementierung von unterschiedlichen Geschäfts-Prozessen im Rahmen einer medizinischen Bildverarbeitung verwendet werden oder in Geschäfts-Prozessen wieder eingesetzt werden, ohne dass die gesamte Applikation neu übersetzt werden muss. Durch das modulare Konzept ist es möglich, dass eine Applikation automatisch in demselben oder in anderen Geschäfts-Prozessen wieder verwendet werden kann, ohne dass sie neu programmiert oder anderweitig angepasst werden muss.
Darüber hinaus ist ein Vorteil darin zu sehen, dass sich der Applikations-Entwicklungs-Ingenieur nur mit den Modulen befassen muss, die für die Erstellung seiner Applikation relevant sind. Damit ist es möglich, die Applikation ressourcensparender zu implementieren.
In der bevorzugten Ausführungsform handelt es sich um eine 5-schichtige Architektur, insbesondere um eine Software-Architektur. In alternativen Ausführungsformen ist es jedoch jederzeit möglich, eine andere Strukturierung der Architektur zu bestimmen. Beginnend bei der hierarchisch an oberster Stelle angeordneten Schicht der 5-schichtigen Architektur umfasst diese folgende Schichten:

– Eine Präsentationsschicht, die zur Darstellung der Daten bestimmt ist und somit ein Frontend darstellt.
– Eine Geschäftsprozess-Schicht, die unterschiedliche Business-Prozess-Logik-Module bzw. Geschäfts-Prozess-Logik-Module umfasst und auch als Web-Layer bezeichnet werden kann;
– eine Controllerschicht, die zur Bereitstellung von Business-Forms bestimmt ist,
– eine Geschäftslogik-Schicht, die zum Bereitstellen von unterschiedlichen Business-Komponenten dient und
– eine Serviceschicht, die zum Bereitstellen von Daten-, Transfer- und/oder Infrastruktur-Services in Form von lokalen und remoten Service-Komponenten bestimmt ist.

Das Konzept der n-schichtigen Applikationen bzw. N-Tier-Applikationen ist im Stand der Technik bekannt und wurde ansatzweise oben stehend anhand der Dreischichten-Präsentationssteuerung und Modell der Aktivitäten bei syngo.NET^® vom Prinzip her bereits vorgestellt. Die grundlegende Idee der Trennung der einzelnen Funktionsebenen ist ansonsten beispielsweise aus Netzwerkprotokollen wie TCP/IP oder dem ISO-Schichtenmodell bekannt. In einer Variante der Erfindung ist vorgesehen, anhand der erkannten Einsatzumgebung festzulegen, welche Schichten des Modells auf dem Zielrechner installiert werden und welche außerhalb des Rechners verbleiben und beispielsweise über ein Netzwerk zugänglich sind. Unter einer Applikationsschicht ist damit ein Bestandteil der Applikation mit logisch gruppierter Funktionalität zu verstehen, der im Hinblick auf das erfindungsgemäße Verfahren als Block angesehen werden kann und, unbeschadet weiterer Ausführungsform der Erfindung, als solcher in den Hauptspeicher geladen wird.
Durch die Komponenten-Architektur und die Verschaltung der unterschiedlichen Module in der medizinischen Domäne ist eine hinsichtlich der Effizienz optimierte Applikationserstellung möglich. Alle Module, insbesondere die Business- und die Service-Komponenten sind versionierbar. „Versionierbar" soll im Rahmen dieser Erfindung bedeuten, dass Module bzw. Komponenten einer oder unterschiedlicher Applikationen in jeweils unterschiedlichen Versionen nebeneinander, bzw. parallel, eingesetzt, zu einer Applikation verschaltet und/oder angewendet werden können.
Erfindungsgemäß greift das Verfahren auf eine (Taskflow-)Manager-Instanz zu, die als separate ausführbare Datei vorgesehen ist und zum Bearbeiten von Taskflow-Instanzen bestimmt ist, die innerhalb eines Applikations-Containers bzw. innerhalb eines Containers ablaufen. Der Manager erlaubt ein Warten, einen Abbruch, eine Wiederaufnahme auch auf entfernten Maschinen (remote), eine Aktivierung bzw. Deaktivierung einer Benutzeroberfläche, einen Abbruch (Stop) und ein Vervollständigen von Taskflow-Instanzen. Falls es vorgesehen ist, einen Taskflow zu starten, der auf der jeweiligen Maschine nicht verfügbar ist, so wird dieser Taskflow durch ein so genanntes "zero-admin-deployment" auf der jeweiligen Client-Maschine installiert. Der Begriff "zero-admin-deployment" kennzeichnet sich durch die Funktionalität, dass jeglicher Verwaltungsaufwand für ein Deployment des Moduls vermieden wird. Jeglicher Verwaltungsaufwand ist somit vollständig von der jeweiligen Applikation entkoppelt.
Erfindungsgemäß können folgende Deployment-Szenarien für die Taskflow-Aktivitäten abgedeckt werden:

– Thin-Client,
– Rich-Thin-Client,
– Rich-Client,
– Adaptive-Client
– Fat-Client und
– Web-Service.

Der Manager umfasst eine Benutzeroberfläche, die zur tabellenartigen Anzeige folgender Parameter bestimmt ist:

– Taskflow-ID, der eineindeutig den jeweiligen Taskflow kennzeichnet,
– den Status des Taskflows. Hier ist gekennzeichnet, ob der Taskflow bereits initialisiert ist oder nicht;
– das Datum der Taskflow-Generierung;
– die aktuelle, gerade laufende Aktivität,
– der aktuelle, gerade ausgeführte Task und
– der Name der Maschine.

In einer weiteren vorteilhaften Ausführungsform greift das erfindungsgemäße Verfahren auf einen so genannten Versions-Mechanismus zu, der dazu bestimmt ist, dass automatisch aus der Menge der grundsätzlich verfügbaren Module das jeweils relevante Modul ausgewählt wird, das für die jeweilige Applikation in der jeweiligen Einsatzumgebung optimal geeignet ist. Insbesondere wird hier die optimierte Version des jeweiligen Moduls bestimmt. Damit kann ein weiterer Flexibilitätsgrad erreicht werden. Darüber hinaus kann das Fehlerpotenzial gesenkt werden, das bisher dadurch entstanden ist, indem falsche oder nicht zueinander passende Versionen von Modulen verwendet worden sind.
Die erfindungsgemäße Lösung basiert auf einem spezifischen Architekturmodell, das sowohl in logischer, als auch in physikalischer Hinsicht weiter unten detaillierter beschrieben werden wird. Neben den vorstehend erwähnten fünf Schichten umfasst es mehrere Komponenten, die jeweils einer Schicht zugeordnet sind und auf vielfältige Weise miteinander verschaltet werden können. Dabei können individuelle Komponenten und Module isoliert und unabhängig voneinander in unterschiedlichen Applikationen verschaltet werden. Die Verschaltung der einzelnen Komponenten der unterschiedlichen Schichten wird vorzugsweise durch den Manager ausgeführt.
In der bevorzugten Ausführungsform der Erfindung ist das Verfahren zum Erstellen einer Applikation ausgerichtet. In einer Weiterbildung ist es vorgesehen, das Verfahren (und entsprechend auch das System) ebenso auch zum Betreiben und/oder zum Warten einer Applikation auszubilden. Darüber hinaus können mit dem erfindungsgemäßen Verfahren neben den Applikationen selbst auch separate Komponenten einer Applikation erstellt werden. Hierfür ist ein generischer Entwicklungsrahmen vorgesehen.
Es sei darauf hingewiesen, dass die Abfolge der Schritte des Verfahrens nicht zwingend eingehalten werden muss und Alternativen auch eine andere Reihenfolge der Verfahrensschritte oder ein zeitliches Vorziehen einzelner Schritte vorsehen.
Eine weitere Lösung der erfindungsgemäßen Aufgabe liegt in einem Produkt, das insbesondere als Computerprogrammprodukt ausgebildet sein kann und Hardwaremodule und/oder Softwaremodule umfasst, und zur Bereitstellung einer Infrastruktur für die Kommunikation von einer Vielzahl von Applikationen bestimmt ist. Das Produkt ist mit den Merkmalen des Verfahrens ausgebildet. Dabei ist zu beachten, dass ein Teil des Produktes auf einem Client und ein anderer verbleibender Teil auf dem Server ausgebildet sein können. In anderen Ausführungsformen kann das Produkt ebenso als verteiltes Produkt auf einer anderen Architektur abgebildet sein.
In einem weiteren Aspekt ist die Erfindung gerichtet auf ein Verfahren zum Ausführen zumindest einer modularen Applikation, in Abhängigkeit von einer Einsatzumgebung eines Zielrechners, mit folgenden Schritten:

– Feststellen einer auf dem Zielrechner vorhandenen Einsatzumgebung; und
– Laden von Modulen der Applikation in den Zielrechner und deren dynamische Zusammenschaltung in Abhängigkeit von der erkannten Einsatzumgebung anhand einer vorab festgelegten Konfiguration der Applikation, und deren Ausführen.

Unter einem Zielrechner ist im Sinne der vorliegenden Erfindung ein Computer oder eine ähnliche Datenverarbeitungsanlage zu verstehen, der/die zur Ausführung eines Taskflows bestimmt ist und in deren Speicher, beispielsweise deren Hauptspeicher, die zur Ausführung des Taskflows notwendigen Applikationen bzw. Bestandteile dieser Applikationen geladen werden können, die nachfolgend von einer Zentraleinheit des Zielrechners ausgeführt werden können.
Unter einem „Feststellen" der Einsatzumgebung ist im Sinne der vorliegenden Erfindung zu verstehen, dass entweder anhand von auf dem Zielrechner befindlichen Informationsdaten (z.B. bezüglich der Deploymentstrategie) oder durch direkte Abfrage der Hardware und ihrer Zustände oder durch eine Kombination dieser Möglichkeiten eine Übersicht der Einsatzumgebung erstellen wird, die das System in die Lage versetzt, festzulegen, wie die Applikationen konfiguriert werden müssen. Die Einsatzumgebung kann beispielsweise durch eine auf dem Zielrechner befindliche Datenstruktur definiert sein, die ausgelesen und ausgewertet werden kann. Die Datenstruktur kann vorzugsweise eine XML-basierte Datenstruktur sein. Es können auch Tests bzw. Benchmarks auf dem Zielrechner durchgeführt werden, um Aspekte der Einsatzumgebung erkennen zu können, was alternativ oder zusätzlich zu der Datenstruktur erfolgen kann. Es kann bei der Feststellung der Einsatzumgebung auch auf Funktionen des Betriebssystems oder einer Laufzeitumgebung zurückgegriffen werden, um die Einsatzumgebung zu bestimmen. Die Feststellung kann beispielsweise durch eine erste Applikation erfolgen, die entweder selbstständig oder in einem sie einbettenden Applikationscontainer etc. auf einem entsprechenden Computer lauffähig ist. Funktionell impliziert es die Fähigkeit, die Einsatzumgebung durch geeignete Funktionen erkennen bzw. bestimmen zu können.
Erfindungsgemäß werden die derart konfigurierten Applikationen dann in ihren Modulen in den Zielrechner geladen und ausgeführt. Unter Modulen von Applikationen sind hierbei alle Arten von im Stand der Technik bekannten Komponenten von Ap plikationen zu verstehen, die insgesamt zu ablauffähigen gruppierten Funktionalitäten innerhalb einer Applikation führen. Als Beispiel für Module sei kurz auf die Funktionalität der von Siemens entwickelten syngo.NET^®-Umgebung zur Darstellung und Auswertung medizinischer Daten verwiesen. Bei syngo.NET sind die einzelnen Applikationen eines Taskflows als so genannte Applikationscontainer ausgeführt. Dieser besteht aus der eigentlichen Aktivität, welche die Funktionalität der Applikation bezüglich der medizinischen Daten implementiert, sowie aus einer Reihe weiterer Teile, die eine Ablaufumgebung für die Aktivität zur Verfügung stellen und der Einbindung in ein Betriebssystem dienen. Hierzu gehört beispielsweise die Bereitstellung eines Menüs, mit dem die Aktivität gesteuert werden kann, einer Statusbar zur Anzeige des Status der Aktivität, eine Gruppe von generischen Views (Ansichten) zur Darstellung von Daten, einer Steuerung des Containers, Modellkomponenten zur Verarbeitung und zum Zugriff auf Daten etc. Aktivitäten wiederum bestehen aus den drei Bestandteilen (Tasks bzw. Komponenten) View, Controller und Model, wobei View Funktionalitäten zur Anzeige und Interaktion mit dem Benutzer enthält, Model die Mechanismen zum Verarbeiten und Zugreifen von Daten und der Controller die Steuerung des Ablaufs innerhalb der Aktivität sowie der Interaktion von View und Model übernimmt. Jede dieser Tasks wiederum besteht aus einer Anzahl von Tasksteps, die nacheinander abgearbeitet werden sollen und die ihrerseits wiederum aus einer Anzahl von Komponenten bestehen. Die Interaktion einer Aktivität bzw. eines Tasksteps mit der Umgebung, das heißt mit dem Container, aber auch mit vorhergehenden und nachfolgenden Applikationen, Aktivitäten oder Tasksteps erfolgt mittels so genannter Ports, die durch den Controller der jeweiligen Ebene implementiert werden.
Alle oben verwendeten Begrifflichkeiten zur Kennzeichnung von Teilen der vorgestellten Applikation in SYNGO.NET sind hierbei als Bestandteile der Applikationen im Sinne der Erfindung zu verstehen.
Vorzugsweise bilden mehrere Applikationen einen Taskflow, d.h. eine Abfolge von kooperierenden Applikationen mit Daten- und Statusübergabe.
In einer bevorzugten Ausführungsform ist das Verfahren durch die weiteren folgenden Schritte gekennzeichnet:

– periodisches Feststellen der Einsatzumgebung, um Änderungen oder geplante Änderungen der Einsatzumgebung zu erkennen, und
– nach Erkennen einer Änderung oder geplanten Änderung bedarfsweises Nachladen und/oder Ersetzens von Modulen der Applikationen, die zu der geänderten Einsatzumgebung passen.

Das periodische Feststellen der Einsatzumgebung hilft dabei, Änderungen der Einsatzumgebung zu erkennen, um dynamisch, das heißt bereits zur Laufzeit der Applikation bzw. des Taskflows aus Applikationen, die Applikationen so modifizieren zu können, dass sie sich den geänderten Bedingungen in optimaler Weise anpassen. Ein Beispiel für eine geänderte Einsatzumgebung ist das Einloggen weiterer Benutzer an einem Mehrbenutzersystem (veränderte Ressourcenverteilung), aber auch das Trennen einer Netzwerkverbindung, so dass Netzwerkdienste nicht mehr zur Verfügung stehen und durch Nachladen geeigneter Module von Applikationen emuliert werden müssen, wobei das Nachladen der Applikationsmodule auch darin bestehen kann, diese so auszuführen, dass die notwendigen Daten zur Bearbeitung ohne Netzwerkverbindung lokal verfügbar gemacht werden können, beispielsweise sogar, bevor die Netzwerkverbindung getrennt wird, sofern die zu erwartende Trennung rechtzeitig erkannt wird, z.B. durch die Abmeldung des Anwenders.
Das erfindungsgemäße Verfahren kann unter automatischer Anbindung an zentrale oder entfernte (remote) Service-Infrastrukturen zur Unterstützung eines Online- und Offline- Betriebs erfolgen, wobei Daten und/oder Dienste lokal und/oder über ein Netzwerk bereitgestellt werden können.
Vorzugsweise sind die Applikationen so genannte n-schichtige Applikationen, wobei anhand von Informationen eine Einsatzumgebung festgestellt und entsprechend passende Schichten der Applikation zur Ausführung in den Hauptspeicher geladen werden und gegebenenfalls Verbindungen über ein Netzwerk zu benötigten Diensten hergestellt werden, die den geladenen Schichten die Funktionalität der nicht-geladenen Schichten bereitstellt.
Unter einer Deployment-Strategie ist im Sinne der vorliegenden Erfindung eine strategische Entscheidung darüber zu verstehen, zu welcher Einsatzumgebung welche Bestandteile des Schichtenaufbaus lokal und welche remote gehören sollen. Ein Deployment kann demnach durch die aktuell vorhandene Einsatzumgebung charakterisiert werden, also z.B. ein Deployment für Web-Einsatz, ein Deployment für einen Desktop-Einsatz etc..
Unter einem Laden von Schichten in den Hauptspeicher eines Zielrechners ist zu verstehen, dass mittels Betriebssystem-Funktionalitäten ein Speicherplatz im Hauptspeicher bereitgestellt wird, die einzelnen Bestandteile einer zu ladenden Schicht bzw. die Schicht als solche von einem Massenspeicher ausgelesen wird und die Binärdaten der Schicht (ausführbarer Code) in den Hauptspeicher übertragen werden. Unter Ausführung ist zu verstehen, dass die Zentraleinheit des Zielrechners den im Hauptspeicher befindlichen Programmcode der Applikationsschichten in üblicher Weise abarbeitet. Unter einer nicht-geladenen Schicht ist dementsprechend eine solche zu verstehen, die nicht im Hauptspeicher des Zielrechners residiert.
Vorzugsweise weisen die n-schichtigen Applikationen zumindest eine Präsentationsschicht zur Darstellung von Informationen und für Benutzerinteraktionen, eine Geschäftsprozess-Schicht, die unterschiedliche Geschäfts-Prozess-Logik-Module umfasst, eine Controllerschicht, die zur Bereitstellung von Business-Forms bestimmt ist, eine Geschäftslogik-Schicht, die zum Bereitstellen von unterschiedlichen Business-Komponenten dient und eine Serviceschicht, die zum Bereitstellen von Daten-, Transfer- und/oder Infrastruktur-Services in Form von lokalen und remoten Service-Komponenten bestimmt ist.
Die Serviceschicht kann eine zustandsbehaftete (stateful) Zugriffsschicht zum Zugriff auf bzw. zur Bereitstellung von Daten und Diensten lokal oder über ein Netzwerk, und eine zustandsfreie (stateless) Zugriffsschicht zum Zugriff auf bzw. zur Bereitstellung von Daten und/oder Diensten lokal und/oder über ein Netzwerk beinhalten.
Dieser fünfschichtige Aufbau entspricht im Wesentlichen dem bereits oben vorgestellten Modell, erweitert um Serviceschichten zur Bereitstellung von Daten und Diensten. Ein maßgeblicher Kern dieses Aspektes der Erfindung liegt in der Ausführung mit zwei Serviceschichten, von denen eine obere zustandsbehaftet ist und eine untere zustandsfrei ist. Die zustandsbehaftete Zugriffsschicht stellt alle notwendigen Funktionen für die darüber liegenden Schichten bereit, so dass diese in der Regel nicht auf die untenliegende zustandsfreie Schicht zugreifen müssen und daher deren Zustand nicht berücksichtigen müssen. Vielmehr ist ausschließlich die zustandsbehaftete Serviceschicht für die Implementierung aller Zugriffe auf Daten und Dienste zuständig. Damit wird erreicht, dass die darüber liegenden Schichten bezüglich der Verfügbarkeit „lokal" oder „remote" grundsätzlich nicht an die darunter liegenden Schichten angepasst werden müssen, sondern nach ihrer Programmierung unverändert bleiben können, unabhängig von der Einsatzumgebung. Dieses Konzept kann auch auf höhere Schichten erweitert werden.
In bevorzugten Ausführungsformen der Erfindung kann die Deployment-Strategie ein Fat-Client, ein Rich-Client, ein Rich-Thin-Client, ein Thin-Client und/oder ein Webservice sein. Beim Fat-Client werden alle Schichten der n-schichtigen Applikation auf dem Zielrechner ausgeführt. Es handelt sich damit um den Fall einer eigenständigen oder Stand-Alone-Applikation, die keinerlei Netzwerkverbindung aufweist, und bei der damit alle Dienste und Daten lokal verfügbar gemacht werden müssen. Beim Rich-Client wird nur die zustandsfreie Zugriffsschicht auf einem entfernten Rechner (Applikationsserver) ausgeführt, während die anderen Schichten auf dem Zielrechner verbleiben und dort ausgeführt werden. Die zustandsbehaftete Zugriffsschicht kümmert sich um die Interaktion mit der zustandsfreien Zugriffsschicht über das Netzwerk und um die Interaktion der darüber liegenden Geschäftsschicht oder den weiter oben liegenden Schichten.
Beim Rich-Thin-Client werden die Präsentationsschicht und optional die Geschäftsprozeß-Schicht auf dem Zielrechner ausgeführt, während die Controller-Schicht, die Geschäftslogik-Schicht und die Serviceschichten auf einem entfernten Rechner ausgeführt werden. Diese Deployment-Strategie eignet sich für leistungsschwächere Rechner bzw. für Rechner, die über eine schnelle Netzwerkverbindung mit Hochleistungsrechnern so verbunden sind, dass keine Engpässe bei der Netzwerkübertragung oder der Abarbeitung von Daten auf einem remoten Rechner zu erwarten sind. Dementsprechend kann der Rich-Thin-Client in der Leistungsfähigkeit des ihn implementierenden Zielrechners einfacher gehalten werden als beim Fat-Client oder beim Rich-Client.
Beim Thin-Client wird nur die Präsentationsschicht auf dem Zielrechner ausgeführt, während Geschäftsprozeß-Schicht, die Geschäftslogik-Schicht und eine lokale, zustandsbehaftete Service-Schicht auf einem Applikationsserver ausgeführt werden, und die remote, zustandsfreie Service-Schicht auf einem entfernten Dienstrechner ausgeführt wird. Bei dieser Deployment-Strategie sind drei verschiedene Rechner an der Abarbeitung der Applikation beteiligt, die miteinander in koordinierter Weise interagieren müssen.
Beim Job-Service schließlich wird ein html-basiertes Programm auf dem Zielrechner ausgeführt, wobei auch die Controller-Schicht innerhalb des Webbrowsers ablaufen kann, und andere zum Aufrufen der Applikationen notwendige Dienste werden auf einem Appliaktionsserver ausgeführt und kommunizieren mit den auf dem Zielrechner befindlichen Schichten über das im Web übliche HTTP-Protokoll oder ein vergleichbar geeignetes Protokoll. Vorzugsweise ist zumindest ein Teil der die Schichten bildenden Softwareobjekte unabhängig von der Deployment-Strategie programmiert, so dass diese lediglich einmal für alle unterschiedlichen Deployment-Strategien entwickelt werden müssen.
Vorzugsweise sind Präsentationsschicht, Geschäftsprozess-Schicht, Controllerschicht und Geschäftslogik-Schicht unabhängig von der Deployment-Strategie programmiert. Die zustandsbehaftete Zugriffsschicht der Serviceschicht kann dafür ausgelegt sein, Interaktionen mit den darüber liegenden Schichten so durchzuführen, dass die Deployment-Strategie für die darüber liegenden Schichten irrelevant ist, das heißt dass die zustandsbehaftete Zugriffsschicht die zustandsfreie Zugriffsschicht für die darüber liegenden Schichten transparent macht, um so deren Programmiervarianten in Abhängigkeit von der Deployment-Strategie zu verringern.
Die Einsatzumgebung kann weiterhin in einer bevorzugten Ausführungsform der Erfindung die Leistungsfähigkeit des Zielrechners umfassen (z. B. Rechenleistung, Speicherplatz etc.), wobei Module der Applikationen nachladbar sind, das heißt nachträglich geladen werden können, die hinsichtlich der verwendeten Algorithmen, der Komplexität der Anzeige von Benutzeroberflächenelementen und/oder der verfügbar gemachten Datenmenge zur Leistungsfähigkeit des Zielrechners passen. Bei dieser bevorzugten Ausführungsform wird in einzelne Module der jeweils verwendeten Applikationen eingegriffen, und diese werden modular zusammengestellt, so dass im Endeffekt erst zur Laufzeitumgebung festgelegt wird, welche Module von Ap plikationen vorhanden sind und wie die Gesamtapplikationen miteinander interagieren.
Die Einsatzumgebung kann weiterhin die Anzahl verfügbarer Bildschirme am Zielrechner umfassen, wobei Module von Applikationen nachladbar sind, die speziell zur Anzeige von Benutzeroberflächenelementen auf der vorhandenen Anzahl von Bildschirmen bestimmt sind. Hierdurch kann die jeweils anzeigende Applikation flexibel an die Situation der Bildschirme auf dem Zielrechner angepasst werden. Gerade im medizinischen Bereich kommt es häufig vor, dass an einem Rechner mehr als ein Bildschirm vorhanden ist, beispielsweise um Bilddaten an einem Arbeitsplatz bearbeiten und gleichzeitig der Kollegenschaft präsentieren zu können, um einen Diskussionsprozess zu Behandlungsstrategien etc. zu ermöglichen. Auch ist vorstellbar, dass mehr als ein Monitor an einem Zielrechner vorhanden ist, um dem Patienten gleichzeitig die Bilddaten präsentieren und durch den Arzt erläutern zu können. Hierbei muss die Anzeige von Daten aber auch von Menüpunkten, Schaltflächen etc. an den Bildschirm angepasst werden. So benötigen beispielsweise Bildschirme für Patienten keinerlei Bildelemente, welche eine Interaktion gestatten, da nur eine Darstellung notwendig ist, während am Arbeitsplatzbildschirm selbst die notwendigen Manipulationselemente vorhanden sein müssen. Auch bei Verwendung mehrerer Bildschirme als Arbeitsplatzbildschirme kann es wünschenswert sein, diese unterschiedlich zu gestalten, um insgesamt eine aufgeteilte Benutzeroberfläche zur Verwendung des Programms und seiner Bedienung bereitzustellen.
In noch einer bevorzugten Ausführungsform wird der Taskflow aus hintereinander geschalteten Applikationen generiert, die in verschiedenen Applikationsvarianten zur Verfügung stehen, wobei aus der Einsatzumgebung bestimmt wird, welche Applikationsvarianten im Taskflow hintereinander geschaltet werden. Die Erfindung beschränkt sich damit nicht nur auf die Konfiguration von Bestandteilen der einzelnen Applikationen, sondern ermöglicht auch ein flexibles Zusammensetzen des Taskflows aus Applikationen, die in unterschiedlichen Varianten vorliegen, um den Gesamt-Taskflow ebenfalls an die vorhandene Einsatzumgebung anpassen zu können.
Vorzugsweise besteht grundsätzlich der Taskflow in der vorliegenden Erfindung aus mehreren, das heißt mindestens zwei, hintereinander geschalteten n-schichtigen instanziierten Applikations-Containern. Unter einem Applikations-Container ist dabei eine Konstrukt zu verstehen, das neben dem eigentlichen semantischen Teil zur Bereitstellung einer Funktionalität auch Teile enthält, welche Allgemeinfunktionen zur Verfügung stellen, die in allen Applikations-Containern vorhanden sein müssen, wie bereits oben bei der Einführung in syngo.NET^® beschrieben.
Das Feststellen der Einsatzumgebung erfolgt vorzugsweise in dem ersten instanziierten Applikations-Containern im Taskflow, um bereits beim Starten des Taskflows und Laden der ersten Bestandteile das Erkennen der Einsatzumgebung zu ermöglichen, so dass eine frühzeitige Festlegung der notwendigen, festgestellten Bestandteile möglich ist.
Das Verfahren kann auf eine Taskflow-Manager-Instanz zugreifen, die als separate ausführbare Datei vorgesehen ist und zum Bearbeiten von Taskflow-Instanzen bestimmt ist, die innerhalb eines instanziierten Applikationscontainers ablaufen.
Vorzugsweise greift eine Geschäftsprozess-Schicht auf eine zentrale Strategiekomponente zu, insbesondere um einzelne Komponenten und/oder Instanzen zu verwalten.
In einer weiteren bevorzugten Ausführungsform ist die Einsatzumgebung durch eine auf dem Zielrechner befindliche Datenstruktur definiert. Damit kann vorab und ohne umständlichen Testroutinen bereits festgelegt werden, wie die Einsatzumgebung eines bestimmten Zielrechners aussieht und auch, welche Deployment-Strategie etc. zum Einsatz gebracht werden soll.
In einer weiteren Ausführungsform ist die Erfindung auf ein Taskflow-Architektur-System gerichtet. Bezüglich des Systems gilt alles bereits oben im Hinblick auf das Verfahren Gesagte und umgekehrt, so dass wechselweise Bezug genommen wird. Das erfindungsgemäße Taskflow-Architektur-System weist auf:

– zumindest eine, aus einer Mehrzahl von Modulen zusammengesetzte Applikation, und
– ein Konfigurierobjekt, das zum Laden von Modulen der zumindest einen Applikation in Abhängigkeit von einer festgestellten Einsatzumgebung bestimmt ist.

Die hier verwendeten Begriffe entsprechen den bereits oben hinsichtlich des Verfahrens angegebenen Definitionen.
Ein Konfigurierobjekt ist darüber hinaus ein programmtechnisches Objekt, wie ein Programm-Modul, ein Programmobjekt etc., das in der Lage ist, mit dem System so zu interagieren, dass es Kenntnis davon erlangt, welche Bestandteile der Applikationen für die erkannte Einsatzumgebung geladen werden müssen, und das entweder selbst oder mittels des Betriebssystems diese Bestandteile in den Hauptspeicher des Zielrechners hinein lädt und miteinander über die existierende Infrastruktur zusammenschaltet, um ablauffähige aus Bestandteilen bestehende Applikationen zu generieren. Dies kann durch Erstellen einer Liste oder anderen Datenstruktur mit zu ladenden Applikationsbestandteilen erfolgen.
Das Festellen der Einsatzumgebung kann periodisch erfolgen, um Änderungen oder einer geplante Änderungen der Einsatzumgebung zu erkennen; und das Konfigurierobjekt kann nach Erkennen einer Änderung oder geplanten Änderung Bedarfsweise zum Nachladen und/oder Ersetzen von Bestandteilen der Applikationen, die zu der geänderten Einsatzumgebung passen, bestimmt sein.
Wie vorstehend erwähnt umfasst die Einsatzumgebung vorzugsweise eine Deploymentstrategie, die Rechenleistung des Zielrechners, den zur Verfügung stehenden Speicherplatz, die vorhandenen Grafikausgabeoptionen, die Netzwerkeinbindung, den Standort des Zielrechners und/oder die Verwendung des Zielrechners.
Die im erfindungsgemäßen System eingesetzten Applikationen können n-schichtige Applikationen sein, wobei anhand der Einsatzumgebung eine für den Zielrechner bevorzugte Deployment-Strategie feststellbar ist und das Konfigurierobjekt entsprechend passende Schichten der Applikationen zur Ausführung in den Hauptspeicher lädt und gegebenenfalls Verbindungen über ein Netzwerk zu benötigten Diensten herstellt, die die Funktionalität der nicht-geladenen Schichten den geladenen Schichten bereitstellt.
Die n-schichtigen Applikationen können wie oben definiert aufgebaut sein.
Das Taskflow-Architektur-System gemäß der vorliegenden Erfindung kann weiterhin eine Deployment-Strategie umfassen, die oben angegeben worden ist.
Vorzugsweise umfasst die Einsatzumgebung begrifflich die Leistungsfähigkeit des Zielrechners, wobei Bestandteile der Applikationen des Taskflows nachladbar sind, die hinsichtlich der Verwendung in den Algorithmen, der Komplexität der Anzeige von Benutzeroberflächenelementen und/oder der verfügbar gemachten Datenmenge zur Leistungsfähigkeit des Zielrechners passen.
Weiterhin kann die Einsatzumgebung die Anzahl verfügbarer Bildschirme am Zielrechner umfassen, wobei Module von Applikationen nachladbar sind, die speziell zur Anzeige von Benutzeroberflächenelementen auf der vorhandenen Anzahl von Bildschirmen bestimmt sind.
Der mögliche Taskflow kann aus hintereinander geschalteten Applikationen bestehen, die in verschiedenen Applikationsvarianten zur Verfügung stehen, so dass weiterhin anhand der Einsatzumgebung erkannt werden kann, welche Applikationsvarianten im Taskflow hintereinander geschaltet werden sollen.
Der Taskflow kann vorzugsweise aus mehreren hintereinander geschalteten n-schichtigen Applikationscontainern bestehen.
Dabei kann das Konfigurierobjekt Bestandteil der ersten Applikationscontainers im Taskflow sein. Die Einsatzumgebung kann durch eine auf dem Zielrechner befindliche Datenstruktur definiert sein.
Weitere vorteilhafte Ausgestaltungen, Aspekte und Details ergeben sich aus den abhängigen Ansprüchen, der Beschreibung und den beigefügten Zeichnungen.
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 beispielhaft den Aufbau einer n-schichtigen Modulstruktur gemäß einer vorteilhaften Ausführungsform der vorliegenden Erfindung,
2 einen grundsätzlichen Aufbau eines Applikationscontainers von SYNGO.NET^® zur Erläuterung einer der Erfindung zugrunde liegenden Software-Architektur und
3 verschiedene erfindungsgemäße Deployment-Strategien.
Die Erfindung zielt allgemein darauf ab, dass durch die Entwicklung einer modularen Architektur, die beispielsweise auf der .NET-Technologie von Microsoft und einer flexiblen, auf einem Zielrechner beispielsweise per einer URL herunterladbaren Applikations-Architektur basiert, die eingangs beschriebenen Probleme gelöst werden. Die flexible, je nach Bedarf und Einsatzumgebung herunterladbare Applikations-Architektur spielt hierbei eine zentrale Rolle, weil sie erkennt, in welchem Einsatz sich die Applikation gerade befindet und die Module der Applikation, beispielsweise ihrer Schichten oder andere Arten von Bestandteilen entsprechend so lädt und anordnet, dass der Applikation ihre aktuelle Einsatzumgebung „verborgen" bleibt bzw. bei der Programmierung und/oder beim Programmstart nicht berücksichtigt werden muss.
In 1 ist das logische Architektur-Modell dargestellt, das als unterste Schicht eine Service (z.B. lokal) – und/oder Datenzugriffsschicht (z.B. remote) umfasst, so dass für die erfindungsgemäß generierten Applikationen eine automatische Anbindung an zentrale und/oder an dezentrale oder entfernte Service-Infrastrukturen bereitgestellt werden kann. Diese unterste Schicht umfasst also eine Vielzahl von üblicherweise unterschiedlichen Service-Komponenten SC als Module. Diese Schicht umfasst also den Zugriff auf lokale Service-Komponenten SC und auf entfernte Service-Komponenten SC (so genannte Remote-Service-Components, wie SOA-Web-Services). Insgesamt umfasst die Serviceschicht 18, 19 Infrastruktur-Services (wie z.B. Kommunikationsservices, Logging-Services, etc.), Daten- und Transfer-Services (wie Transfer- und Print-Dienste) und Processing-Services (wie Volumendienste, Graphikdienste etc.)
Daran schließt sich als zweit-unterste Schicht die Geschäftslogik-Schicht an, die zum Bereitstellen von unterschiedlichen so genannten Toolkits in Form von einer Menge von Business-Komponenten BC bestimmt ist. In dieser Schicht fließt eine Komponenten-Architektur ein. Sie besteht aus unterschiedlichen Business-Komponenten BC. Dabei gibt es applikations-spezifische und allgemein verwendbare Business-Komponenten BC, wobei die ersten nur in Bezug auf eine jeweilige Applikation zusammen zu schalten sind, während die letzteren für mehrere Applikationen verwendet werden können. Zu diesen Modulen können bspw. ein Segmentationsmodul, ein Positionierungsmodul, ein Zirkulationsmodul, ein Ergebnistabellenmodul (z.B. für eine Herzuntersuchung) und ein Volumenmodul, ein Anzeigemodul, ein Berichtsmodul, ein Editiermodul, ein Dokumentenmodul, ein Untersuchungsmodul etc. als applikations-übergreifende Module zu nennen.
Als dritte Schicht ist eine Controllerschicht zu nennen, die zum Bereitstellen von Business-Forms BF und/oder Business-Pages bestimmt ist. Sie wird auch als Service-Bus bezeichnet und kann als Backend im Rahmen der Applikationsentwicklung aufgefasst werden. Hier kann z.B. ein Identifikationsschritt von einem Segmentierungsschritt und einem Quantifizierungsschritt gefolgt werden. Auch auf dieser Ebene kann zwischen applikations-spezifischen und allgemein-verwendbaren Modulen differenziert werden.
Als zweit-oberste Schicht ist eine so genannte Geschäftsprozessschicht zu nennen, die unterschiedliche Geschäfts-Prozess-Logik-Module LM umfasst. Hier fließt eine Geschäfts-Architektur ein. In dieser Schicht ist folgendes angesiedelt: Ein Taskflow, Activities und eine zentrale Strategiekomponente, sowie Tasks und/oder Jobs, die erfindungsgemäß verschaltet werden können.
Als oberste Schicht schließt sich eine Präsentationsschicht für klinische Tasks an, die zur Darstellung der Daten bestimmt ist und auch als Frontend im Rahmen der Applikationsentwicklung bezeichnet werden kann. In einer Ausführungsform kann sie auch einen so genannten Client-Layer betreffen. Hier sind mehrere Präsentations-Komponenten PC, z.B. auch als Tasks eines Taskflows, angeordnet.
Ein beispielhafter Aufbau für das n-schichtige System bzw. Architektur-Modell mit unterschiedlichen Subsystemen sei nachfolgend kurz aufgeführt:

– Schicht 5: eine Präsentations-Logik und Services für Adaptive-Client-Benutzerschnittstellen als oberste Schicht,
– eine konkrete Menge bzw. Auswahl von Präsentationsformen und Präsentations-Komponenten,
– Schicht 4: eine Geschäfts-Prozess-Logik und eine Taskflow-Instrumentalisierung,
– ein konkreter Satz bzw. eine konkrete Menge von so genannten Taskflows,
– Schicht 3: ein konkreter Satz von Tasks und Jobs einer zentralen Strategie-Komponente und ein Service-Bus
– Schicht 2: eine Geschäfts-Logik
– ein konkreter Satz von Geschäfts-Tasks, die als Tools und Applikations-Backends zur Verfügung stehen und
– ein konkreter Satz von Geschäfts-Komponenten, um Domain-Toolkits zu implementieren,
– Schicht 1: Service- und Datenzugriffslogik,
– ein konkreter Satz von lokalen Service-Komponenten, um ein Domain-Framework zu implementieren und
– ein konkreter Satz von entfernten Service-Komponenten (z. B. SOA-Web-Services) um mit PACS und/oder RIS-Systemen und/oder anderen Informationssystemen zu interagieren (z. B. mit SOARIAN).

2 zeigt einen generischen Applikationscontainer mit einer darin eingelassenen Aktivität. Der generische Container stellt eine Laufzeitumgebung für Applikationen oder Aktivitäten bereit. Der Container 1 enthält dabei eine Aktivität 2, die dem Model-View-Controller-Designmuster folgt und daher eine View-Schicht 3, eine Controller-Schicht 4, sowie eine Model-Schicht 5 aufweist. Die View-Schicht 3 wird durch eine generische Front-End-Komponente repräsentiert, die für die Benutzeroberfläche verantwortlich ist, und die Model-Schicht 5 wird durch ein generisches Back-End repräsentiert, das für die Geschäftslogik verantwortlich ist, wobei beide miteinan der durch die Steuerungsschicht 4 verbunden sind, die für die Benutzeroberflächen-Aktionshandhabung verantwortlich ist. Die Controller-Schicht ist auch für das Aktivieren generischer Kommandokanäle zwischen Front-End- und Back-End-Komponenten verantwortlich. Die Back-End-Schicht oder der Back-End-Teil 5 einer Aktivität hat weiterhin Eingabe- und Ausgabe-Ports 6, die für den Datenfluss zwischen automatisch verbundenen Aktivitäten benötigt werden, die innerhalb eines Taskflows ausgeführt werden. Die 2 zeigt weiterhin eine so genannte Präsentations-Form 7, die Funktionalitäten zur Anzeige durch das View 3 bereitstellt, sowie Business-Forms 8 (bzw. Geschäftsforms 8), die dem Model 5 Funktionalitäten bereitstellen. Jede der Schichten 3, 4 und 5 besteht wiederum aus einzelnen Task-Stegs bzw. Schritten 9, 10, 11, die hintereinander geschaltet die eigentliche Funktionalität der jeweiligen Schicht implementieren und die wiederum aus einer Reihe von (nicht dargestellten) Komponenten zusammengesetzt sein können. Durch diesen flexiblen, modularen Aufbau kann nach einer Art von „Baukastensystem" jede Applikation aus den jeweils für den Einsatzzweck bzw. die Einsatzumgebung am besten passenden Modulen, seien dies Aktivitäten, deren Schichten, Tasksteps oder Komponenten, ad hoc zusammengebaut und betriebsbereit verschaltet werden.
3 zeigt verschiedene bevorzugte Formen von Deployment-Strategien, die mit der vorliegenden Erfindung realisiert werden können. Wie die 3 demonstriert, ist es möglich, Komponenten zu „deployen", die dafür ausgelegt sind, kompatibel mit SYNGO.NET zu sein, und die sehr flexibel sind und von einer einzigen, ausführbaren Datei bis zu mehreren ausführbaren Dateien reichen und selbst über Maschinen oder Netzwerkgrenzen hinwegreichen. Hierbei sind dargestellt: Eine kombinierte Präsentations- und Geschäftsprozessschicht 15, eine Controllerschicht 16, eine Geschäftslogikschicht 17, sowie lokale Serviceschicht-Ebene 18 und entfernte Serviceschicht-Ebene 19. 3 zeigt auf der linken Seite einen Fat-Client und einen Rich-Client mit 1 entsprechenden Bestandteilen bzw. Schichten, wobei der Rich-Client optional noch entfernte Dienste zur Verfügung hat, auf die er zugreifen kann, und die damit nicht auf dem lokalen Rechner vorhanden sein müssen. Diese beiden Deployment-Strategien können gleichzeitig verwendet werden, um es einem Rechner zu ermöglichen, wahlweise lokal oder in einem Netzwerk verwendet zu werden, was beispielsweise bei Laptops nützlich ist, die teilweise mit einem Netzwerk verbunden sind und damit Zugriff auf alle Daten und Dienste haben, teilweise aber auch im Stand-Alone-Betrieb arbeiten müssen, so dass nicht nur die notwendigen Dienste lokal implementiert sein müssen, sondern auch zumindest die Daten der aktuellen Taskflows-Abarbeitung lokal vorhanden sein müssen, beispielsweise Bilddaten zu einem bestimmten Patienten. Bei einem Fat Client ist eine „Zero Administration" nicht von Belang und oft auch gar nicht gewünscht. Bei Rich Clients kann vor dem Zugang zu einem Netzwerk noch eine Firewall vorgeschaltet sein.
Eine weitere Deployment-Strategie ist ein Adaptive-Client, bei dem, ähnlich wie beim Rich Client, die zustandsfreie bzw. remote Serviceschicht 19 auf einem entfernten Rechner implementiert ist, während die anderen Schichten der n-schichtigen Applikationsarchitektur auf dem Zielrechner ausgeführt werden. Im Unterschied zum Rich Client kann ein Adaptive-Client jedoch nicht in den Modus Fat Client umschalten, da diese Deployment-Strategie für ihn nicht vorgesehen ist.
Beim Rich Thin Client, einer weiteren Deployment-Strategie gemäß der Erfindung, ist als Besonderheit die Controller-Schicht 16 zweigeteilt bzw. als eine Netzwerkfunktionalität ausgelegt, bei der ein Teil auf dem Zielrechner läuft und ein zweiter, mit dem ersten Teil interagierender und kommunizierender Teil auf einem Server oder ähnlichem in einem Netzwerk läuft. Auf diese Weise sinken die Anforderungen an die Hardware des Zielrechners, da viele rechenaufwendige Vorgänge nunmehr auf einem leistungsstarken Rechner, den sich mehrere Anwender teilen können, abgearbeitet werden können und lediglich die Präsentation der Daten auf dem Zielrechner berechnet wird.
Ein Thin Client, wie beispielsweise ein HTML-basierter Thin Client, enthält überhaupt keine Steuerschicht 16 mehr auf dem Zielrechner. Vielmehr wird die meiste Funktionalität, bis auf die reine Benutzerschnittstelle und die Datenpräsentation, auf einem Applikationsserver implementiert; lediglich eine HTML-basierte Oberfläche läuft auf dem Zielrechner. Auch die zustandsfreie Serviceschicht 19 befindet sich auf einem oder mehreren weiteren Netzwerkrechnern, auf die vom Applikationsserver aus zugegriffen wird.
Ein Webservice schließlich ist als die einfachste mögliche Implementierung einer n-schichtigen Applikation in Bezug auf den Zielrechner anzusehen, da auf diesem nur noch ein üblicher Webbrowser mit einer Benutzeroberfläche läuft, die einen Zugriff auf die auf einem oder mehreren entfernten Rechnern laufenden Applikationen gestatten. Damit steht jeder Rechner, auf dem ein Web-Browser läuft, als Zielrechner zur Verfügung.
Wie 3 demonstriert, ist es möglich, erfindungsgemäß implementierte Komponenten sehr flexibel zu deployen, von einem einzigen „Executable" bis zu multiplen „Executables" und sogar über Rechner- oder Netzwerkgrenzen hinweg. Für bildgebende Systeme, beispielsweise im Bereich der Medizintechnik, kann es aus Leistungsgründen bezüglich der Benutzerinteraktivität, dem Nutzen von Zielrechnerressourcen, Notwendigkeit bzw. Entbehrlichkeit von Netzwerkverbindungen, Skalierbarkeit, Multi-User etc. vorteilhaft sein, sich auf Adaptive Clients zu fokussieren, eher als auf Thin Clients oder Web Clients, bei denen der Status (Zustand) oft schwieriger zu verwalten ist als bei Adaptive Clients.
Es versteht sich, dass erfindungsgemäß weitere Deployment-Strategien sowie Varianten der beispielhaft vorgestellten Deployment-Strategien möglich sind und vom Schutzumfang der Erfindung umfasst sein sollen.
Auch ist es möglich, die verschiedenen Teilaspekte der Erfindung miteinander zu kombinieren, so beispielsweise die gleichzeitige Festlegung einer bestimmten Deployment-Strategie für einen Zielrechner und die Auswahl von Bestandteilen der Präsentationsschicht, um einen oder mehrere Monitore zur Anzeige von Benutzerelementen zu verwenden.

Claims

Verfahren zum Erstellen einer modularen Applikation, mit folgenden Verfahrensschritten: – Bereitstellen einer Menge von Modulen, in denen jeweils zumindest eine Funktionalität zum Erstellen der Applikation implementiert ist, – Auswahl von für die jeweilige Applikation benötigten Funktionalitäten, und – Konfigurieren der ausgewählten Funktionalitäten zu einer Applikation, wobei die Module bereits als compilierter ausführbarer Programmcode vorliegen und zumindest bestimmte Module für unterschiedliche Einsatzumgebungen ausgelegt sind, und wobei Module automatisch ausgewählt werden und die Applikation so konfiguriert wird, dass zur Laufzeit zu unterschiedlichen erkannten Einsatzumgebungen passende Module dynamisch zusammenschaltbar sind, ohne dass die Applikation neu compiliert werden muss.
Verfahren nach Anspruch 1, dadurch gekennzeichnet, dass die Applikation in einer n-schichtigen Systemarchitektur aufgebaut wird, wobei Module unterschiedlichen Schichten angehören und zu unterschiedlichen erkannten Einsatzumgebungen passende Module nur denjenigen Schichten zugeordnet sind, die für eine Wechselwirkung mit den jeweils erkannten Einsatzumgebungen relevant sind.
Verfahren nach Anspruch 1 oder 2, dadurch gekennzeichnet, dass die Einsatzumgebung ein Online-Modus oder ein Offline-Modus ist und/oder unterschiedliche Deployments umfasst.
Verfahren nach zumindest einem der Ansprüche 1 bis 3, dadurch gekennzeichnet, dass die Applikation jeweils Module in einem Frontend und in einem Backend umfassen kann, wobei zumindest jeweils ein Modul aus dem Frontend mit zumindest einem Modul aus einem Backend über Datenpfade verschaltet werden kann.
Verfahren nach zumindest einem der vorhergehenden Ansprüche 2 bis 4, dadurch gekennzeichnet, dass die Systemarchitektur 5-schichtig ist und folgende Schichten umfasst, beginnend bei einer hierarchisch obersten Schicht: – eine Präsentationsschicht (15), die zur Darstellung der Daten bestimmt ist, – eine Geschäftsprozess-Schicht (15), die unterschiedliche Geschäfts-Prozess-Logik-Module (LM) umfasst, – eine Controllerschicht (16), die zur Bereitstellung von Business-Forms (BF) bestimmt ist, – eine Geschäftslogik-Schicht 17), die zum Bereitstellen von unterschiedlichen Business-Komponenten (BC) dient und – eine Serviceschicht (18, 19), die zum Bereitstellen von Daten-, Transfer- und/oder Infrastruktur-Services in Form von lokalen und remoten Service-Komponenten (SC) bestimmt ist.
Verfahren nach Anspruch 5, dadurch gekennzeichnet, dass die Business-Komponenten (BC) uns/oder die Service-Komponenten (SC) versionierbar sind.
Verfahren nach zumindest einem der vorhergehenden Ansprüche, dadurch gekennzeichnet, dass mehrere Applikationen zu einem Taskflow verschaltet werden können.
Verfahren zum Ausführen zumindest einer modularen Applikation, in Abhängigkeit von einer Einsatzumgebung eines Zielrechners, mit folgenden Schritten: – Feststellen einer auf dem Zielrechner vorhandenen Einsatzumgebung; und – Laden von Modulen der Applikation in den Zielrechner und deren dynamische Zusammenschaltung in Abhängigkeit von der erkannten Einsatzumgebung anhand einer vorab festgelegten Konfiguration der Applikation, und deren Ausführen.
Verfahren gemäß Anspruch 8, dadurch gekennzeichnet, dass mehrere Applikationen einen Taskflow bilden.
Verfahren gemäß Anspruch 8 oder 9, gekennzeichnet durch die weiteren Schritte: – periodisches Feststellen der Einsatzumgebung, um Änderungen oder geplante Änderungen der Einsatzumgebung zu erkennen, und – nach Erkennen einer Änderung oder geplanten Änderung bedarfsweises Nachladen und/oder Ersetzen von Modulen der Applikationen, die zu der geänderten Einsatzumgebung passen.
Verfahren gemäß einem der Ansprüche 8 bis 10, dadurch gekennzeichnet, dass die Einsatzumgebung eine Deploymentstrategie für den Zielrechner, die Rechenleistung des Zielrechners, den zur Verfügung stehenden Speicherplatz, die vorhandenen Graphikausgabeoptionen, die Netzwerkeinbindung, den Standort des Zielrechners und/oder die Verwendung des Zielrechners umfasst.
Verfahren nach zumindest einem der Ansprüche 8 bis 11, dadurch gekennzeichnet, dass das Verfahren unter automatischer Anbindung an zentrale oder entfernte (remote) Service-Infrastrukturen zur Unterstützung eines Online- und Offline-Betriebes erfolgt, wobei Daten und/oder Dienste lokal und/oder über ein Netzwerk bereitgestellt werden können.
Verfahren gemäß einem der Ansprüche 8 bis 12, dadurch gekennzeichnet, dass die Applikationen n-schichtige-Applikationen sind und, dass eine für den Zielrechner bevorzugte Deployment-Strategie festgestellt wird und entsprechend passende Schichten bzw. Schichten zugeordne te Module der Applikation zur Ausführung in den Hauptspeicher geladen werden und gegebenenfalls Verbindungen über ein Netzwerk zu benötigten Diensten hergestellt werden, die den geladenen Schichten die Funktionalität der nicht geladenen Schichten bereitstellen.
Verfahren nach Anspruch 13, dadurch gekennzeichnet, dass die Systemarchitektur 5-schichtig ist und folgende Schichten umfasst, beginnend bei einer hierarchisch obersten Schicht: – eine Präsentationsschicht (15), die zur Darstellung der Daten bestimmt ist, – eine Geschäftsprozess-Schicht (15), die unterschiedliche Geschäfts-Prozess-Logik-Module (LM) umfasst, – eine Controllerschicht (16), die zur Bereitstellung von Business-Forms (BF) bestimmt ist, – eine Geschäftslogik-Schicht (17), die zum Bereitstellen von unterschiedlichen Business-Komponenten (BC) dient und – eine Serviceschicht (18, 19), die zum Bereitstellen von Daten-, Transfer- und/oder Infrastruktur-Services in Form von lokalen und remoten Service-Komponenten (SC) bestimmt ist.
Verfahren gemäß Anspruch 13 oder 14, dadurch gekennzeichnet, dass die Deployment-Strategie einen Fat-Client, einen Rich-Client, einen Rich-Thin-Client, einen Thin-Client, oder einen Web-Service umfasst, wobei – bei dem Fat-Client alle Schichten auf dem Client ausgeführt werden, – bei dem Rich-Client nur eine remote, zustandsfreie Zugriffsschicht auf einem entfernten Rechner ausgeführt wird, – bei dem Rich-Thin-Client die Präsentationsschicht und optional die Geschäftsprozeß-Schicht (15) auf dem Client ausgeführt werden, während die Controller-Schicht (16), die Ge schäftslogik-Schicht (17) und die Serviceschichten (18, 19) auf einem entfernten Rechner ausgeführt werden, – bei dem Thin-Client die Präsentationsschicht (15) auf dem Client ausgeführt wird, die Geschäftsprozeß-Schicht (15), die Geschäftslogik-Schicht (17) und eine lokale, zustandsbehaftete Service-Schicht (18) auf einem Applikationsserver ausgeführt werden, und die remote, zustandsfreie Service-Schicht (19) auf einem entfernten Dienstrechner ausgeführt wird, und – bei dem Web-Service ein HTML-basiertes Programm auf dem Client ausgeführt wird und alle zum Ausführen der Applikationen notwendige Dienste auf einem entfernten Rechner ausgeführt werden.
Verfahren gemäß einem der Ansprüche 13 bis 15, dadurch gekennzeichnet, dass zumindest ein Teil der die Schichten bildenden Softwareobjekte unabhängig von der Deployment-Strategie programmiert sind.
Verfahren gemäß einem der Ansprüche 14 bis 16, dadurch gekennzeichnet, dass die Präsentations- und Geschäftsprozess-Schicht (15), die Controller-Schicht (16) und die Geschäftslogik-Schicht (17) unabhängig von der Deployment-Strategie programmiert sind.
Verfahren gemäß einem der Ansprüche 15 bis 17, dadurch gekennzeichnet, dass die zustandsbehaftete Service-Schicht (18) dafür ausgelegt ist, Interaktionen mit den darüber liegenden Schichten (17, 16, 15) so durchzuführen, dass die Deployment-Strategie für die darüber liegenden Schichten irrelevant ist.
Verfahren gemäß einem der Ansprüche 8 bis 18, dadurch gekennzeichnet, dass die Einsatzumgebung die Leistungsfähigkeit des Clients umfasst und Module der zumindest einen Applikation nachladbar sind, die zu mindest hinsichtlich der verwendeten Algorithmen, der Komplexität der Anzeige von Benutzeroberflächenelementen und/oder der verfügbar gemachten Datenmenge zur Leistungsfähigkeit des Clients passen.
Verfahren gemäß einem der Ansprüche 8 bis 19, dadurch gekennzeichnet, dass die Einsatzumgebung die Anzahl verfügbarer Bildschirme am Client umfasst und dass Module der zumindest einen Applikation nachladbar sind, die speziell zur Anzeige von Benutzeroberflächenelementen auf der vorhandenen Anzahl von Bildschirmen bestimmt sind.
Verfahren gemäß einem der Ansprüche 8 bis 20, dadurch gekennzeichnet, dass ein Taskflow aus hintereinander geschalteten Applikationen generiert wird, die in verschiedenen Applikations-Varianten zur Verfügung stehen, und dass aus der Einsatzumgebung bestimmt wird, welche Applikationsvarianten im Taskflow hintereinander geschaltet werden.
Verfahren gemäß einem der Ansprüche 8 bis 21, dadurch gekennzeichnet, dass ein Taskflow von Applikationen aus mehreren hintereinander geschalteten n-schichtigen instanziierten Applikationscontainern (1) besteht.
Verfahren gemäß Anspruch 22, dadurch gekennzeichnet, dass das Feststellen der Einsatzumgebung durch einen ersten instanziierten Applikationscontainer (1) im Taskflow erfolgt.
Verfahren nach einem der Ansprüche 22 oder 23, dadurch gekennzeichnet, dass das Verfahren auf eine Taskflow-Manager-Instanz zugreift, die als separate ausführbare Datei vorgesehen ist und zum Bearbeiten von Taskflow-Instanzen bestimmt ist, die innerhalb eines instanziierten Applikationscontainers (1) ablaufen.
Verfahren nach einem der Ansprüche 14 bis 24, dadurch gekennzeichnet, dass eine Geschäftsprozess-Schicht (15) auf eine zentrale Strategiekomponente zugreift, insbesondere um einzelne Komponenten und/oder Instanzen zu verwalten.
Verfahren gemäß einem der Ansprüche 8 bis 25, dadurch gekennzeichnet, dass die Einsatzumgebung durch eine auf dem Client befindliche Datenstruktur definiert ist.
Software-Architektur-System, zumindest umfassend: – zumindest eine, aus einer Mehrzahl von Modulen zusammengesetzte Applikation; – ein Konfigurierobjekt, das zum Laden von Modulen der zumindest einen Applikation in Abhängigkeit von einer festgestellten Einsatzumgebung bestimmt ist.
Software-Architektur-System gemäß Anspruch 27, dadurch gekennzeichnet, dass es zur Ausführung des Verfahrens gemäß einem der Ansprüche 8 bis 26 eingerichtet ist.