Application platform and method for operating a data processing arrangement having such an application platform

An application platform is disclosed together with a method for operating a data processing arrangement on which the application platform is implemented along with at least one application which is executable on the application platform by accessing at least one programming interface of the application platform. In at least one embodiment, in the course of a change of version of the application platform or of a part of the platform, a check is carried out by way of an update module to determine whether a newly-to-be-installed more recent version of the application platform or of the part of the platform is consistent with the existing older version of the application platform or of the part of the platform in terms of the interface specification and/or the behavior of the or each programming interface. If necessary, the update module overwrites the older version with the more recent version. Otherwise the update module installs the more recent version or at least its programming interface in parallel with the existing version or its programming interface.

PRIORITY STATEMENT

The present application hereby claims priority under 35 U.S.C. §119 on German patent application number DE 10 2010 011 658.0 filed Mar. 17, 2010, the entire contents of which are hereby incorporated herein by reference.

FIELD

At least one embodiment of the invention generally relates to a method for operating a data processing arrangement, in particular a computer or a computer network, on which an application platform has been implemented along with at least one (software) application which is executable on the application platform through access to at least one programming interface of the application platform.

The term “application platform” denotes a (generic or domain-specific) software platform, i.e. an inter-application software solution that is interposed between the computer hardware with the operating system running thereon on the one hand and the applications, i.e. the actual application programs, on the other hand. A widely established example of such an application platform is J2EE (Java Platform, Enterprise Edition).

BACKGROUND

An application platform typically provides basic functions that are required by a multiplicity of applications, e.g. the reading, writing, deleting and archiving of data. Often an application platform also provides a user interface, i.e. functions such as graphical control elements, etc., via which applications can interact with a user for the purpose of inputting and outputting data. An application platform that is specialized for software applications in the medical field often also provides medically relevant basic functions in addition, e.g. algorithms for inspecting, analyzing and processing medical images. The function portfolio that is made available by an—in particular specialized—application platform enables the development time for software applications to be shortened significantly, in particular in the medical environment.

To allow easy access to the functions of an application platform, the latter generally provides what is termed an application programming interface (API) or a plurality of such programming interfaces (APIs), the functions of which can be integrated into the applications that are to be created. Furthermore an application platform sometimes provides what is termed an (application) container in which an application or, in the case of multi-layered applications, a layer of an application runs in encapsulated form. In this case the container controls the execution sequence of the application, in particular the program start and the termination of the application. In addition at least part of the API(s) is typically implemented as a component part of the container. Often, however, the APIs also include additional functions which are implemented independently of the container and which the applications can also access accordingly independently of the container.

The term “function” signifies both here and in the following description in general a functional component of a software program. Such a function can also be realized as a “method” within the context of object-oriented programming or in another form.

By providing a container a correspondingly embodied application platform particularly effectively supports the development of multi-layered, distributed applications, in other words applications that comprise a plurality of mutually independently running parts (layers) which interact with one another via the application platform. In this case medical engineering applications frequently include in particular a so-called frontend layer, the primary purpose of which is interaction with the user, and a so-called backend layer, in which most of the actual calculations are performed. In a computer network, as commonly used these days in medical institutions, the backend layer is in this case implemented mostly in a central server, while the frontend layer is implemented on a client, i.e. a workstation. The application platform is in this case implemented both on the server side and on the client side and also supports the communication between these hardware devices. In this arrangement the frontend layer and the backend layer are encapsulated by the application platform usually in a separate container in each case.

In a typical data processing system of a contemporary medical institution a multiplicity of different medical engineering applications are often implemented on a shared, cross-network application platform. A full or partial update of the application platform, i.e. a change from an older version of the application platform or a part of the platform to a more recent version of the same application platform or part of the platform often proves to be problematic in the case of such a complex system. This is because when there is change of version of an application platform, frequently the specification and/or behavior of an API or a plurality of APIs is also changed to a greater or lesser degree, as a result of which the compatibility of the (new) API(s) with the applications already present before the update is sometimes compromised or destroyed altogether. In order to ensure error-free operation of these applications, the existing applications must in this case be “migrated” to the new platform version, i.e. adapted to match the specification and/or behavior of the new API(s).

