Method and system for deploying non-backward compatible server versions in a client/server computing environment

The present invention relates generally to computer systems in a client / server environment, and more specifically to the deployment of new versions of server software applications that do not require backward compatibility with client versions.

Client / server computing models implemented on networks have been adopted everywhere. In this model, queries issued by client node software applications are sent to one or more connected servers. When processed by the server, the queried information is returned to the client. This model is one of the Internet, where the client is a web browser and the server is a web server that includes a number of specialized servers such as mail servers.

This model generally serves as a community of clients, end users of software applications running on service provider computing resources, possibly through a combination of private and public networks, including the Internet. It is also one of many service providers that run. Examples of such providers include airlines, regular and online travel agencies (eg for travel planning and booking), and airports (eg for passenger departure control and check-in) throughout the travel industry. Global Distribution System (GDS), which provides travel services to Japan.

Software systems are generally updated frequently over their lifetime. Software applications continue to evolve to improve them by making modifications and adding new features when the system is up and running, even after the development phase is complete. You may also need to make changes to take full advantage of the performance of new types of machines, or because your operating system is new, evolved, or different.

In the client / server model, in order to roll out a new version of a server-side application, the standard technique is that the new version must be backward compatible. Therefore, no matter what version of the client application is used on any node, the new server will immediately process client queries and make the queried information compatible when deployed. Can be delivered in a certain format.

This ideal mechanism applies to some extent to the Internet, where web servers require compatibility with all existing web browsers used by the myriad of clients on the global public network. However, this is not entirely the case. It's well known that not all web browser brands work exactly the same, and that many servers actually only support the latest versions of client applications. For example, in the case of Internet Explorer (IE) by Microsoft Corporation, which is the most used in the world, many modern server applications currently only support version 5 (IE5) and above. In fact, older versions of browsers, or unsupported browser brands, can seriously compromise the client's graphic user interface (GUI) when receiving information from an upgraded server.

Maintaining backward compatibility is expensive, even though it can only be partially achieved in practice. New applications on the server must somehow address all options, features, incompatibilities, and flaws in all client versions supported in that area. This requires a lot of time and skill to develop new server applications, and in some cases requires more memory and faster hardware resources to be implemented, which is costly during the development phase. It takes. More importantly, the number of server / client browser combinations to check is an impossible number of resources for the testing phase to allow comprehensive testing of all combinations within a reasonable amount of time. It is increasing rapidly to the extent that maintenance of (machinery and human resources) may be required.

The above is true even if the web browser is a client called a "thin client". That is, this applies even to a client that actually executes only limited shared work between the server application and the client application when executing the requested job. In fact, the main task of a web browser is to display the pages returned by the web server through the GUI.

In the case of a publicly inaccessible client / server system, the client application is rather a server, similar to the GDS mentioned above, which generally works only with the relevant client (eg, airline, travel agency, airport, etc.). You may need to be a "rich client" who has to perform more of the entire work shared between you and the client. This may be necessary because the bandwidth available between them is too limited to allow client applications to ask for a server on a per-task basis. In the case of GDS, this is a client application system used at the airport to control passenger check-in, for example, when the aircraft departs and is a task that must be dealt with quickly when the passenger is on board. This is the case. In fact, small airports may still have limited external communication resources. In addition, airport computing resources are owned by the airport authorities, are under their control, require approval to be deployed and updated, and therefore check-in applications are used by airlines associated with GDS. Even if it does, it takes time.

Therefore, when a client application is a rich client designed to do most of its work on its own, the problem of having a backwards compatible server is due to the thin client, if not impossible. It can be even more difficult to achieve. In fact, the number of options and features for all versions of rich client applications supported is potentially very large, thus exacerbating the problems mentioned above regarding the development and testing stages of server applications.

US-A-5.732.275 discloses methods and equipment for managing and automatically updating software programs. This document does not address the issue of adapting all client software applications on the network before deploying a new backward incompatible version of the server software application. According to this prior art, it is assumed that the client application can automatically make a software version from shared memory. While this limits the scope of application of this technique, the present invention can be applied to networks containing significant dumb terminals with limited software resources.

WO01 / 69382A discloses a method for initial configuration of client devices. According to this gazette, a new template is downloaded to initially configure the client application. This template is intended to adapt the client application to a new format of data organization rather than a new version of the server software application itself.

