DE102010011658A1

DE102010011658A1 - Applikationsplattform und Verfahren zum Betrieb einer Datenverarbeitungseinrichtung mit einer solchen

Info

Publication number: DE102010011658A1
Application number: DE201010011658
Authority: DE
Inventors: Karlheinz Dorn; Armin Michel; Dr. Ukis Vladyslav
Original assignee: Siemens AG
Current assignee: SIEMENS HEALTHINEERS AG, DE
Priority date: 2010-03-17
Filing date: 2010-03-17
Publication date: 2011-09-22
Also published as: US9063817B2; US20110231832A1

Abstract

Es wird eine Applikationsplattform (5) angegeben sowie ein Verfahren zum Betrieb einer Datenverarbeitungseinrichtung (1), auf der die Applikationsplattform (5) implementiert ist sowie mindestens eine Applikation (7a–7c), die auf der Applikationsplattform (5) durch Zugriff auf mindestens eine Programmierschnittstelle (11) der Applikationsplattform (5) lauffähig ist. Bei einem Versionswechsel der Applikationsplattform (5) oder eines Plattformteils wird dabei durch ein Update-Modul (12) geprüft, ob eine neu zu installierende jüngere Version (V2) der Applikationsplattform (5) oder des Plattformteils der bestehenden älteren Version (V1) der Applikationsplattform (5) bzw. des Plattformteils hinsichtlich der Schnittstellenspezifikation und/oder des Verhaltens der oder jeder Programmierschnittstelle (11) entspricht. Gegebenenfalls überschreibt das Update-Modul (12) die ältere Version (V1) durch die jüngere Version (V2). Andernfalls installiert das Update-Modul (12) die jüngere Version (V2) oder zumindest deren Programmierschnittstelle (11) parallel zu der bestehenden Version (V1) bzw. deren Programmierschnittstelle (11).

Description