Where there are a large number of applications based on a common application platform the amount of effort involved in performing a platform update is often considerable because usually all of the applications must be migrated. In the case of applications which are subdivided into frontend and backend components it is necessary in addition to update both application layers of each application when the application platform is updated. Following the update full tests of every modified application must be run, the tests being particularly exhaustive and time-consuming most notably in the medical field. This causes a heavy workload on the one hand. In the worst case an update of the application platform can also lead to a comparatively long downtime of the medical institution. The development advantage achieved through the use of the application platform is often substantially diminished as a result.

SUMMARY

In at least one embodiment the invention, a method is disclosed for operating a data processing arrangement having an application platform and at least one application running thereon, which method enables a flexible and easy-to-handle version change (update) of the application platform or a part of the same. A further embodiment of the invention discloses an application platform that is particularly suitable for performing the method.

With regard to at least one embodiment of the method, advantageous embodiment variants and developments of the invention will emerge from the claims and the following description.

According to at least one embodiment of the invention, the application platform includes at least one programming interface (API), though generally it includes a plurality of functionally delimited programming interfaces (APIs), by accessing which at least one application is executable on the application platform. The application platform additionally includes an update module.

In the event of a change of version of the application platform or of a part of the platform, a check is carried out by the update module to determine whether a more recent version of the application platform that is to be newly installed is consistent with the existing older version of the application platform in terms of the interface specification or the interface behavior of the or each API.

What is to be understood as “(interface) specification” in this context is the totality of criteria that an application accessing the API must comply with in order to be compatible with the API. These criteria include for example the nomenclature for the functions of the API and the definition of arguments (i.e. variables) of these functions.

What is referred to as “(interface) behavior” in this context is the totality of those characteristics of an API which become apparent only at platform runtime. In this case the behavior of an API is determined in particular by the response time or computing time associated with the invocation of each API functionality, the accuracy of return values of such functionalities, etc.

Provided the APIs or each API of the more recent and older version of the application platform are consistent in terms of the interface specification and interface behavior it is thereby ensured that the applications running on the older version of the application platform are also compatible with the more recent version. In this case the update module causes the older version of the application platform or part of the platform to be overwritten by the more recent version. Alternatively, if it is established by the update module that the more recent version of the application platform or part of the platform is not consistent in terms of the interface specification or interface behavior with an API of the older version, in other words exhibits compatibility-breaking modifications, the update module initiates the installation of the more recent version of the application platform or part of the platform or at least of the API that has been modified in a compatibility-breaking manner in parallel (side-by-side) with the existing, older version of the application platform or part of the platform or of the API.

Generally, the application platform is a software product whose component parts are configured for the purpose of performing the above-described method or one of its below-described variants by programming means, such that the method is automatically performed when the application platform is implemented on a data processing arrangement and executed. The update module and the API or each API are software components of the application platform.

Owing to the possibility of installing multiple versions of the application platform or its API(s) in parallel it is made possible for each of the applications implemented on the data processing arrangement to access a corresponding compatible version of the API(s) in accordance with its respective interface compatibility. If a plurality of applications are implemented on the data processing arrangement, then in this case in particular some of the applications can access the API(s) associated with the older platform version, while other applications access the API(s) associated with the more recent platform version. In the event of an update of the application platform in which at least one API is modified in a compatibility-breaking manner there is therefore no necessity to migrate the applications running on the application platform immediately. Rather, the applications can be migrated progressively and successively to the more recent version or even left long-term in the previous state. In this way it is ensured that the platform update does not lead, or at least leads only to a negligible degree, to downtimes of the data processing arrangement or the applications implemented thereon. In addition the workload associated with the migration of the applications can be divided up in a flexible manner, in particular can be “stretched” over time. Furthermore one and the same application can also be implemented in multiple versions in parallel. For example, in addition to a version migrated to a new platform version of a particular application the older version of the same application running on an older platform version can be maintained.

Furthermore the compatibility check of the API(s) performed by the update module ensures that the different platform versions are not installed “blind” next to one another, but are installed only when this is necessary due to the established incompatibility of the API(s). The number of versions of the application platform that are implemented on the data processing arrangement over the long term is thus limited to a minimum, thereby saving memory space and reducing the complexity of the overall software structure implemented on the data processing arrangement.