Therefore, considering the above, it is desirable to enable the deployment of new versions of server applications that do not need to be backward compatible in a client / server environment.

Further objects, features, and advantages of the present invention will become apparent to those skilled in the art by considering the following description with reference to the accompanying drawings. All additional benefits are intended to be incorporated herein.

The above-mentioned problem of having to deploy a backward compatible server in a client / server networking environment is the introduction of a new backward incompatible version of the application server software program into the client / server networking environment. It is addressed by the present invention, which describes methods and systems for managing. The method is first compatible with a mode compatible with the current version of the application server, and a new backward incompatible version for client systems that are provided with a new backward incompatible version of the application server software program. It consists of the steps of distributing a client application that can operate in a compatible mode. Depending on the integration into the client system, the client application is set to downgrade mode, which is compatible with the current version of the application server. The client application continues to run in downgrade mode while the current version of the application server is still running. With the introduction of a new backward incompatible version of the application server, the client application is set to the enabled mode, which is compatible with the new version of the application server. From that point on, the client application operates in enabled mode. The mode setting is automatically triggered on every reboot of the client system that queries the version server running in the client / server networking environment. The query includes the identification of the client system and the version number of the client application in order to obtain a status value from the queried version server so that the client system operates in modes including downgrade mode and enable mode.

According to an additional but purely optional embodiment of the invention, the method is as follows. -The configuration step is automatically triggered on every reboot of the client system A step of querying a version server operating in a client / server networking environment, the query comprising identifying the client system and further including the version number of the client application. It further includes the step of getting a status value from the queried version server to operate the client system in modes including downgrade mode and enable mode. -The query further includes geographic location, user identification, and any kind of information about the client system to establish statistics. -Inquiry content is stored in the database of the version server. -The client system restart is forced by the service provider running the application server when a new backward incompatible version of the application server software program is run. -Client system restarts are automatically forced when a new backward incompatible version of the application server software program is loaded. -Client system restarts are automatically forced in the event of a fallback for a previous version. -The client application receives a status value from the version server to operate the client system in disabled mode. -The step to get is in the version server Includes a preceding step that checks the version number of the client application against the meta-rule and immediately declares that the client application older than the one specified by the meta-rule is invalid. -If the meta rule check is successful, Steps to check the version number of the client application against a set of compatibility rules, Steps to declare that a client application related to a compatibility rule is disabled, deprecated, or downgraded according to the content of the rule, Otherwise, it involves a step in which the client application, which is not involved in any compatibility rules, declares it valid. -The step to get is to deliver more patches to fix problems with one or more client applications. -Patches are applied dynamically each time the client system is rebooted. -Client application includes graphic user interface.

The present invention provides a new backward incompatible version of a software program for an application server within a client / server networking environment that includes a version server and a database, including means adapted to perform each step of the method. Also related to the system for managing the introduction to.

The present invention provides computer-readable methods for managing the deployment of new backward incompatible versions of application server software programs into a client / server networking environment for at least one computer to operate. It also relates to computer program products that are stored in computer-readable storage media with a variety of code means.

<figref num="1">FIG. 1 illustrates an exemplary system according to the invention based on GDS including a version server and database.</figref><figref num="2">Figure 2 is a high-level diagram of the major steps of the method at the client node that determines how the client application and GUI should behave depending on the running server version.</figref><figref num="3">Figure 3 discusses how the version server manages the status caused by the client system for which a query was issued at login.</figref><figref num="4">Figure 4 illustrates the online patching of client systems, which is an enhancement brought about by the use of version servers.</figref>

Refer to the accompanying drawings for a detailed description of the present invention below. Although the description includes exemplary embodiments, other embodiments are possible and modifications can be made to the embodiments described without departing from the spirit and scope of the invention.