Die Erfindung bezieht sich auf ein Verfahren zum Betrieb einer Datenverarbeitungseinrichtung, insbesondere eines Computers oder eines Computernetzwerks, auf der eine Applikationsplattform implementiert ist sowie mindestens eine (Software-)Applikation, die auf der Applikationsplattform durch Zugriff auf mindestens eine Programmierschnittstelle der Applikationsplattform lauffähig ist.
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 darüberhinaus 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. 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. Ein vollständiger oder teilweise Update der Applikationsplattform, d. h. ein Wechsel von einer älteren Version der Applikationsplattform oder eines Plattformteils auf eine jüngere Version derselben Applikationsplattform bzw. des Plattformteils gestaltet sich bei einem solch komplexen System oft problematisch. Häufig wird bei einer Versionsänderung einer Applikationsplattform nämlich auch die Spezifikation und/oder das Verhalten einer API oder mehrerer APIs mehr oder weniger stark geändert, wodurch mitunter die Kompatibilität der (neuen) API(s) mit den vor dem Update bereits vorhandenen Applikationen beeinträchtigt oder gänzlich zerstört wird. Um ein fehlerfreies Funktionieren dieser Applikationen sicherzustellen, müssen die vorhandenen Applikationen in diesem Fall auf die neue Plattformversion „migriert”, d. h. an die Spezifikation bzw. das Verhalten der neuen API(s) angepasst werden.
Bei einer großen Anzahl von Applikationen, die auf einer gemeinsamen Applikationsplattform basieren, ist der Aufwand für einen Plattform-Update oft beträchtlich, da in der Regel alle Applikationen migriert werden müssen. Bei Applikationen, die in Frontend- und Backend-Anteile unterteilt sind, müssen beim Update der Applikationsplattform darüber hinaus beide Applikationsschichten jeder Applikation angepasst werden. Nach der Anpassung müssen Volltests jeder geänderten Applikation gefahren werden, die gerade im medizinischen Bereich besonders intensiv und zeitaufwändig sind. Dies verursacht einerseits einen hohen Arbeitsaufwand. Im ungünstigen Fall kann ein Update der Applikationsplattform auch zu einer vergleichsweise langen Ausfallzeit der medizinischen Einrichtung führen. Der durch die Verwendung der Applikationsplattform erzielte Entwicklungsvorteil wird hierdurch oft erheblich relativiert.
Der Erfindung liegt die Aufgabe zugrunde, ein Verfahren zum Betrieb einer Datenverarbeitungseinrichtung mit einer Applikationsplattform und mindestens einer darauf aufsetzenden Applikation anzugeben, das einen einfach und flexibel handhabbaren Versionswechsel (Update) der Applikationsplattform oder eines Teils derselben ermöglicht. Der Erfindung liegt weiterhin die Aufgabe zugrunde, eine zur Durchführung des Verfahrens besonders geeignete Applikationsplattform anzugeben.
Bezüglich des Verfahrens wird die Aufgabe erfindungsgemäß gelöst durch die Merkmale des Anspruchs 1. Bezüglich der Applikationsplattform wird die Aufgabe erfindungsgemäß gelöst durch die Merkmale des Anspruchs 9. Vorteilhafte Ausführungsformen und Weiterbildungen der Erfindung ergeben sich durch die abhängigen Ansprüche und die nachfolgenden Ausführungen.
Die Applikationsplattform umfasst erfindungsgemäß mindestens eine Programmierschnittstelle (API), in der Regel aber mehrere funktional abgegrenzte Programmierschnittstellen (APIs), unter Zugriff auf welche mindestens eine Applikation auf der Applikationsplattform lauffähig ist. Die Applikationsplattform umfasst desweiteren 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 kompatibiltätsbrechend geänderten API parallel (side-by-side) zu der bestehenden, älteren Version der Applikationsplattform bzw. des Plattformteils oder dieser API installiert.
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 dem Update-Modul und der oder jeder API handelt es sich um Softwarebestandteile der Applikationsplattform.
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.
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.
In bevorzugter Ausführung des Verfahrens werden durch die Applikationsplattform mehrschichtige Applikationen mit einer Frontend-Schicht und einer Backend-Schicht unterstützt. Durch die Applikationsplattform werden in diesem Fall der Frontend-Schicht und der Backend-Schicht jeweils eine oder mehrere API(s) und gegebenenfalls eine Containerinstanz zur Verfügung gestellt. Durch das Versionsmanangement-Modul wird 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.
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.
Zweckmäßigerweise unterstützt die Applikationsplattform die gleichzeitige Ausführung mehrerer Applikationen. Jede der parallel laufenden Applikationen bzw. Applikationsschichten (bei mehrschichtigen Applikationen) bildet zusammen mit dem gegebenenfalls zugeordneten Container jeweils einen separaten (Betriebssystem-)Prozess, so dass regelmäßig eine Mehrzahl von solchen Prozessen parallel ablaufen.
Um einem Nutzer der Datenverarbeitungseinrichtung die Handhabung der gleichzeitig ablaufenden Prozesse zu erleichtern, umfasst die Applikationsplattform in einer zweckmäßigen Variante der Erfindung zusätzlich ein Prozessverbindungmodul, das 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 insbesondere ein gemeinsamer Rahmen für die parallel laufenden Prozesse zur Verfügung gestellt. Die Nutzerschnittstelle ist hierbei beispielsweise Bestandteil eines speziellen Containers, der die Container der übrigen (Frontend-)Prozesse ausgabetechnisch steuert, insbesondere diesen Containern eine Ausgabeposition innerhalb des Rahmens zuweist.
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 Containerversionen 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 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

Claims

