Online information delivery system including replicated sites from which information can be delivered

[0002] This invention relates to information delivery systems and methods and in particular to online delivery systems and methods, such as are used for delivering information over the World Wide Web (WWW) and which are to some degree fault tolerant so that information can still be made available despite a number of machines/processes being inoperable. The latter is a particular concern of the financial services industry.

[0003] According to one aspect of the present invention there is provided a system for delivering information from a site, including database means, over a communications network to remote users upon request, wherein the site is comprised of a plurality of sub-sites each accessible by a common network address and each including respective database means, server means, means for logging-in users and means for storing details of logged-in users, wherein each sub-site user details storage means stores details of all users logged in to the plurality of sub-sites, wherein the plurality of sub-site database means are content mirrored, and wherein the system includes means to connect a user to one of the sub-sites and, upon failure of a component or process of the one sub-site, to transfer a user logged-in thereat to another of the sub-sites where the respective user request is complied with without requiring the user to login, details of the user being available from the respective storage means.

[0004] According to another aspect of the present invention there is provided a method for use in delivering information from a site, including database means, over a communications network to remote users upon request, wherein the site is comprised of a plurality of sub-sites each accessible by a common network address and each including respective database means, the plurality of sub-site database means being content mirrored including the steps of

[0005] (a) upon a user request for information, connecting the user to one said sub-site, logging in the user thereat, and passing details of the logged in user to all said sub-sites for storage thereat

[0006] (b) upon component or process failure at a said sub-site to which a user is logged in, connecting the logged in user to another said sub-site and complying with the user request thereat without requiring the user to login at the other said sub-site, details of the user being obtained from the details stored at the other said sub-site.

[0007] Embodiments of the invention will now be described with reference to the accompanying drawings, in which:

[0008] FIG. 1 illustrates, schematically, a basic known information delivery system, and

[0009] FIG. 2 illustrates, also schematically, an embodiment of information delivery system according to the present invention.

[0010] In an example of information delivery system with which the present invention is concerned, and which is illustrated schematically in FIG. 1, a user 1 employs a Web network access software application 2 (browser), such as Netscape Navigator, to contact a particular Web site 3 via a network 4 which may be the Internet, an Intranet or similar. Information is freely available from many Web sites and those sites do not necessarily maintain any records as to the details of users. However, there are some sites, for example relating to the publishing of material online or the financial services industry, that provide information in a controlled way. In view of inbuilt access control systems, users only have access to information they are entitled to see, as a result, for example, of subscription or other previously arranged payment arrangements, and thus such sites can and do retain details of their users.

[0011] The Web site 3 illustrated in FIG. 1 employs an access control system which requires a user to login. The information held at this web site is stored as objects in an object database 5, such as ODB-II. When particular information is required by the user a respective page containing it is generated on the fly (on demand/dynamically) from the information stored in the database 5 and placed in a dynamically generated stream of HTML by a page daemon “paged” 6, provided the user has previously been authenticated by a login process performed by a login daemon “logind” 7. Typically a user is requested to supply a username and password to logind 7. In a particular system, which insists that all services are provided as part of a session, when the user has been authenticated he is given a session key, which is valid for a predetermined time, comprising, for example, a function of the name of the user, his password and a random number. This session key is encoded into the URL (Uniform Resource Locator) of the page concerned, so that the URL contains information about who the user is. All requests to the system must include a session key and an instruction. If a session key is found to be invalid, for example due to timeout or logout, as a result of the system checking invalidity at intervals, the user is requested to login again using a new session key. The original instruction will still be valid and is carried out as soon as the user is reauthenticated. An initial or home page is generally provided first and subsequently other content (pages) is served by a page daemon in response to user requests.

[0012] Each of the system daemons supports a set of command sequences (through its methods) and may also pass on commands (again through method calls) to objects outside of the daemon itself. The command sequences to daemons may be in the following format:

[0013] [type: class:] method/hashToken/OID/otherParams

[0014] type: The type of the method (instance or class) to be invoked.

[0015] class: The name of the class on which the method is to be invoked.

[0016] (The first two parameters are optional, and are used for methods not directly supported by a daemon process itself, hence they are indicated in brackets).

[0017] method: This is the system function being invoked. It might be a request to display a particular page, execute a search, or create a new user.

[0018] hashToken: An encrypted token identifying the user sessions.

[0019] OID: A unique identifier for the object to execute the method (not required for daemon or class level methods) eg the object ID of the target database object.

[0020] otherParams: a string containing any parameters specific to method.

[0021] As well as the daemons “paged” and “logind”, there is a session daemon “sessd” 9 which is responsible for updates to the session information.

[0022] It is possible to invoke executable programs on a Web server, such as 8, from Web browsers and view the resultant output through a mechanism known as a Common Gateway Interface (CGI). Executables and parameters are specified in a URL and can thus be embedded in Web pages, to be viewed by the user, as Hypertext Links to other pages. The purpose of the CGI script is to provide HTML to the server, which bundles it into HTTP packets and transmits it back to the browser, just as if it had read HTML from a flat HTML page. Hence whilst pages are generated on the fly they appears as if they were pre-existing.