The compatibility check performed by the update module can basically be carried out in different ways. In a simplest method variant, and therefore one that is used by preference, the more recent, newly-to-be-installed version of the application platform includes a specific indication, attached by the vendor, relating to its compatibility with one or more previous versions of the application platform. This information, which directly indicates whether the interface specification and/or the interface behavior of the two API versions are consistent, is in this case read out by the update module.

In an alternative method variant each version of the application platform includes details concerning the corresponding interface specification and/or the interface behavior which the update module in this case reads out and compares with one another. Again as an alternative hereto it is conceivable for the update module to test the API(s) of the more recent version for compatibility. Hybrid forms of these three alternatives are also conceivable within the scope of at least one embodiment of the invention. In particular it can be provided that the compatibility in terms of the interface specification is determined on the basis of stored information, while the compatibility in terms of the interface behavior is established by way of tests.

Insofar as multiple versions of the application platform, individual platform components and/or API(s) have already been installed in parallel in the course of a single or multiple platform update, a check is carried out by a version management module during the loading of each application to determine with which of the installed platform versions the application is compatible. In this case the API(s) of the corresponding compatible version is (are) selected by the version management module, which is a further software component of the application platform that is provided in this case, and made available. The loaded application is in this case executed in particular in a container originating from the corresponding platform version and containing the API(s), or at least a part thereof. The container in this case contains in particular the API(s) which include functions for what is referred to as the “lifecycle” of the associated application, in particular the starting, stopping, suspending or reawakening of the application.

The version management module communicates with the containers preferably using a specific protocol defined by corresponding specifications. In an example embodiment of the invention, if multiple versions of the protocol exist, multiple versions of the version management module are implemented in parallel, each of these versions of the version management module using one of the different versions of the protocol in each case. The protocol versions do not necessarily correspond to the versions of the application platform in this case. In particular it is conceivable that the continuing development of the protocol used progresses at a slower pace than that of the application platform, with the result that a number of succeeding versions of the application platform will use the same protocol version.

The different versions of the version management module are preferably cascaded internally, i.e. implemented in a specified access sequence. In this case all requests for starting and managing a container instance are always addressed initially to the most recent version of the version management module, the version of the version management module first checking whether it tallies with the container required for the affected application in terms of the protocol version used. If incompatibility is established the most recent version of the version management module delegates the request to that older version of the version management module which is compatible with the application, in other words the one which is compatible in terms of the protocol used with a container which is in turn compatible with the application.

In an example embodiment of the method, multi-layer applications having a frontend layer and a backend layer are supported by the application platform. In this case the frontend layer and the backend layer are each provided with one or more API(s) and if necessary a container instance by the application platform. It is ensured by the version management module in this case that the frontend layer and the backend layer of the same application are always assigned API(s) or containers of the same version. In other words the version management module ensures that the frontend layer and the backend layer are not provided with API(s) or containers which come from different versions of the application platform.

Basically, the API(s) or containers assigned in each case to the frontend layer and the backend layer can have a different structure. Alternatively hereto, in a particularly simple method variant, essentially identically structured API(s) and where applicable identically structured containers are made available both for the frontend layer and for the backend layer of an application. In this case the version management module accordingly allocates the frontend layer and the backend layer of the application two instances of the same API(s) or of the same container in each case.

The application platform beneficially supports the simultaneous execution of a plurality of applications. Each of the parallel-running applications or application layers (in the case of multi-layer applications) together with the possibly assigned container forms a separate (operating system) process in each case, such that a plurality of such processes regularly run in parallel.

In order to make it easier for a user of the data processing arrangement to handle the concurrently running processes, in a beneficial variant of at least one embodiment of the invention the application platform additionally includes a process connection module which generates an inter-process user interface by means of which the parallel-running processes collectively interact with the user of the data processing arrangement. Notwithstanding this, however, in multi-layered applications having a frontend layer and a backend layer this relates only to the processes assigned to the frontend layer, especially since the processes assigned to the backend layer by definition have no direct user interaction.