Verfahren zum Betrieb einer Datenverarbeitungseinrichtung (1), auf der eine Applikationsplattform (5) implementiert ist sowie mindestens eine Applikation (7a–7c), die auf der Applikationsplattform (5) durch Zugriff auf mindestens eine Programmierschnittstelle (11) der Applikationsplattform (5) lauffähig ist, bei welchem bei einem Versionswechsel der Applikationsplattform (5) oder eines Plattformteils durch ein Update-Modul (12) geprüft wird, ob eine neu zu installierende jüngere Version (V2) der Applikationsplattform (5) bzw. des Plattformteils der bestehenden älteren Version (V1) hinsichtlich der Schnittstellenspezifikation und/oder des Verhaltens der oder jeder Programmierschnittstelle (11) entspricht, und bei welchem das Update-Modul (12) gegebenenfalls die ältere Version (V1) durch die jüngere Version (V2) überschreibt, und andernfalls die jüngere Version (V2) oder zumindest deren Programmierschnittstelle (11) parallel zu der bestehenden Version (V1) bzw. deren Programmierschnittstelle (11) installiert.
Verfahren nach Anspruch 1, bei welchem beim Laden einer Applikation (7a–7c) durch ein Versionsmanagement-Modul (14) geprüft wird, mit welcher Version (V1, V2) diese Applikation (7a–7c) kompatibel ist, und bei welchem das Versionsmanagement-Modul (14) dieser Applikation (7a–7c) die oder jede Programmierschnittstelle (11) der entsprechenden Version (V1, V2) zuordnet startet.
Verfahren nach Anspruch 2, bei welchem jeder laufenden Applikation (7a–7c) durch das Versionsmanagement-Modul (14) pro Applikationsschicht (9, 10) eine Instanz (16, 17) eines Containers der Applikationsplattform (5) zugeordnet wird, wobei das Versionsmanagement-Modul (14) mittels eines bestimmten Protokolls mit Containerinstanzen (16, 17) der oder jeder Version (V1, V2) der Applikationsplattform (5) kommuniziert, und wobei mehrere Versionen (V1, V2) des Versionsmanagement-Moduls (14) parallel implementiert sind, die jeweils unterschiedliche Protokollversionen (P1, P2) verwenden.
Verfahren nach Anspruch 3, bei welchem Anfragen zum Starten oder Verwalten von Containerinstanzen (16, 17) zunächst stets an die jüngste Version (V2) des Versionsmanagement-Moduls (14) gerichtet werden, bei welchem durch diese Version (V2) des Versionsmanagement-Moduls (14) geprüft wird, ob diese Version (V2) hinsichtlich der von ihr unterstützten Protokollversion (P1, P2) mit der betroffenen Containerinstanz (16, 17) kompatibel ist, und bei welchem bei festgestellter Inkompatibilität durch diese Version (V2) des Versionsmanagement-Moduls (14) die Anfrage an eine kompatible ältere Version des Versionsmanagement-Moduls (14) übergeben wird.
Verfahren nach einem der Ansprüche 1 bis 4, bei welchem die oder jede Applikation (7a–7c) eine Frontend-Schicht (9) und eine Backend-Schicht (10) umfasst, und bei welchem der Frontend-Schicht (9) und der Backend-Schicht (10) durch die Applikationsplattform (5) jeweils mindestens eine Programmierschnittstelle (11) zur Verfügung gestellt werden, wobei der Frontend-Schicht (9) und der Backend-Schicht (10) derselben Applikation (7) durch das Versionsmanagement-Modul (14) stets Programmierschnittstellen (11) derselben Version (V1, V2) zur Verfügung gestellt werden.
Verfahren nach Anspruch 5, bei welchem der Frontend-Schicht (9) und der Backend-Schicht (10) derselben Applikation (7a–7c) gleiche Programmierschnittstellen (11) zur Verfügung gestellt werden.
Verfahren nach einem der Ansprüche 1 bis 6, bei welchem durch die Ausführung mehrerer Applikationen (7a–7c) eine Mehrzahl von parallel auf der Applikationsplattform (5) ablaufenden Betriebssystemprozessen erzeugt wird, und bei welchem durch ein Prozessverbindungsmodul (19) eine prozessübergreifende Benutzerschnittstelle (18) erzeugt wird, durch die die parallel laufenden Betriebssystemprozesse gemeinsam mit einem Nutzer der Datenverarbeitungseinrichtung (1) interagieren.
Verfahren nach Anspruch 7, bei welchem durch die prozessübergreifende Benutzerschnittstelle (18) ein gemeinsamer Rahmen (40) für die parallel laufenden Betriebssystemprozesse zur Verfügung gestellt wird.
Applikationsplattform (5) mit mindestens einer Programmierschnittstelle (11), unter Zugriff auf welche mindestens eine Applikation (7a–7c) auf der Applikationsplattform (5) lauffähig ist, mit einem Update-Modul (12), das dazu eingerichtet ist, bei einem Versionswechsel der Applikationsplattform (5) oder eines Plattformteils zu prüfen, ob eine neu zu installierende jüngere Version (V2) der Applikationsplattform (5) oder des Plattformteils der bestehenden älteren Version (V1) der Applikationsplattform (5) bzw. des Plattformteils hinsichtlich der Schnittstellenspezifikation und/oder des Verhaltens der oder jeder Programmierschnittstelle (11) entspricht, und gegebenenfalls die ältere Version (V1) durch die jüngere Version (V2) zu überschreiben sowie andernfalls die jüngere Version (V2) oder zumindest deren Programmierschnittstelle (11) parallel zu der bestehenden Version (V1) bzw. deren Programmierschnittstelle (11) zu installieren.
Applikationsplattform (5) nach Anspruch 9, mit einem Versionsmanagement-Modul (14), das dazu eingerichtet ist, beim Laden einer Applikation (7a–7c) zu prüfen, mit welcher Version (V1, V2) diese Applikation (7a–7c) kompatibel ist, und die oder jede Programmierschnittstelle (11) der entsprechenden Version (V1, V2) zu starten.
Applikationsplattform (5) nach Anspruch 10, das dazu eingerichtet ist, jeder laufenden Applikation (7a–7c) pro Applikationsschicht (9, 10) eine Instanz 16, 17) eines Containers der Applikationsplattform (5) zuzuordnen, wobei das Versionsmanagement-Modul (14) dazu eingerichtet ist, mittels eines bestimmten Protokolls mit Containerinstanzen (16, 17) der oder jeder Version (V1, V2) der Applikationsplattform (5) zu kommunizieren, und wobei mehrere Versionen (V1, V2) des Versionsmanagement-Moduls (14) parallel implementiert sind, die jeweils unterschiedliche Protokollversionen (21,22) verwenden.
Applikationsplattform (5) nach Anspruch 11, wobei die mehreren Versionen (V1, V2) des Versionsmanagement-Moduls (14) kaskadierend implementiert sind, so dass Anfragen zum Starten oder Verwalten von Containerinstanzen (16, 17) zunächst stets an die jüngste Version (V2) des Versionsmanagement-Moduls (14) gerichtet werden, wobei diese Version (V2) des Versionsmanagement-Moduls (14) dazu eingerichtet ist zu prüfen, ob sie hinsichtlich der von ihr unterstützten Protokollversion (P1, P2) mit der betroffenen Containerinstanz (16, 17) kompatibel ist, und bei festgestellter Inkompatibilität die Anfrage an eine kompatible ältere Version des Versionsmanagement-Moduls zu übergeben.
Applikationsplattform (5) nach einem der Ansprüche 9 bis 12, die dazu eingerichtet ist, mehrschichtige Applikationen (7a–7c) mit jeweils einer Frontend-Schicht (9) und einer Backend-Schicht (10) durch Zurverfügungstellung jeweils mindestens einer Programmierschnittstelle (11) für die Frontend-Schicht (9) und die Backend-Schicht (10) zu unterstützen, wobei das Versionsmanagement-Modul (14) dazu eingerichtet ist, der Frontend-Schicht (9) und der Backend-Schicht (10) derselben Applikation (7a–7c) stets Programmierschnittstellen (11) derselben Version (V1, V2) zur Verfügung zu stellen.
Applikationsplattform (5) nach Anspruch 13, wobei das Versionsmanagement-Modul (14) dazu eingerichtet ist, der Frontend-Schicht (9) und der Backend-Schicht (10) derselben Applikation (7a–7c) gleich aufgebaute Programmierschnittstellen (11) zur Verfügung zu stellen.
Applikationsplattform (5) nach einem der Ansprüche 9 bis 14, die dazu eingerichtet ist, mehrere durch die Ausführung mehrerer Applikationen (7a–7c) erzeugte Betriebssystemprozesse parallel ablaufen zu lassen, wobei die Applikationsplattform (5) zusätzlich ein Prozessverbindungsmodul (19) umfasst, das dazu ausgebildet ist, eine prozessübergreifende Nutzerschnittstelle (18) zu erzeugen, durch die die parallel laufenden Betriebssystemprozesse gemeinsam mit einem Nutzer der Datenverarbeitungseinrichtung (1) interagieren.
Applikationsplattform (5) nach Anspruch 15, wobei die prozessübergreifende Nutzerschnittstelle (18) dazu ausgebildet ist, einen gemeinsamen Rahmen (40) für die parallel laufenden Betriebssystemprozesse zur Verfügung zu stellen.