FIG. 1 illustrates an exemplary system according to GDS (100) discussed in the background section of the invention. GDS or any equivalent system servicing through a network in a client / server environment should support a large number of remote client applications (120) (software applications running at the client level) and systems (122). In general, implement a server from a large amount of computing resources (110). In this particular embodiment used to illustrate the invention, the client system is an Airport Departure Control System (DCS), used, for example, when a passenger is on board an aircraft. Connections are maintained between servers and clients through wide area networks (WANs), optionally including any combination of private and public networks, including the Internet (130). All computing resources are interconnected, for example, with a private local area network or LAN (105). Similarly, a set of local client applications can be integrated through a LAN, such as an airport LAN (125), while multiple sets of independent client applications communicate with the GDS over a WAN (130). The interface with the client application is performed through the gateway (101) in this embodiment to allow the client to access all applications (109) provided by GDS, including the DCS application described herein. .. Such systems are generally expected to allow the client application to connect to to work with any of the legitimate and supported applications (109). Includes a logon and security server, or LSS (103) intended to ensure that authentication can be provided.

In this description, an application server software program means a software resource that is used at the application server level to perform its function. Unless explicitly stated, the term "application server application program software program" may be abbreviated to the term "application server" hereafter. In fact, the subject of the present invention is to manage software component versions, even if the server contains hardware components.

The present invention introduces a version server (105) that functions in conjunction with the database (107). As detailed in the discussion below, the role of the version server is to keep track of all client application versions (120) present in the region. In general, GDS and equivalent systems (100) will be able to interface thousands of remote client applications (120) over the global WAN (130). Client characteristics are stored in the database, which they are read by the version server as needed.

When backward compatibility of a server is not possible or becomes very expensive, the method of the invention first consists of deploying an upgraded version of the client application and GUI to all remote clients. This includes making the new version of the client application compatible with both the current version of the server and the newer version, that is, everything. With such a mechanism, the new server does not need to be compatible with older client applications and GUIs when incorporated.

As a result of the above measures, during the deployment phase (full deployment can generally take weeks to complete in a network with thousands of client nodes), when new client applications are deployed , Downgraded to server version N, ie to the current version in operation. Its status is changed to "Downgrade to version N" in the database (107) of the version server (105) accordingly. Therefore, during the interim period when the client application is deployed within the client node, that of the already upgraded node will use version N, which is compatible with the current server, systematically, that is, every time the client is restarted. doing.

When the distribution is complete or nearly complete, the server system, eg GDS (100) in Figure 1, will initiate all or at least most of the end users to take advantage of the upgraded client / server features and features. You can decide to promote the new server so that you can. Promotion can be done manually by the system administrator or can be triggered automatically when the software is loaded. In this case, the version server has the status of the remote client node "enabled" in the database so that it can run the next version of the server (N + 1) and the client application and GUI can also run at the N + 1 level. You will be instructed to change to. To achieve this, the version server forces disconnection of all sessions using version N (and older versions, if any). To do this, the version server sends a sign-out message to each client remote node to terminate the user session and ask for a restart of the client application and GUI. Then, on the next reboot, version N + 1 will be used automatically, as further discussed in the following description of the invention. It should be noted here that the GDS service provider system has the freedom to control a small number or a large number of client nodes through the version server as needed. Only client nodes that involve a particular upgrade need to be restarted. Upgrades, downgrades (eg, for fallbacks with respect to previous versions), and version blocking (if the current version is incompatible) can be performed with a variety of very different levels of fineness. This can range from the world, territories, countries, cities, airports to any identifiable location within the airport, such as specific terminals, boarding gates, offices, etc., and therefore considerable to new client versions.

Figure 2 illustrates the key steps in the client node method of determining how a client application and GUI should behave depending on the running server version.

The process runs every time the client application (210) is restarted. Transactions are initiated by the client application at login (212) to read the version details (214) of the client application used from the version server and database (220). Queries automatically sent by the client application to the version server must include the ID of the client node, including the application identification (ID) in use, and its version number.

In a preferred embodiment of the invention, the query must include more information about the client, including: It doesn't become. -User identification, -User's office, for example: LONLH033, Lufthansa (LH) agency in London, -User location, eg: LHR / T2 / GTE / 20, for Gate 20 in Terminal 2 at London Heathrow Airport. -User's organization, for example: airline name LH, -Other.

In any case, the information provided to the logon and security server (LSS) (103) shown in Figure 1 as part of the authentication is provided to be recognized as a legitimate user of the application server.

Therefore, what is provided in the client application query (212) is to obtain very important information about the deployment of new application versions in that area and, in general, the characteristics of the group of client applications that interface with the application server. Can be used for. For example, GDS can establish a list of locations around the world that are using a version of a client application, or can detect locations that are still using a very old version. The information provided by the client application is collected in a database and can be used by any kind of program running from the management center responsible for monitoring and managing large groups of remote client nodes.