[0023] The URLs basically consist of three components, which are the protocol used for communication, the machine (server) to be communicated with, or rather its IP (Internet Protocol) address, and the information file that is required, and are written in the form, for example, http://machine/file. In view of the login and session requirements referred to above, the system controls what users there are and is aware of what each user is doing. However, the user is tied to a particular machine. Hence if that machine fails, the user cannot obtain any information and for financial applications that is a particularly undesirable state of affairs. Thus rather than service being provided by a single machine, ie information is provided via a single Web server, it would be preferable if more than one machine were able to provide the same service.

[0024] As will be appreciated from the above, there are a number of programs/processes which are disposed behind the Web server 8. The daemon 6 performs the mapping from the database 5 to the format the Web server 8 understands and sends to the browser 2. The login daemon 7 attends to logging in and the generation of the session key, before passing a user off to the page daemon, which then performs the transaction or provides the information as required. It is possible to arrange that a page daemon can request the login daemon to reroute user requests to other page daemons on a different machine. This can be done automatically if the page daemon dies, or if the load on the current page daemon becomes too high. Such an arrangement is of no assistance if the login daemon fails, as it is only the login daemon that is aware of the user who has logged in.

[0025] Hence the replicated arrangement of FIG. 2 is proposed, where a single site is shown as effectively comprising three sites (sub-sites) together and has three servers 8a, 8b, 8c, three login daemons 7a, 7b, 7c, three page daemons 6a, 6b, 6c, three databases 5a, 5b, 5cand three session daemons 9a, 9b, 9c. Whilst three machines are illustrated this is not the only possibility. The number employed should be consistent with the number required to make the overall system sufficiently resilient for a particular application. As will be appreciated from FIG. 2, each session daemon 9a, b, cis in communication with all three, as illustrated, of the login daemons 7a, b, c. Content mirroring is employed to ensure that the databases 5a, b, call contain the same data and that the three sites are thus synchronised. Irrespective of which login daemon performs the login process, the session daemons of all three sites are advised the identity of the user of a session which has just been established, as a result of that information being broadcast to all of the session daemons 9a, b, c. Hence if a login daemon fails, such as 7a, a user can be logged in again by say login daemon 7b, since the associated session daemon 9bwill be aware of the identity of the user concerned. Similarly, if a page daemon fails, another page daemon can be brought into action, albeit in a different one of the three sites.

[0026] Since to the user there is only one site with which contact is to be made, and therefore only one IP address (“machine” of the URL as referred to above), whereas there are actually a plurality of sites (sub-sites) in the proposed replicated system, it is necessary to arrange that the same IP address can reach more than one site. Now, the IP address is actually a number which consists of four separate numbers, each somewhere in the range 000-256, separated by dots, and is referred to as a dotted quad, for example x.y.z.w. Since numbers are not particularly easy to remember, a domain name for a “machine” can alternatively be used. A domain name is a name which maps onto the IP number, this being achieved by a system such as the DNS (Domain Name Service) on the Internet. Hence the server with the IP number x.y.z.w. can also be referred to by the name www.icl.u, for example Similar mappings between “machine” numbers and names can be achieved in private networks.

[0027] The DNS mappings between name and number are only valid for a predetermined length of time and a web browser can only use a particular mapping while it is still valid. When it times out, the browser has to request the mapping again and generally it will not have changed, mappings typically being valid for say 3 hours. This is known as the time to live (TTL). Now, the DNS does have mechanisms whereby multiple IP addresses are possible ie www.icl.u may map to x.y.z.1, x.y.z.2, x.y.z.3, ie three separate servers at a particular site, and the DNS can randomly choose which server a browser is connected to when it first logs in. Hence with regard to FIG. 2, the site including server 8b may be chosen in the first instance. If something within that site fails then the user can be connected to another of the sites, since the session daemons all know the details of the user. However, in this case, with the multiple address facility it will be necessary to wait until the server to which the user was first connected times out. If the TTL is as long as is generally set, eg 3 hours, this is impractical. However, if the TTL is reduced to something sufficiently short, eg 30, 60, 90 seconds, then eventually the initially connected server will time out and the DNS will select a different one, say server 8c, which upon checking with its associated session daemon 9cto determine the user associated with the session key, will be able to continue with the requirements of that particular user since it already has his details.

[0028] Such a system is not fault tolerant, but it is tolerant to single points of failure. It is the domain name owner that determines which IP numbers correspond to a particular name, ie provides the mapping between them, and the domain name owner can define the TTL as appropriate for the type of transactions eg information retrieval, being performed. As to setting of the TTL, there is clearly a trade-off between the overall transaction time involved when users are being transferred between machines when there are no failures but the TTL expires, ie the desired operational characteristics of the system when there are no failures and the time they have to wait for reconnection when there is a failure. If the TTL is too long then a user will potentially have to wait a long time before they can continue a transaction.

[0029] As will be appreciated from the above, there is thus provided a system and method whereby a user can be connected to a different sub-site in the event of certain problems within a particular sub-site without the need for renewed login. Since the URL is itself unchanged, once the user has been connected to another sub-site, the file required, which is part of the URL, will be supplied without the user having to request it again. Whilst the invention has been particularly described in connection with object databases for data storage and creating pages on the fly in response to user requests, it is not to be considered as so restricted. The basic principle of replication of the site, to create similar sub-sites, is applicable to other data storage systems.