As a result of the shared, inter-process user interface the plurality of processes (or, as the case may be, the underlying applications in each case) appear externally like a single process. The user can switch between different processes or applications via the shared user interface without being aware of it. In a beneficial embodiment of the invention, in particular a common frame is provided in this case for the parallel-running processes by the inter-process user interface. In this case the user interface is for example part of a special container which controls the output functions of the containers of the remaining (frontend) processes, in particular allocating an output position within the frame to the containers.

All the above-described variants and embodiments of the method according to the invention and of the associated application platform can—as far as possible—be used with one another in any combination.

Parts, quantities and structures corresponding to one another are labeled consistently with the same reference signs in all the figures.

DETAILED DESCRIPTION OF THE EXAMPLE EMBODIMENTS

The data processing arrangement1shown in rough schematic form inFIG. 1is provided by way of example for use in a medical institution such as e.g. a clinic. The data processing arrangement1comprises a plurality of clients2(only one of which is depicted for the sake of simplicity) and a central server3. The clients2and the server3are connected for data transmission purposes by means of a (data communication) network4such as e.g. a so-called LAN (Local Area Network).

In this arrangement an application platform5is implemented on each client2and on the server3. Within the framework of the software architecture built on the clients2and the server3the application platform5is interposed between an operating system6and a plurality of (software) applications in each case. Three applications7a,7band7care shown by way of example in this case inFIG. 1.

In the example shown the application platform5does not sit directly on top of the operating system6of the clients2or of the server3. Rather, a runtime environment8is interposed here between it and the application platform5in each case. Examples of the runtime environment8used are the so-called JAVA Runtime Environment or the .NET Framework.

Each of the applications7a-7citself comprises two layers in each case which are implemented distributed over the clients2and the server3, namely a frontend layer9implemented on the client side and a backend layer10implemented on the server side. For the purpose of communicating with the applications7a-7cthe application platform5provides a plurality of programming interfaces, both on the client side and on the server side, which are accessed by the frontend layers9and backend layers10of the applications7a-7c. For reasons of simplification reference is made in the following, without loss of generality, to just one programming interface (referred to below as API11) by way of example.

FIG. 1shows the data processing arrangement1in its original state, in particular prior to an update of the application platform5. In this state the application platform5is present in a version V1by way of example. In the course of an update this older version V1is to be replaced by a more recent version V2of the application platform5.

During the update of the application platform5an automatic check, described in more detail below, is now carried out to determine whether the API11of the more recent version V2that is to be installed is consistent in terms of the interface specification and the interface behavior with the API11of the existing version V1. If this is the case, the existing version V1of the application platform5is overwritten both on the client side and on the server side by the more recent version V2. In this case the end state of the data processing arrangement1upon completion of the update continues to correspond to the representation according toFIG. 1, notwithstanding the fact that the application platform5is now present in version V2on both the client side and the server side.

If, on the other hand, it is established during the update that the API11of version V2of the application platform5is not consistent in terms of its interface specification or interface behavior with the API11of the existing version V1, then the more recent version V2of the application platform5is implemented in parallel (side-by-side) with the existing version V1. In this case, upon completion of the update both versions V1and V2of the application platform5are therefore present in each case—as shown in FIG.2—both on the client2and on the server3.

Immediately after the update the applications7a-7cthat are compatible with the older version V1of the application platform5still access the API11of the older version V1as previously. Thanks to the parallel implementation of the two versions V1and V2the applications7a-7ccan now, as shown inFIG. 2based on the example of the application7c, be updated to the more recent version V2by means of migration M, i.e. by means of corresponding code changes.FIG. 2shows by means of continuous lines an intermediate state in which the applications7aand7bstill access the API11of the older version V1, while the application7chas already been migrated to the more recent version V2.

As can be seen fromFIG. 2, both the frontend layer9and the backend layer10of the application7cmust be migrated.

It can be provided that all the component parts of the application platform5are always implemented in both versions V1and V2in parallel. Preferably, however, the continuing development of individual components and modules of the application platform5is always carried out on a backward-compatible basis by virtue of predefined specification. In this case preferably only the remaining components of the application platform5, in particular the API11, are implemented in parallel in both versions V1and V2in a compatibility-breaking version transition. The backward-compatible components of version V1are overwritten without a separate check by the corresponding components of version V2and interact as necessary with the remaining components of version V1or version V2.