The version server (220) continues to maintain a status list of client applications and GUIs in use on all client nodes. The status is then returned to each client system at login, based on knowing the version of the currently running application server and, as mentioned above, the information provided by the client node in the query (214). The status can capture one of the following values:

Enabled: The status of the last downloaded version (N + 1) of the client application and GUI. This is the normal status after a new client application is deployed and corresponds to the new version of the server you have run. Deprecated: Indicates that the client application and GUI are older versions but compatible with the current production server. This status is used when newer versions of the GUI are available, but older deployed GUIs are currently compatible with the server. Optionally, a warning message is displayed to the end user at login, depending on the client configuration. Downgrade to version N: Version N + 1 of the newly deployed client application and GUI must act as version N (while the new client application and GUI are distributed before running the corresponding new server). (It has been done). As mentioned above, this status is primarily used to allow you to manage the startup of backwards incompatible servers. It may also be used to manage server fallback (to a previous version), as described below. Disabled: Indicates that the client application and GUI are older versions that are incompatible with the current production server. The end user of the client node receives a warning notification at login and is usually blocked.

The above status values are translated by the client system (216) to operate according to the version of the running application server. After that, a normal transaction (218) can be performed between the client application in charge of those processes and the application server (230).

If for some reason there is a problem with the promoted application server and it must be removed, there must be a fallback for the previous version. Therefore, new client applications and GUIs that have already been downloaded will be returned to a "downgrade" status to resume operation compatible with previous server versions, as during the interim period during which deployment was in progress. Must be set. If some client systems were still using previous versions of the client application and GUI, their status would be reversed from "deprecated" to "enabled".

Figure 3 discusses how the version server manages the status caused by the client system for which a query was issued at login.

The process begins with the client application and GUI version (310) provided for queries issued by the client system to the version server. To determine the status returned when queried by the client system, the version server uses the (340) compatibility rules that are checked for each of the provided client versions (310), which version of the application Know if it is up and running. However, in order to avoid the expansion of compatibility rules, there is a client version pre-check (320) for meta-rules. Meta-rules are used to directly exclude all version numbers older than a given value. There is one meta-rule per client application. Therefore, if the meta-rule check fails (331), an "invalid status" is returned directly (352). On the other hand, if the client version passes the meta-rule check (332), it is necessary to check the compatibility rule (340). Compatibility rules are all incompatible between a running server and a particular client system, so that everything related to the rule is ultimately declared valid (380). Track the status of. Otherwise, the client systems involved in the rules are "invalid" (350), "deprecated" (360), or "downgraded" (370), depending on the content of the rules that apply to them. Is declared.

Figure 4 illustrates online patching of client systems, an extension brought about by the use of version servers.

The use of version servers is especially useful in large networks involving a large number of client systems, which may involve thousands or tens of thousands of client nodes. Therefore, deploying a new client application is a cumbersome and time-consuming task that typically takes weeks to complete. Since remote sites may not be under the direct control of service providers, such as the GDS used to demonstrate the invention, for example those responsible for airport authorities may in fact adversely affect their systems. You may dislike embedding new versions of your application. The fallback mechanism supported by the present invention is one answer to this concern, allowing reversion to previous versions of the server in case of serious problems. The version server according to the invention implements further functional enhancements to avoid problems that may be found at some point during the deployment of the client application or after it has been achieved. It can be so.

If a major blocking issue is found in a version (410) of a client application that is already globally adopted, the version server (420) will now resolve the issue without having to redistribute the entire client application. , Can provide patches that are part of the code. To do this, a patch is added to the response when the version server responds to the query (412) that was automatically sent when the remote client system logged in, as already described in Figure 2. .. Based on the version number and application name provided in the query, the version server recognizes that the version of the client application has a functional problem. The response sent by the version server then contains the status already discussed and the patch for the functional issue (414). Upon receiving the server response, the client application changes its behavior according to the version status and patches itself (416). The patch is not permanently stored or embedded in the client application machine and is applied each time the client application is restarted. Normal transactions (418) can then be resumed between the client application responsible for them and the application server (430). This mode of operation will continue until a new version is redistributed.