Distributed session services

[0001] This application claims the benefit of U.S. Provisional Application No. 60/158,733, filed Oct. 11, 1999.

[0002] 1. Field of the Invention

[0003] The present invention relates generally to computer communication systems, and more specifically to a method and system for managing session level services over a complex Internet service application.

[0004] 2. Description of the Prior Art

[0005] Use of publicly available communication systems such as the Internet is currently increasing at a rapid rate. Many companies find it extremely valuable to be able to provide information to customers and other entities over such communication systems. In particular, web pages are made publicly available, and typically accessed by widely available browsers.

[0006] Because a large number of people may wish to access a company's information simultaneously, it is becoming more common to provide a bank of web servers that can operate in parallel. Each web server has access to the underlying corporate information as is well known in the art, and each can handle a number of sessions simultaneously.

[0007] Each connection between a remote browser and the underlying system can be termed a session. A session is, generally, a series of requests from a browser to a web system that make up an interaction with the characteristics of a conversation. The system retains data as the interaction continues (known as session data) that enables the system to remember what has been done in earlier stages of the interaction. Use of sessions is known to those skilled in the art. The web hosting system, containing several web servers in parallel, maintains information on each of these sessions in order to provide appropriate communications with the remote browser.

[0008] An example of a system which uses a bank of web servers in this matter is described in detail in U.S. Pat. No. 6,076,108, issued to Courts et al., and assigned to i2 Technologies, Inc. The method and system set forth in this patent utilizes a global session server (GSS), which maintains information on all of the sessions currently running on the host system. A single session server, or a bank of such session servers, are used to provide session information to each workstation so that a proper response can be made to request by remote browsers.

[0009] Some systems have a drawback in that under heavy loads it is difficult to maintain a high level of performance. Also, the system described therein is not as fault tolerant as might be desired.

[0010] It would be desirable to provide an improved system and method for providing session services for a bank of web servers that is both very fast, and provides a high level of fault tolerant to insure a high level of system availability.

[0011] In accordance with the present invention, a remote session server, or bank of remote session servers, is provided to a bank of web servers. Each web server maintains a cache that contains all of the session information for all sessions being serviced by that server. The web server utilizes its local cache to perform all session services. The remote session server maintains a copy of all session information from all caches, and is updated whenever changes are made on each web server. If a web server should go down, an ongoing session can be transferred to a different web server. In such event, the new web server is able to obtain the previous status of the session from the remote web server and continues serving the session in a transparent manner.

[0017] The system and method of the present invention is an improvement to the global session server described in detail in U.S. Pat. No. 6,076,108. However, it will be understood by those skilled in the art that the described technique for providing a remote session server can be adapted to any system using a plurality of web servers to handle Internet or similar communications.

[0018] The information stored for each session will be implementation dependent, and is known by those skilled in the art. For example, session data can typically include information such as the user profile, status of the session, history of events in the session, and particular information pertinent to the session such as an identification of items in a shopping cart for purchases being made by the remote user. Identification and maintenance of such information is well known by those skilled in the art, and will not be described further herein.

[0019] Referring to FIG. 1, a host system designated generally as reference number 10 includes a plurality of web servers 12, 14, 16, 18, 20, 22. A browser connect 24 connects to one of the web servers 12–22 over an internet connection 26 which is routed through a local director 28. As known in the art, local director 28 directs all communications from incoming IP addresses to selected servers 12–22. This may be through the use of a table, or other algorithm, that distributes communications with connected IP addresses to particular web servers 12–22. Local director 28 functions to keep a specific browser connected to a specific web server to optimize access to a session for normal operation.

[0020] In prior art systems, as exemplified by U.S. Pat. No. 6,076,108, each web server 12–22 communicates with a separate global session server that contains all session information. When an event occurs which requires access to such session information, such as display of a web page requested by a browser 24, access must be made to the global session server. However, in the preferred technique, each web server 12–22 maintains all of its session service information on the same hardware system that provides the remaining web services.

[0021] Referring to FIG. 2, a remote session server 30 is provided which communicates with all of the web servers 12–22. Remote session server 30 is provided to keep track of, and maintain a backup for, all of the session information on each of workstations 12–22.