As is evident fromFIG. 3, the application platform5includes an update module12which controls the update process. The update module12is shown by way of example inFIG. 3as a fixed software component of the application platform5implemented on the server side. Alternatively thereto, however, the update module12can also be implemented separately from the actual application platform5. In particular the update module12can be part of a setup program which is assigned to the application platform5and which is no longer required following completion of the update and accordingly can be deleted from the memory assigned to the data processing arrangement1.

The application platform5also includes an application start module13. This software module is configured by programming measures to initiate the start of the applications7a-7crunning on the application platform5. The software module is likewise implemented on the server side in the example according toFIG. 3. Alternatively hereto, however, the application start module13could also be implemented on the client side.

The application platform5additionally includes a version management module14as a central component on the server side. The main function of the software module resides in selecting, starting and managing the API11and container instances16,17in a compatible version V1or V2for each application7a-7cthat is to be started during the operation of the application platform5.

In order to start the respective associated container instances16,17the application platform5includes a container start module15of the invention disclosure, the software module being implemented both on the client side and on the server side.

During the operation of the application platform5a container instance16is generated both on the client side and on the server side for each application7a-7crunning thereon, which container instance16encapsulates the frontend layer9and/or the backend layer10of the respective application7a-7c. The API11is implemented in part as a component of the container instances16,17. In addition, however, the API11also includes components which are independent of the container instances16,17.

Essentially, identical container instances16, in other words instances (i.e. embodiments or exemplars) of the same container, are used on both client side and server side. Thus, in particular the container instances16encapsulating the frontend layer9and the backend layer10of the same applications7band7care identical in each case. In a departure from the basic principle, presented with reference to the applications7band7c, that frontend layers9and backend layers10are always encapsulated by means of identical container instances16, the frontend layer9of the first application7ais encapsulated in a modified container instance17. The container instance17additionally includes a user interface18which provides a common frame40(FIG. 5) for the frontend-side containers16and17of all the running applications7a,7band7c. In order to generate and control the container instance17the application platform5includes on the client side a software module referred to as a process connection module19.

For each application7ato7c, the version management module14always selects the API11and the container instances16,17in the version V1,V2that is compatible with the respective application7a-7c. Analogously to the example according toFIG. 2, in which the applications7aand7bare compatible with version V1, and the application7cfollowing its migration M is compatible with version V2, the API and the container instances16,17are therefore selected in version V1for the applications7aand7b, while the API and the container instances16are selected in version V2for the application7c.

The version management module14communicates with the container instances16and17using a specific protocol which may possibly be present in different protocol versions P1and P2. Solely by way of example, the container instances16,17in version V1use protocol version P1, whereas the container instances16,17in version V2use protocol version P2. In order to be able to manage both container versions, the version management module14is therefore also implemented in multiple versions V1and V2in parallel, the version management module14in version V1in this case, by way of example, supporting protocol version P1, while the version management module14in version V2supports protocol version P2.

Referring toFIG. 4, the principle of operation of the application platform5is described in more detail with the aid of a schematically simplified flowchart which represents a typical process workflow during the update of the application platform5and the subsequent loading of the applications7ato7c.

According thereto, in the course of the update process the update module12reads out in a first step20information which is assigned to the newly-to-be-implemented version V2of the application platform5and which specifies the interface compatibility of version V2with the existing version V1. In a following step21the update module12checks the information that has been read out. If the result of this check is that the API11of version V2has been modified in a compatibility-breaking manner compared to the API11of the existing version V1, then in a following step22the update module12initiates the parallel implementation of the application platform5—or at least of the parts thereof that are not backward-compatible—in versions V1and V2. In so doing the update module12installs in particular the API11, the containers and the version management module14of version V2in parallel with the corresponding software components of the existing version V1, as indicated by means of dotted arrows23inFIG. 3.

If, on the other hand, the check performed in step21reveals that the API11of version V2has not been changed, or has been changed merely in a non-compatibility-breaking manner compared to the API11of version V1, then in step24the update module12installs the new version V2over the existing version V1. The update process is therewith completed.

