-
Die Erfindung bezieht sich auf ein Verfahren zum Betrieb einer Datenverarbeitungseinrichtung, insbesondere eines Computers oder eines Computernetzwerks, auf der eine Applikationsplattform implementiert ist sowie mehrere eine (Software-)Applikationen, die auf der Applikationsplattform durch Zugriff auf mindestens eine Programmierschnittstelle der Applikationsplattform lauffähig sind.
-
Der Begriff „Applikationsplattform” bezeichnet eine (generische oder domain-spezifische) Software-Plattform, d. h. eine applikationsübergreifende Software, die der Computerhardware mit dem darauf aufsetzenden Betriebssystem einerseits und den Applikationen, d. h. den eigentlichen Anwendungsprogrammen andererseits zwischengeschaltet ist. Ein weit verbreitetes Beispiel für eine solche Applikationsplattform ist J2EE (Java Platform, Enterprise Edition).
-
Eine solche Applikationsplattform stellt typischerweise grundlegende Funktionen zur Verfügung, die von einer Vielzahl von Applikationen benötigt werden, z. B. das Lesen, Schreiben, Löschen und Archivieren von Daten. Eine Applikationsplattform stellt häufig auch eine Nutzerschnittstelle (User Interface) zur Verfügung, d. h. Funktionen, wie grafische Bedienelemente, etc., über die Applikationen mit einem Nutzer zur Ein- und Ausgabe von Daten interagieren können. Eine Applikationsplattform, die für medizinische Software-Applikationen spezialisiert ist, stellt häufig darüber hinaus auch medizinisch relevante Grundfunktionen, z. B. Algorithmen zur Sichtung, Auswertung und Bearbeitung von medizinischen Bildern zur Verfügung. Das durch eine – insbesondere spezialisierte – Applikationsplattform zur Verfügung stehende Funktions-Portfolio ermöglicht eine wesentliche Beschleunigung der Entwicklungszeit für Software-Applikationen, insbesondere im medizinischen Umfeld.
-
Für einen einfachen Zugriff auf die Funktionen einer Applikationsplattform stellt diese in der Regel eine so genannte Programmierschnittstelle (kurz: API, Application Programming Interface) oder mehrere solcher Programmierschnittstellen (APIs) zur Verfügung, deren Funktionen in die zu schaffenden Applikationen eingebunden werden können. Zudem stellt eine Applikationsplattform mitunter einen sogenannten (Applikations-)Container zur Verfügung, in dem eine Applikation, oder bei mehrschichtigen Applikationen eine Schicht einer Applikation, gekapselt abläuft. Der Container steuert hierbei den Ablauf der Applikation, insbesondere den Programmstart und die Beendung der Applikation. Üblicherweise ist zumindest ein Teil der API(s) als Bestandteil des Containers implementiert. Oft umfassen die APIs darüber hinaus aber auch Funktionen, die unabhängig von dem Container implementiert sind, und auf die die Applikationen entsprechend auch unabhängig von dem Container zugreifen können.
-
Der Begriff „Funktion” bezeichnet hier und im Folgenden allgemein einen funktionalen Bestandteil eines Softwareprogramms. Eine solche Funktion kann auch als „Methode” im Sinne einer objektorientierten Programmierung oder in anderer Form realisiert sein.
-
Durch die Zurverfügungstellung eines Containers unterstützt eine entsprechend ausgebildete Applikationsplattform insbesondere effektiv die Entwicklung von mehrschichtigen, verteilten Applikationen, also Applikationen, die mehrere unabhängig voneinander laufende Teile (Schichten) umfassen, die über die Applikationsplattform miteinander interagieren. Medizintechnische Applikationen umfassen hierbei insbesondere häufig eine so genannte Frontend-Schicht, die vorrangig die Interaktion mit dem Nutzer zur Aufgabe hat, und eine so genannte Backend-Schicht, in der ein Großteil der eigentlichen Berechnungen durchgeführt wird, und die keine direkte Nutzerinteraktion beinhaltet. In einem Computernetzwerk, wie es in medizinischen Einrichtungen heutzutage üblicherweise verwendet wird, ist hierbei die Backend-Schicht meist in einen zentralen Server implementiert, während die Frontend-Schicht auf einem Client, d. h. einer Arbeitsstation implementiert ist. Die Applikationsplattform ist in diesem Fall sowohl serverseitig als auch clientseitig implementiert und unterstützt auch die Kommunikation zwischen diesen Hardwaregeräten. Die Frontend-Schicht und die Backend-Schicht werden hierbei durch die Applikationsplattform zumeist jeweils in einem separaten Container gekapselt.
-
Bei einem typischen Datenverarbeitungssystem einer modernen medizinischen Einrichtung sind häufig eine Vielzahl von verschiedenen medizintechnischen Applikationen auf einer gemeinsamen, netzwerkübergreifenden Applikationsplattform implementiert. Insbesondere sind medizintechnische Datenverarbeitungssysteme häufig „granular” strukturiert, indem verschiedene Teilfunktionen des Datenverarbeitungssystems als unabhängig lauffähige Applikationen implementiert sind. Diese granulare Struktur vereinfacht nämlich einerseits die Weiterentwicklung und Wartung eines komplexen Datenverabeitungssystems. Andererseits fördert ein granularer Aufbau auch die Stabilität eines solchen Systems, d. h. die Fehlerunempfindlichkeit im Betrieb des Systems. Durch die Aufteilung des Systems in viele unabhängige Applikationen wird nämlich weiterstgehend sichergestellt, dass ein Fehler in einer Teilfunktion nicht das gesamte Datenverarbeitungssystem zum „Absturz” bringt.
-
Eine Applikationsplattform ist typischerweise dazu eingerichtet, mehrere dieser Applikationen parallel, d. h. gleichzeitig, laufen zu lassen. Jede dieser parallellaufenden Applikationen bzw. – bei mehrschichtigen Applikationen – jede Schicht der parallellaufenden Applikationen bildet dabei einen eigenen, separaten Betriebssystemprozess. Frontendseitig, d. h. gegenüber einem Nutzer, wird jede dieser parallellaufenden Applikationen durch übliche Betriebssysteme separat und unabhängig dargestellt. Bei modernen Betriebssystemen mit graphischer Nutzeroberfläche wird z. B. jeder parallellaufenden Applikation ein eigener Rahmen (Fenster) zugeordnet, wobei diese Rahmen unabhängig voneinander verschoben, ein- und ausgeblendet oder geschlossen werden können.
-
Aufgrund der Granularität von medizintechnischen Datenverarbeitungssystemen ist es bei medizinischen Arbeitsgängen, insbesondere bei der bildverarbeitungstechnischen Aufbereitung und Auswertung von medizinischen Bilddaten, für einen Nutzer oft erforderlich, eine Vielzahl von Applikationen gleichzeitig oder nacheinander zu bedienen. Im Zuge eines solchen medizinischen Arbeitsgangs werden daher häufig eine Vielzahl von Applikationen parallel gestartet. Die darstellungstechnische Unabhängigkeit der einzelnen Applikationen führt hierbei mitunter zu einer gewissen Unordnung, die die Effektivität des Arbeitsganges beeinträchtigen kann. Insbesondere ist es bei vielen laufenden Applikationen für den Nutzer mitunter mühsam, die jeweils benötigte Applikation zu finden, da er sich hierzu durch die geöffneten Fenster „klicken” muss. Zudem steigt bei großer Anzahl laufender Applikationen das Risiko, dass eine noch benötigte Applikation versehentlich vorzeitig geschlossen wird.
-
Der Erfindung liegt die Aufgabe zugrunde, die Handbarkeit von (Software-)Applikationen, die parallel auf einer Applikationsplattform lauffähig sind, zu verbessern.
-
Diese Aufgabe wird erfindungsgemäß gelöst durch ein Verfahren mit den Merkmalen des Anspruchs 1. Die Aufgabe wird weiterhin gelöst durch eine Applikationsplattform mit den Merkmalen des Anspruchs 4. Vorteilhafte Ausführungsformen und Weiterbildungen der Erfindung ergeben sich durch die abhängigen Ansprüche und die nachfolgenden Ausführungen.
-
Die Applikationsplattform umfasst danach mindestens eine Programmierschnittstelle (API), in der Regel aber mehrere funktional abgegrenzte Programmierschnittstellen (APIs), unter Zugriff auf welche mehrere Applikation auf der Applikationsplattform parallel lauffähig ist.
-
Bei der Applikationsplattform handelt es sich allgemein um ein Softwareprodukt, dessen Bestandteile zur Ausführung des vorstehend Verfahrens oder einer seiner nachfolgend beschriebenen Varianten programmtechnisch eingerichtet sind, so dass das Verfahren automatisch durchgeführt wird, wenn die Applikationsplattform auf einer Datenverarbeitungseinrichtung implementiert und ausgeführt wird.
-
Bei einschichtigen Applikationen wird durch den Start einer Applikation jeweils ein separater Betriebssystemprozess gebildet. Bevorzugt ist die Applikationsplattform aber dazu eingerichtet, mehrschichtige Applikationen mit jeweils einer Frontend-Schicht und einer Backend-Schicht im Sinne der vorstehenden Definition zu unterstützen. In diesem Fall werden durch den Start einer Applikation jeweils separate Betriebssystemprozesse für die Frontend-Schicht und die Backend-Schicht jeder Applikation gebildet.
-
Um einem Nutzer der Datenverarbeitungseinrichtung die Handhabung der gleichzeitig ablaufenden Applikation bzw. Prozesse zu erleichtern, umfasst die Applikationsplattform erfindungsgemäß ein Prozessverbindungmodul. Durch dieses Prozessverbindungsmodul wird eine prozessübergreifende Nutzerschnittstelle (User Interface) erzeugt, durch die die parallellaufenden Prozesse gemeinsam mit dem Benutzer der Datenverarbeitungseinrichtung interagieren. Bei mehrschichtigen Applikationen mit einer Frontend-Schicht und einer Backend-Schicht betrifft dies allerdings lediglich die der Frontend-Schicht zugeordneten Prozesse, zumal die der Backend-Schicht zugeordneten Prozesse definitionsgemäß keine unmittelbare Nutzerinteraktion haben.
-
Durch die gemeinsame, prozessübergreifende Nutzerschnittstelle treten die mehreren Prozesse (bzw. die jeweils zugrunde liegenden Applikationen) nach außen hin wie ein einziger Prozess auf. Der Nutzer kann über die gemeinsame Nutzerschnittstelle zwischen verschiedenen Prozessen bzw. Applikationen wechseln, ohne dass er sich dessen bewusst wird. Durch die prozessübergreifende Nutzerschnittstelle wird hierbei in zweckmäßiger Ausführung der Erfindung ein gemeinsamer Rahmen für die parallel laufenden Prozesse zur Verfügung gestellt. Der gemeinsame Rahmen wird insbesondere, jedoch nicht zwingend, in Form eines gewöhnlichen Fensters dargestellt, wie es von der graphischen Benutzeroberfläche eines Betriebssystems üblicherweise zur Verfügung gestellt wird. In jedem Fall handelt es sich bei der prozessübergreifenden Nutzerschnittstelle der Applikationsplattform aber um eine Softwarestruktur, die an sich von dem Betriebssystem und der diesem gegebenenfalls zugeordneten graphischen Benutzeroberfläche unabhängig ist.
-
In bevorzugter Ausführung umfasst die Applikationsplattform Container zur Kapselung einer Applikation bzw. – bei mehrschichtigen Applikationen – jeweils einer Applikationsschicht. Bei mehrschichtigen Applikationen wird durch die Applikationsplattform zumindest der Frontend-Schicht, bevorzugt aber auch der Backend-Schicht jeder laufenden Applikation jeweils eine Instanz eines solchen Containers (nachfolgend Containerinstanz) zur Verfügung gestellt, in der jeweilige Schicht gekapselt abläuft. Jede laufende Applikation bzw. Applikationsschicht bildet zusammen mit der zugehörigen Containerinstanz jeweils einen Betriebssystemprozess. Das Prozessverbindungsmodul startet hierbei in bevorzugter Ausbildung für eine erste laufende Applikation eine Instanz eines übergeordneten Containers, die die den weiteren laufenden Applikationen jeweils zugeordneten Containerinstanzen steuert. Die Nutzerschnittstelle ist hierbei insbesondere Bestandteil dieser übergeordneten Containerinstanz, die insbesondere den weiteren Containerinstanzen eine Ausgabeposition innerhalb des Rahmens zuweist. Das Umschalten zwischen den laufenden Applikationen bzw. den zugehörigen Betriebssystemprozesses erfolgt über Logik, die bevorzugt als Teil des übergeordneten Containers implementiert ist.
-
In einer vorteilhaften Weiterbildung der Erfindung umfasst die Applikationsplattform zusätzlich ein Update-Modul. Bei einem Versionswechsel der Applikationsplattform oder eines Plattformteils wird durch das Update-Modul geprüft, ob eine neu zu installierende jüngere Version der Applikationsplattform der bestehenden älteren Version der Applikationsplattform hinsichtlich der Schnittstellenspezifikation oder des Schnittstellenverhaltens der oder jeder API entspricht.
-
Als „(Schnittstellen-)Spezifikation” wird hierbei die Gesamtheit derjenigen Angaben verstanden, die eine auf die API zugreifende Applikation einhalten muss, um mit der API kompatibel zu sein. Diese Angaben umfassen beispielsweise die Bezeichnung der Funktionen der API und die Definition von Argumenten (d. h. Variablen) dieser Funktionen.
-
Als „(Schnittstellen-)Verhalten” wird hierbei die Gesamtheit derjenigen Eigenschaften einer API bezeichnet, die erst zur Laufzeit der Plattform zutage treten. Das Verhalten einer API wird dabei insbesondere bestimmt durch die mit dem Aufruf einer jeden API-Funktionalität verbundene Antwortzeit bzw. Rechenzeit, die Genauigkeit von Rückgabewerten solcher Funktionalitäten, etc.
-
Solange sich die oder jede API der jüngeren und älteren Version der Applikationsplattform hinsichtlich der Schnittstellenspezifikation und des Schnittstellenverhaltens entsprechen, ist somit sichergestellt, dass die auf der älteren Version der Applikationsplattform aufbauenden Applikationen auch kompatibel mit der jüngeren Version sind. In diesem Fall wird durch das Update-Modul die ältere Version der Applikationsplattform bzw. Plattformteils durch die jüngere Version überschrieben. Wird andernfalls durch das Update-Modul festgestellt, dass die jüngere Version der Applikationsplattform bzw. des Plattformteils hinsichtlich der Schnittstellenspezifikation oder des Schnittstellenverhaltens einer API der älteren Version nicht entspricht, also kompatibilitätsbrechende Änderungen aufweist, so wird durch das Update-Modul die jüngere Version der Applikationsplattform bzw. des Plattformteils oder zumindest dieser kompatibilitätsbrechend geänderten API parallel (side-by-side) zu der bestehenden, älteren Version der Applikationsplattform bzw. des Plattformteils oder dieser API installiert.
-
Durch die Möglichkeit, mehrere Versionen der Applikationsplattform oder deren API(s) parallel zu installieren, wird ermöglicht, dass jede der auf der Datenverarbeitungseinrichtung implementierten Applikationen nach Maßgabe ihrer jeweiligen Schnittstellen-Kompatibilität auf eine entsprechende, kompatible Version der API(s) zugreifen kann. Sind mehrere Applikationen auf der Datenverarbeitungseinrichtung implementiert, so können hierbei insbesondere einige dieser Applikationen auf die der älteren Plattformversion zugeordnete API(s) zugreifen, während andere Applikationen auf die der jüngeren Plattformversion zugeordnete API(s) zugreifen. Bei einem Update der Applikationsplattform, bei dem mindestens eine API in kompatibilitätsbrechender Weise geändert wird, müssen daher die auf der Applikationsplattform aufbauenden Applikationen nicht sofort migriert werden. Vielmehr können die Applikationen allmählich und nacheinander auf die jüngere Version migriert oder sogar langfristig in dem bisherigen Zustand belassen werden. Auf diese Weise ist sichergestellt, dass der Plattform-Update nicht, oder zumindest nur in vernachlässigbarem Maße zu Ausfallzeiten der Datenverarbeitungseinrichtung oder der darauf implementierten Applikationen führt. Zudem kann der mit der Migration der Applikationen verbundene Arbeitsaufwand flexibel eingeteilt, insbesondere über die Zeit „gestreckt” werden. Ferner kann auch ein und dieselbe Applikation parallel in mehreren Versionen implementiert werden. Beispielsweise kann neben einer auf eine neue Plattformversion migrierten Version einer bestimmten Applikation die auf einer älteren Plattformversion aufbauende ältere Version derselben Applikation aufrechterhalten werden.
-
Die durch das Update-Modul vorgenommene Kompatibilitätsprüfung der API(s) stellt zudem sicher, dass die verschiedenen Plattformversionen nicht „blind” nebeneinander installiert werden, sondern nur dann, wenn dies aufgrund festgestellter Inkompatibilität der API(s) nötig ist. Die Anzahl der auf der Datenverarbeitungseinrichtung langfristig implementierten Versionen der Applikationsplattform wird somit auf ein Mindestmaß beschränkt, was Speicherplatz einspart und die Komplexität der insgesamt auf der Datenverarbeitungseinrichtung implementierten Softwarestruktur reduziert.
-
Die von dem Update-Modul vorgenommene Kompatibilitätsprüfung kann grundsätzlich auf verschiedene Weise erfolgen. In einer einfachsten, und daher bevorzugt eingesetzten Verfahrensvariante enthält die neu zu installierende, jüngere Version der Applikationsplattform eine herstellerseitig beigefügte konkrete Angabe zu ihrer Kompatibilität mit einer oder mehreren Vorgängerversionen der Applikationsplattform. Diese Angabe, die unmittelbar angibt, ob sich die Schnittstellenspezifikation und/oder das Schnittstellenverhalten der beiden API-Versionen entsprechen, wird in diesem Fall von dem Update-Modul ausgelesen. In einer alternativen Verfahrensvariante enthält jede Version der Applikationsplattform Angaben zu der entsprechenden Schnittstellenspezifikation und/oder dem Schnittstellenverhalten, die das Update-Modul in diesem Fall ausliest und miteinander vergleicht. Wiederum alternativ hierzu ist denkbar, dass das Update-Modul die API(s) der jüngeren Version auf Kompatibilität testet. Ferner sind Mischformen dieser drei Alternativen im Rahmen der Erfindung denkbar. Insbesondere kann vorgesehen sein, dass die Kompatibilität hinsichtlich der Schnittstellenspezifikation anhand hinterlegter Angaben bestimmt wird, während die Kompatibilität hinsichtlich des Schnittstellenverhaltens durch Tests ermittelt wird.
-
Sofern im Zuge eines einfachen oder mehrfachen Plattform-Updates bereits mehrere Versionen der Applikationsplattform, einzelner Plattformteile und/oder API(s) parallel installiert wurden, wird beim Laden einer jeden Applikation durch ein Versionsmanagement-Modul geprüft, mit welcher der installierten Plattformversionen diese Applikation kompatibel ist. Durch das Versionsmanagement-Modul, bei dem es sich um einen in diesem Fall vorgesehenen weiteren Softwarebestandteil der Applikationsplattform handelt, wird/werden in diesem Fall die API(s) der entsprechenden kompatiblen Version ausgewählt und zur Verfügung gestellt. Die geladene Applikation wird hierbei insbesondere in einem der entsprechenden Plattformversion entstammenden Container ausgeführt, der die API(s), oder zumindest einen Teil davon enthält. Der Container enthält hierbei insbesondere die API(s), die Funktionen für den so genannten „Life Cycle” der zugeordneten Applikation, insbesondere das Starten, Stoppen, Suspendieren oder Wiedererwecken der Applikation, enthalten.
-
Bei mehrschichtigen Applikationen wird durch das Versionsmanagement-Modul hierbei sichergestellt, dass der Frontend-Schicht und der Backend-Schicht derselben Applikation stets API(s) bzw. Container derselben Version zugeordnet werden. Mit anderen Worten stellt das Versionsmanagement-Modul sicher, dass der Frontend-Schicht und der Backend-Schicht nicht API(s) bzw. Container zur Verfügung gestellt werden, die aus unterschiedlichen Versionen der Applikationsplattform stammen.
-
Das Versionsmanagement-Modul kommuniziert mit den Containern vorzugsweise unter Verwendung eines bestimmten, durch entsprechende Spezifikationen festgelegten Protokolls. Sofern mehrere Versionen dieses Protokolls existieren, sind in bevorzugter Ausgestaltung der Erfindung mehrere Versionen des Versionsmanagement-Moduls parallel implementiert, wobei jede dieser Versionen des Versionsmanagement-Moduls jeweils eine der unterschiedlichen Versionen des Protokolls verwendet. Die Protokollversionen entsprechen hierbei nicht zwangsweise den Versionen der Applikationsplattform. Insbesondere ist vorstellbar, dass sich das verwendete Protokoll langsamer fortentwickelt als die Applikationsplattform, so dass mehrere aufeinander folgende Versionen der Applikationsplattform dieselbe Protokollversion verwenden.
-
Die verschiedenen Versionen des Versionsmanagement-Moduls sind intern vorzugsweise kaskadierend, d. h. in einer festgelegten Zugriffsreihenfolge implementiert. Dabei werden alle Anfragen zum Starten und Verwalten einer Containerinstanz zunächst stets an die jüngste Version des Versionsmanagement-Moduls gerichtet, wobei diese Version des Versionsmanagement-Moduls zunächst prüft, ob sie hinsichtlich der verwendeten Protokollversion mit dem für die betroffene Applikation benötigten Container übereinstimmt. Bei festgestellter Inkompatibilität delegiert die jüngste Version des Versionsmanagement-Moduls die Anfrage an diejenige ältere Version des Versionsmanagement-Moduls, die mit der Applikation kompatibel ist, die also hinsichtlich des verwendeten Protokolls mit einem Container kompatibel ist, der wiederum mit der Applikation kompatibel ist.
-
Grundsätzlich können die der Frontend-Schicht und der Backend-Schicht jeweils zugeordneten API(s) oder Container unterschiedlich aufgebaut sein. In einer besonders einfachen Verfahrensvariante werden abweichend hiervon grundsätzlich gleich aufgebaute API(s), und gegebenenfalls gleich aufgebaute Container sowohl für die Frontend-Schicht als auch für die Backend-Schicht einer Applikation zur Verfügung gestellt. In diesem Fall weist das Versionsmanagement-Modul der Frontend-Schicht und der Backend-Schicht der Applikation also jeweils zwei Instanzen der gleichen API(s) bzw. des gleichen Containers zu.
-
Alle vorstehend beschriebenen Varianten und Ausführungsformen des erfindungsgemäßen Verfahrens und der zugeordneten Applikationsplattform sind – soweit möglich – in beliebiger Kombination miteinander einsetzbar.
-
Nachfolgend wird ein Ausführungsbeispiel der Erfindung anhand einer Zeichnung näher erläutert. Darin zeigen:
-
1 in einem schematischen Blockschaltbild eine Datenverarbeitungseinrichtung mit einem Server und einem Client, sowie mit einer auf dem Server und dem Client implementierten Applikationsplattform vor einem Plattform-Update,
-
2 in Darstellung gemäß 1 die Datenverarbeitungseinrichtung nach dem Update der Applikationsplattform,
-
3 in einem schematischen Blockschaltbild im größeren Detail den Aufbau der Applikationsplattform,
-
4 in einem Flussdiagramm ein von der Applikationsplattform durchgeführtes Verfahren zum Betrieb der Datenverarbeitungseinrichtung, und
-
5 in schematischer Darstellung die Ausgabe einer von der Applikationsplattform zur Verfügung gestellten Nutzerschnittstelle für mehrere auf der Applikationsplattform laufende (Software-)Applikationen.
-
Einander entsprechende Teile, Größen und Strukturen sind in allen Figuren stets mit gleichen Bezugszeichen versehen.
-
Die in 1 grob schematisch dargestellte Datenverarbeitungseinrichtung 1 ist beispielhaft für den Einsatz in einer medizinischen Einrichtung wie z. B. einer Klinik vorgesehen. Die Datenverarbeitungseinrichtung 1 umfasst eine Vielzahl von Clients 2 (von denen der Einfachheit halber lediglich einer dargestellt ist) sowie einen zentralen Server 3. Die Clients 2 und der Server 3 sind durch ein (Datenübertragungs-)Netzwerk 4 wie z. B. ein so genanntes LAN (Local Area Network) datenübertragungstechnisch verbunden.
-
Auf jedem Client 2 sowie auf dem Server 3 ist hierbei eine Applikationsplattform 5 implementiert. Im Rahmen der auf den Clients 2 und dem Server 3 aufgebauten Software-Architektur ist die Applikationsplattform 5 jeweils einem Betriebssystem 6 und einer Mehrzahl von (Software-)Applikationen, zwischengeschaltet. In 1 sind hierbei beispielhaft drei Applikationen 7a, 7b und 7c dargestellt.
-
Im dargestellten Beispiel setzt die Applikationsplattform 5 nicht direkt auf dem Betriebssystem 6 der Clients 2 bzw. des Servers 3 auf. Vielmehr ist hier der Applikationsplattform 5 jeweils eine Laufzeitumgebung 8 zwischengeschaltet. Als Laufzeitumgebung 8 werden beispielsweise die sogenannte JAVA Runtime Environment oder das .NET-Framework verwendet.
-
Jede der Applikationen 7a–7c umfasst selbst jeweils zwei Schichten, die auf die Clients 2 und den Server 3 verteilt implementiert sind, nämlich eine clientseitig implementierte Frontend-Schicht 9 sowie eine serverseitig implementierte Backend-Schicht 10. Zur Kommunikation mit den Applikationen 7a–7c stellt die Applikationsplattform 5 sowohl clientseitig als auch serverseitig mehrere Programmierschnittstellen zur Verfügung, auf die die Frontend-Schichten 9 und Backend-Schichten 10 der Applikationen 7a–7c zugreifen. Aus Vereinfachungsgründen wird im Folgenden ohne Beschränkung der Allgemeinheit beispielhaft auf lediglich eine Programmierschnittstelle (nachfolgend als API 11 bezeichnet) Bezug genommen.
-
1 zeigt die Datenverarbeitungseinrichtung 1 in ihrem ursprünglichen Zustand, insbesondere vor einem Update der Applikationsplattform 5. In diesem Zustand liegt die Applikationsplattform 5 beispielhaft in einer Version V1 vor. Im Zuge eines Updates soll diese ältere Version V1 durch eine jüngere Version V2 der Applikationsplattform 5 ersetzt werden.
-
Beim Update der Applikationsplattform 5 wird nun auf nachfolgend näher beschriebene Weise automatisch überprüft, ob die API 11 der zu installierenden jüngeren Version V2 der API 11 der bestehenden Version V1 hinsichtlich der Schnittstellenspezifikation und des Schnittstellenverhaltens entspricht. Ist dies der Fall, so wird die bestehende Version V1 der Applikationsplattform 5 sowohl clientseitig als auch serverseitig mit der jüngeren Version V2 überschrieben. In diesem Fall entspricht der Endzustand der Datenverarbeitungseinrichtung 1 nach erfolgtem Update weiterhin der Darstellung gemäß 1, wobei allerdings die Applikationsplattform 5 sowohl serverseitig als auch clientseitig nun in der Version V2 vorliegt.
-
Wird dagegen bei dem Update festgestellt, dass die API 11 der Version V2 der Applikationsplattform 5 hinsichtlich ihrer Schnittstellenspezifikation oder des Schnittstellenverhaltens der API 11 der bestehenden Version V1 nicht entspricht, so wird die jüngere Version V2 der Applikationsplattform 5 parallel (side-by-side) zu der bestehenden Version V1 implementiert. Nach erfolgtem Update liegen in diesem Fall also – wie in 2 gezeigt – sowohl auf dem Client 2 als auch auf dem Server 3 jeweils beide Versionen V1 und V2 der Applikationsplattform 5 vor.
-
Unmittelbar nach dem Update greifen die mit der älteren Version V1 der Applikationsplattform 5 kompatiblen Applikationen 7a–7c noch wie zuvor auf die API 11 der älteren Version V1 zurück. Dank der parallelen Implementierung der beiden Versionen V1 und V2 können nun die Applikationen 7a–7c, wie dies in 2 am Beispiel der Applikation 7c dargestellt ist, durch Migration M, d. h. durch entsprechende Code-Änderungen an die jüngere Version V2 angepasst werden. 2 zeigt mit durchgezogenen Linien einen Zwischenzustand, in dem die Applikationen 7a und 7b noch auf die API 11 der älteren Version V1 zugreift, während die Applikation 7c schon auf die jüngere Version V2 migriert ist.
-
Wie 2 zu entnehmen ist, müssen sowohl die Frontend-Schicht 9 als auch die Backend-Schicht 10 der Application 7c migriert werden.
-
Es kann vorgesehen sein, dass stets alle Bestandteile der Applikationsplattform 5 in beiden Versionen V1 und V2 parallel implementiert werden. Bevorzugt werden aber einzelne Bestandteile und Module der Applikationsplattform 5 kraft vorgegebener Festlegung stets rückwärtskompatibel fortentwickelt. In diesem Fall werden bevorzugt nur die übrigen Bestandteile der Applikationsplattform 5, insbesondere die API 11, bei einem kompatibilitätsbrechenden Versionsübergang in beiden Versionen V1 und V2 parallel implementiert. Die rückwärtskompatiblen Komponenten der Version V1 werden ohne gesonderte Prüfung mit den entsprechenden Komponenten der Version V2 überschrieben und interagieren bedarfsweise mit den übrigen Komponenten der Version V1 oder der Version V2.
-
Wie aus 3 hervorgeht, umfasst die Applikationsplattform 5 ein Update-Modul 12, das den Updatevorgang steuert. Das Update-Modul 12 ist in 3 beispielhaft als fester Softwarebestandteil der serverseitig implementierten Applikationsplattform 5 dargestellt. Abweichend hiervon kann das Update-Modul 12 aber auch separat von der eigentlichen Applikationsplattform 5 implementiert sein. Insbesondere kann das Update-Modul 12 Bestandteil eines der Applikationsplattform 5 zugeordneten Setup-Programms sein, das nach erfolgtem Update nicht mehr benötigt wird und entsprechend aus dem der Datenverarbeitungseinrichtung 1 zugeordneten Speicher gelöscht werden kann.
-
Weiterhin umfasst die Applikationsplattform 5 ein Applikationsstart-Modul 13. Dieses Softwaremodul ist programmtechnisch dazu eingerichtet, den Start der auf der Applikationsplattform 5 aufbauenden Applikationen 7a–7c zu veranlassen. Dieses Software-Modul ist im Beispiel gemäß 3 ebenfalls serverseitig implementiert. Alternativ hierzu könnte das Applikationsstart-Modul 13 aber auch clientseitig implementiert sein.
-
Als zentralen Bestandteil umfasst die Applikationsplattform 5 serverseitig zusätzlich ein Versionsmanagement-Modul 14. Die Hauptaufgabe dieses Software-Moduls besteht darin, im Betrieb der Applikationsplattform 5 für jede zu startende Applikation 7a–7c die API 11 sowie Containerinstanzen 16, 17 in einer kompatiblen Version V1 oder V2 auszuwählen, zu starten und zu verwalten.
-
Zum Starten der jeweils zugehörigen Containerinstanzen 16, 17 umfasst die Applikationsplattform 5 ein Containerstart-Modul 15 der Erfindungsmeldung, wobei dieses Softwaremodul sowohl clientseitig als auch serverseitig implementiert ist.
-
Im Betrieb der Applikationsplattform 5 ist für jede auf ihr ablaufende Applikation 7a–7c sowohl clientseitig als auch serverseitig jeweils eine Containerinstanz 16 erzeugt, die die Frontend-Schicht 9 bzw. die Backend-Schicht 10 der jeweiligen Applikation 7a–7c kapselt. Die API 11 ist zum Teil als Bestandteil der Containerinstanzen 16, 17 implementiert. Die API 11 umfasst aber darüber hinaus auch Bestandteile, die von den Containerinstanzen 16, 17 unabhängig sind.
-
Grundsätzlich werden clientseitig und serverseitig gleiche Containerinstanzen 16, also Instanzen (d. h. Verkörperungen oder Exemplare) desselben Containers verwendet. So sind insbesondere die die Frontend-Schicht 9 und die Backend-Schicht 10 derselben Applikationen 7b und 7c kapselnden Containerinstanzen 16 jeweils gleich. Abweichend von dem anhand der Applikationen 7b und 7c dargestellten Grundprinzip, dass Frontend-Schichten 9 und Backend-Schichten 10 stets durch gleiche Containerinstanzen 16 gekapselt werden, wird die Frontend-Schicht 9 der ersten Applikation 7a in einer modifizierten Containerinstanz 17 gekapselt. Diese Containerinstanz 17 umfasst zusätzlich eine Nutzerschnittstelle 18, die einen gemeinsamen Rahmen 40 (5) für die frontendseitigen Container 16 und 17 aller laufenden Applikationen 7a, 7b und 7c zur Verfügung stellt. Zur Erzeugung und Steuerung der Containerinstanz 17 umfasst die Applikationsplattform 5 clientseitig ein als Prozessverbindungs-Modul 19 bezeichnetes Softwaremodul.
-
Durch das Versionsmanagement-Modul 14 werden für jede Applikation 7a bis 7c die API 11 und die Containerinstanzen 16, 17 stets in derjenigen Version V1, V2 ausgewählt, die kompatibel mit der jeweiligen Applikation 7a–7c ist. Analog zu dem Beispiel gemäß 2, bei dem die Applikationen 7a und 7b kompatibel mit der Version V1, und die Applikation 7c nach ihrer Migration M kompatibel mit der Version V2 ist, werden also für die Applikationen 7a und 7b die API und die Containerinstanzen 16, 17 in der Version V1 ausgewählt, während für die Applikation 7c die API und die Containerinstanzen 16 in der Version V2 ausgewählt werden.
-
Das Versionsmanagement-Modul 14 kommuniziert mit den Containerinstanzen 16 und 17 unter Verwendung eines bestimmten Protokolls, das gegebenenfalls in verschiedenen Protokollversionen P1 und P2 vorliegt. Lediglich beispielhaft verwenden die Containerinstanzen 16, 17 in der Version V1 die Protokollversion P1, während die Containerinstanzen 16, 17 in der Version V2 die Protokollversion P2 verwenden. Um beide Containterversionen verwalten zu können, ist deshalb auch das Versionsmanagement-Modul 14 in mehreren Versionen V1 und V2 parallel implementiert, wobei das Versionsmanagement-Modul 14 in der Version V1 hier beispielhaft die Protokollversion P1 unterstützt, während das Versionsmanagement-Modul 14 in der Version V2 die Protokollversion P2 unterstützt.
-
Die Funktionsweise der Applikationsplattform 5 wird in 4 anhand eines schematisch vereinfachten Flussdiagramms näher beschrieben, das einen typischen Verfahrensablauf beim Update der Applikationsplattform 5 und dem anschließenden Laden der Applikation 7a bis 7c beschreibt.
-
Danach liest das Update-Modul 12 im Zuge des Update-Prozesses in einem ersten Schritt 20 eine Information aus, die der neu zu implementierenden Version V2 der Applikationsplattform 5 zugeordnet ist, und die die Schnittstellenkompatibilität der Version V2 mit der bestehenden Version V1 angibt. In einem folgenden Schritt 21 prüft das Update-Modul 12 die ausgelesene Information. Sofern diese Prüfung ergibt, dass die API 11 der Version V2 im Vergleich zu der API 11 der bestehenden Version V1 in kompatibilitätsbrechender Weise verändert wurde, veranlasst das Update-Modul 12 in einem folgenden Schritt 22 die parallele Implementierung der Applikationsplattform 5 – oder zumindest deren nicht rückwärts kompatiblen Teile – in den Versionen V1 und V2. Dabei installiert das Update-Modul 12 insbesondere die API 11, die Container und das Versionsmanagement-Modul 14 der Version V2 parallel zu den entsprechenden Software-Komponenten der bestehenden Version V1, wie in 3 durch gepunktete Pfeile 23 angedeutet ist.
-
Falls dagegen die in Schritt 21 vorgenommene Prüfung ergibt, dass die API 11 der Version V2 im Vergleich zu der API 11 der Version V1 nicht oder lediglich in nicht-kompatibilitätsbrechender Weise verändert wurde, installiert das Update-Modul 12 in Schritt 24 die neue Version V2 über der bestehenden Version V1. Der Update-Prozess ist damit abgeschlossen.
-
Der zeitlich unmittelbar oder mittelbar anschließende Start einer der Applikationen 7a–7c erfolgt durch das Applikationsstart-Modul 13, das in einem Schritt 25 mit dem Laden der zu startenden Applikation 7a–7c beginnt (Pfeil 26 in 3). Das Applikationsstart-Modul 13 stellt gleichzeitig an das Versionsmanagement-Modul 14 der jüngsten, zur Verfügung stehenden Version V2 eine Anfrage zur Erzeugung von Containerinstanzen 16, 17 (Pfeil 27 in 3). Das Versionsmanagement-Modul 14 liest in einem folgenden Schritt 28 Angaben zu der Schnittstellenkonfiguration der geladenen Applikation 7a–7c aus.
-
In einem weiteren Schritt 29 prüft das Versionsmanagement-Modul 14 in der zunächst aktiven Version V2, ob die von der geladenen Applikation 7a–7c benötigte Containerversion mit der von ihm unterstützten Protokollversion P2 übereinstimmt.
-
Ist dies der Fall, so aktiviert das in der Version V2 vorliegende Versionsmanagement-Modul 14 in einem Schritt 30 die serverseitig und clientseitig implementieren Containerstart-Module 15 (wie in 3 durch einen Pfeil 31 angedeutet ist).
-
Andernfalls übergibt das in der Version V2 vorliegende Versionsmanagement-Modul 14 in einem Schritt 32 die Anfrage an das der älteren Version V1 entsprechende Versionsmanagement-Modul 14, das nun seinerseits die Containerstart-Module 15 aktiviert (Schritt 30 in 4 bzw. Pfeil 31 in 3).
-
Die Containerstart-Module 15 erzeugen nun client- und serverseitig je eine Containerinstanz 16, 17 der von der jeweiligen Applikation 7a–7c benötigten Version V1 oder V2 (Schritt 33 in 4, in 3 angedeutet durch Pfeile 34).
-
Beim Start der ersten Applikation 7a wird hierbei frontendseitig von dem Containerstart-Modul 15 unter Vermittlung des Prozessverbindungsmoduls 19 die Containerinstanz 17 gestartet (Pfeil 35 in 3). Allen danach gestarteten Applikationen 7b und 7c und deren frontendseitigen Containerinstanzen 16 wird durch diese übergeordnete Containerinstanz 17 eine zugehörige Position in dem von der Nutzerschnittstelle 18 geschaffenen gemeinsamen Rahmen 40 bzw. Fenster zugewiesen (Pfeil 36 in 3).
-
Die von der Nutzerschnittstelle 18 erzeugte Bildschirmausgabe ist in 5 beispielhaft und schematisch vereinfacht dargestellt. Der gemeinsame Rahmen 40 ist hier beispielhaft nach Art eines MS-Windows-Fensters dargestellt. Den frontendseitig parallellaufenden Betriebssystemprozessen, die durch die Frontend-Schichten 9 der Applikationen 7a bis 7c mit den zugehörigen frontendseitigen Containerinstanzen 17 und 16 gebildet sind, ist in diesem Rahmen 40 jeweils ein – beispielhaft nach Art einer Registerkarte dargestelltes – Ausgabefeld zugeordnet. Anschaulich gesprochen läuft also in jeder Registerkarte ein separater Betriebssystemprozess. In der Darstellung gemäß 5 ist beispielsweise der der Applikation 7a zugeordnete Prozess im Vordergrund eingeblendet, während die den Applikationen 7b und 7c zugeordneten Prozesse im Hintergrund der Bildschirmausgabe laufen.
-
Durch die Darstellung in dem gemeinsamen Rahmen werden die den Applikationen 7a–7c zugeordneten Betriebssystemprozesse dargestellt wie ein einziger Prozess. Der Nutzer kann somit zwischen diesen Prozessen – beispielsweise durch Mausklick – wechseln, ohne den Prozess- bzw. Applikationswechsel zu bemerken.
-
Das Umschalten von Prozess zu Prozess bzw. von Applikation zu Applikation erfolgt durch Algorithmen, die die Containerinstanz 17 im Rahmen der Nutzerschnittstelle 18 zur Verfügung stellt.
-
Wie aus 3 entnehmbar ist, werden durch das Prozessverbindungsmodul 19 und die von diesem gestartete übergeordnete Containerinstanz 17 insbesondere auch Prozesse verbunden, die auf verschiedenen Versionen V1, V2 der Applikationsplattform 5 aufbauen und/oder verschiedene Protokollversionen P1, P2 benutzen. Hierdurch wird insbesondere sichergestellt, dass sich infolge eines Updates der Applikationsplattform 5 und teilweise vorgenommer Migration der auf dieser aufbauenden Applikationen 7a–7c das Ausgabeverhalten der Applikationen 7a–7c nicht grundlegend ändert. Dem Nutzer wird vielmehr durch das Prozessverbindungsmodul 19 suggeriert, dass die Applikationen 7a–7c auch nach teilweiser Migration auf die neue Version V2 zumindest frontendseitig wie ein einziger Prozess arbeiten.
-
Bezugszeichenliste
-
- 1
- Datenverarbeitungseinrichtung
- 2
- Client
- 3
- Server
- 4
- (Datenübertragungs-)Netzwerk
- 5
- Applikationsplattform
- 6
- Betriebssystem
- 7a, b, c
- Applikationen
- 8
- Laufzeitumgebung
- 9
- Frontend-Schicht
- 10
- Backend-Schicht
- 11
- API
- 12
- Update-Modul
- 13
- Applikationsstart-Modul
- 14
- Versionsmanagement-Modul
- 15
- Containerstart-Modul
- 16
- Containerinstanz
- 17
- Containerinstanz
- 18
- Nutzerschnittstelle
- 19
- Prozessverbindungs-Modul
- 20
- Schritt
- 21
- Schritt
- 22
- Schritt
- 23
- Pfeil
- 24
- Schritt
- 25
- Schritt
- 26
- Pfeil
- 27
- Pfeil
- 28
- Schritt
- 29
- Schritt
- 30
- Schritt
- 31
- Pfeil
- 32
- Schritt
- 33
- Schritt
- 34
- Pfeil
- 35
- Pfeil
- 36
- Pfeil
- 40
- Rahmen
- M
- Migration
- P1
- Protokollversion
- P2
- Protokollversion
- V1
- Version
- V2
- Version