[0022] Referring to FIG. 3, workstation 12 is illustrated in more detail. Contained within workstation 12 is a session server cache 32, which contains all of the session ID's (SID) 34 which are being handled by web server 12. For each session ID 34, all session data 36 which is maintained on behalf of the web server is maintained within session cache 32. Thus, when a request is made by a particular session, web server 12–22 contained locally all information needed to respond to the request. It is not necessary to obtain session information from any remote location.

[0023] However, whenever session information within cache 32 is updated by any web server, a copy of such update is communicated to remote session server 30. Thus, remote session server 30 contains a complete set of all session information for all sessions on all web servers.

[0024] If a particular web server should go down, all sessions on that web server must be handled elsewhere. When a web server goes down, local director 28 becomes aware of that fact and re-routes sessions, based upon IP addresses, to alternate web servers. When sessions that were connected to the failed web server make subsequent requests, their session data is retrieved by the alternate servers from the remote session server. If a web server goes down, changes to the session will be lost if the web server goes down before those changes have been updated in the remote server. In that case, the session will be available on the alternate server, but the session will not be completely current.

[0025] For example, assume web server 16 goes down while running 100 simultaneous sessions. At the time web server 16 goes down, a complete copy of its session cache 32 was stored on remote session server 30. Some recent information may be lost if the crash of web server 16 prevents the last few cache updates being written to remote session server 30, but all sessions should otherwise be reasonably current.

[0026] Using whatever algorithm is implemented in local director 28, all of the sessions that were on web server 16 are re-routed to one of the other web servers the next time a communication is received. In some systems, a standby web server can be used; in others already operating web servers will take over the load from the system that went down. In either event, when local director 18 routes an interrupted session to a new web server, for example web server 12, the web server is initially unprepared to handle the transferred session.

[0027] Before responding to the transferred session the first time, web server 12 obtains from remote session server 30 a copy of the session information for the transferred SID. Once this data is transferred from remote session server 30, workstation 12 is ready to manage the session from the point at which workstation left it.

[0028] In the system shown in the Figures, if remote session server 30 goes down, all of the web servers 12–22 continue functioning. In other words, the remote session server 30 is not a single failure point that will bring down the entire system. Once remote session server 30 is brought back up, all of the web servers 12–22, which have been handling their sessions properly in the meantime, will update all of their changed sessions to remote session server 30. In the scheme shown in FIG. 2, if a web server should go down while remote session server 30 is unavailable, the current status of all sessions on that web server will be lost. In order to provide addition robustness to the system, remote session server 30 can be implemented as a bank of separate machines.

[0029] Referring to FIG. 4, remote session server 30 is actually composed of two separate pieces of hardware, servers 38, 40. Each workstation 12–22 maintains an identifier indicating which RSS 38, 40 maintains its session data backups. If an RSS 38, 40 used by a particular workstation should go down, that workstation connects to another RSS within the bank making up remote session server 30, and provides it a complete copy of its session information cache 32. In this manner, all sessions are properly handled even if problems should be encountered in one or more web servers, and one or more servers in the remote session server bank 30, simultaneously.

[0030] When a workstation goes down, and a session its moved to a new workstation, the new workstation will need to poll the individual machines within the remote session server 30 in order to determine which one has that session data. Once the proper machine is found, the new workstation downloads the session data and continues as described above.

[0031] Within each workstation, it is possible for multiple updates to be attempted to the data for a single session. For example, if two frames for a session try to update at the same time, the remote session server 30 is not updated until both updates are made. By locking the data for a particular SID whenever an update is made, multiple updates will be automatically serialized. If an attempt is made to obtain a lock to update session information, and that session is already locked, the update will be retained in a queue until the previous update is completed. Only when all pending updates for a particular SID have been made will the corresponding session information be transferred from the workstation to the remote session server 30 to provide the remote update.

[0032] The described system and method provides for a bank of web servers that provide excellent performance because all of the session information needed by each server is maintained locally. In addition, by backing up the local information cache to a remote session server, a session is maintained even if its hosting web server should go down. By providing a bank of remote session servers, even a failure of one of the machines in the remote session server bank will not terminate a session.

[0033] While the invention has been particularly shown and described with reference to a preferred embodiment, it will be understood by those skilled in the art that various changes in form and detail may be made therein without departing from the spirit and scope of the invention.