One of the applications7a-7cis started directly or indirectly succeeding in time by the application start module13, which in a step25commences with the loading of the application7a-7cthat is to be launched (arrow26inFIG. 3). The application start module13simultaneously issues a request to the version management module14of the most recent available version V2to generate container instances16,17(arrow27inFIG. 3). In a following step28the version management module14reads out specifications relating to the interface configuration of the loaded application7a-7c.

In a further step29the version management module14checks in the initially active version V2whether the container version required by the loaded application7a-7cis compatible with the protocol version P2supported by it.

If this is the case, then in a step30the version management module14present in version V2activates the container start modules15implemented on the server side and client side (as indicated by an arrow31inFIG. 3). Otherwise, in a step32, the version management module14present in version V2passes on the request to the version management module14corresponding to the older version V1, which now for its part activates the container start modules15(step30inFIG. 4or arrow31inFIG. 3).

The container start modules15now generate on the client side and server side one container instance16,17each of version V1or V2required by the respective application7a-7c(step33inFIG. 4, indicated by arrows34inFIG. 3).

In this case, at the start of the first application7a, the container instance17is started on the frontend side by the container start module15through the medium of the process connection module19(arrow35inFIG. 3). All subsequently started applications7band7cand their frontend-side container instances16are allocated an associated position in the common frame40or window created by the user interface18by the container instance17(arrow36inFIG. 3).

The screen output generated by the user interface18is shown by way of example and in schematically simplified form inFIG. 5. The common frame40is in this case shown by way of example in the style of an MS-Windows window. In the frame40the operating system processes running in parallel on the frontend side, which processes were created by the frontend layers9of the applications7ato7cwith the associated frontend-side container instances17and16, are each assigned an output field—shown by way of example in the style of a tab. To express it more graphically, a separate operating system process therefore runs in each tab. In the diagram according toFIG. 5, for example, the process assigned to the application7ais displayed in the foreground, while the processes assigned to the applications7band7crun in the background of the screen output.

By being displayed in the common frame the operating system processes assigned to the applications7a-7care represented as a single process. The user can therefore switch between these processes, for example by means of a mouse click, without noticing the process or application changeover.

Switching from process to process or, as the case may be, from application to application is effected by means of algorithms which the container instance17makes available within the scope of the user interface18.

As can be gathered fromFIG. 3, the process connection module19and the higher-order container instance17started by it also connect in particular processes that run on different versions V1, V2of the application platform5and/or use different protocol versions P1,P2. By this means it is ensured in particular that the output behavior of the applications7a-7cdoes not change fundamentally as a result of an update of the application platform5and partial performed migration of the applications7a-7crunning thereon. Rather, it is suggested to the user by the process connection module19that the applications7a-7coperate like a single process at least on the frontend side even after partial migration to the new version V2.

Still further, any one of the above-described and other example features of the present invention may be embodied in the form of an apparatus, method, system, computer program, non-transitory computer readable medium and non-transitory computer program product. For example, of the aforementioned methods may be embodied in the form of a system or device, including, but not limited to, any of the structure for performing the methodology illustrated in the drawings.

Even further, any of the aforementioned methods may be embodied in the form of a program. The program may be stored on a non-transitory computer readable medium and is adapted to perform any one of the aforementioned methods when run on a computer device (a device including a processor). Thus, the non-transitory storage medium or non-transitory computer readable medium, is adapted to store information and is adapted to interact with a data processing facility or computer device to execute the program of any of the above mentioned embodiments and/or to perform the method of any of the above mentioned embodiments.

The non-transitory computer readable medium or non-transitory storage medium may be a built-in medium installed inside a computer device main body or a removable non-transitory medium arranged so that it can be separated from the computer device main body. Examples of the built-in non-transitory medium include, but are not limited to, rewriteable non-volatile memories, such as ROMs and flash memories, and hard disks. Examples of the removable non-transitory medium include, but are not limited to, optical storage media such as CD-ROMs and DVDs; magneto-optical storage media, such as MOs; magnetism storage media, including but not limited to floppy disks (trademark), cassette tapes, and removable hard disks; media with a built-in rewriteable non-volatile memory, including but not limited to memory cards; and media with a built-in ROM, including but not limited to ROM cassettes; etc. Furthermore, various information regarding stored images, for example, property information, may be stored in any other form, or it may be provided in other ways.

LIST OF REFERENCE SIGNS