WO2009098430A1

WO2009098430A1 - Information access system

Info

Publication number: WO2009098430A1
Application number: PCT/GB2008/000455
Authority: WO
Inventors: Rajen Manani; Simon Howe; Nilesh Gharat
Original assignee: British Telecommunications Public Limited Company
Priority date: 2008-02-08
Filing date: 2008-02-08
Publication date: 2009-08-13
Also published as: GB2459249A; GB0804993D0

Abstract

A system for providing access to an information system comprising a plurality of instances (102,104); in which the system for providing access comprises: an input for receiving requests from a user (22) for access to the information system; in which each request is associated with a session; a request processor arranged in use to identify the session to which each request belongs and arranged in use to operate in two states: in a first state, prior to initiation of a transition, the request processor is arranged to forward to the first instance (102) each request that is the first request in a session; in a second state, following initiation of a transition, the request processor is arranged to forward to the second instance (104) each request that is the first request in a session. The system for providing access may also, in the first state, forward to the first instance (102) each request associated with a session for which a request has previously been forwarded to the first instance (102); and forward to the second instance (104) each request associated with a session for which a user request has previously been forwarded to the second instance (104). The system for providing access may also, in the second state, forward to the second instance (104) each request associated with a session for which a user request has previously been forwarded to the second instance (104) while continuing to forward to the first instance (102) each request associated with a session for which a request has previously been forwarded to the first instance (102).

Description

INFORMATION ACCESS SYSTEM

The invention is directed to the field of information systems in general and is in particular associated with improving access to information systems.

Since the 1990's, businesses have been embracing the internet to expose their internal systems, sales and support services as a self-service offering to customers. This has provided an electronic channel to market in which the services exposed are expected by the customers to be online 24x7. This is a high benchmark to achieve, particularly when dependent on large IT systems comprising software packages and applications which rely on downtime (system outages which disables services) for maintenance. IT Systems availability is usually measured by planned and unplanned downtime. Electronic self service systems exposed over the internet such as electronic banking, electronic billing, e-commerce websites, business to business gateways all suffer from downtime caused by both planned and unplanned outages. System maintenance, such as system upgrades and software/application releases still require system downtime involving a temporary loss of service. System maintenance may also provide for "rollback" to an earlier state in the event of a failure in the software upgrade / application release.

The negative effects of these outages include non-tangible effects such as "customer experience" and "customer perception" but also hard financial effects - for example downtime on a commercial internet site has an immediate financial impact due to increased calls to customer service contact centres (sometimes referred as "call centres") where the handling cost of a transaction is significantly higher than the same transaction handled via the internet channel. Furthermore, it is becoming more common for lower cost consumer and business self-service products and services only to be offered through the internet channel (with no customer service contact centre) -meaning, that the availability of the on-line systems is a key factor in managing customer expectations.

When a user generates a request for information held on a website, this request is communicated in the form of one or more packets containing the URI (e.g. www.web site.com) of the desired information source (i.e. the website). According to standard Internet practice, these packets are routed to a domain name server (DNS) where the embedded URI is mapped to a destination IP address (e.g. 111.222.111.222) which is added to the packet header. The packets tagged with the destination IP address are then routed to the desired destination (if available). A user's browser will often temporarily store the mapping in a cache to reduce DNS traffic and avoid having to consult the DNS on each subsequent access to the same website. This caching can result in a user continuing to attempt to access a website via a first address even after the website administrator has changed the IP address of the website (re-programmed the DNS) to a second address. In such a situation, the URI is not uniquely defined but points to different IP addresses for different users. This is a temporary phenomenon as each cached mapping will be associated with a time to live (TTL). On expiry of the TTL, a fresh reference is made to the DNS at which point, the new IP address will be obtained. Individual user settings dictate the lifetime of the cached mappings outside of the control of the administrator. As a result, neither the administrator nor any of the users will know what versions of the website are being accessed by what users.

Over the last few years with the increase in electronic services, there has been a focus on providing a high availability infrastructure service to support the increased demand in 24x7 global operations via websites. The demand for high availability requires an end-to- end view of IT systems availability typically across a multi-tier architecture which spans multiple physical servers and separate components. For example, with reference to Figure 1 , such components can include, firewalls 12, traffic management servers 14, web servers 16, application servers 18, integration servers and database servers 20.

Typically, high availability engineering within a systems architecture focuses on hardware and software clustering and IP protocol load balancing capabilities. However, such architectures are designed to maintain service-availability as a running system - they are not intended to provide high availability during system maintenance.

A number of products on the market support traffic management activities, such as HTTP load balancing and HTTP traffic manipulation. Such products include the Cisco ACE, the Cisco CSM and the Zeus Extensible Traffic Manager (referred to from hereon as ZXTM). However, these products do not remove the need for planned downtime. The above references to the prior art are given for the purposes of providing background to the present invention and are not to be taken as an indication that the content of the cited prior art documents constitutes common general knowledge.

There is a need for capabilities that may be implemented via, although not limited to, traffic management products such as those outlined above that are suitable for reducing downtime of a website or similar service during software or application upgrade or other causes of downtime.

The invention provides a method of accessing an information system comprising a plurality of instances, in which the method includes: receiving user requests; identifying a session associated with each request; forwarding each request that is the first request of a session to a first instance; initiating a transition to a second instance and where a request is received following initiation of the transition: forwarding each request that is the first request of a session to the second instance.

The method may include, following initiation of the transition, forwarding to the second instance requests associated with a session for which a request has previously been forwarded to the second instance while continuing to forward to the first instance requests associated with a session for which a request has previously been forwarded to the first instance.

The method may further include, prior to initiation of the transition, forwarding to the second instance requests associated with a session for which a request has previously been forwarded to the second instance and forwarding to the first instance requests associated with a session for which a request has previously been forwarded to the first instance.

In one aspect of the invention, the method includes reading a HTTP request forming a part of the request and deciding, based on the HTTP request, which of the first and second instances to forward a request to. In a further aspect, the method includes reading a flag inserted in the request by an administrative user and modifying the forwarding based on the flag to allow the administrative user to determine the destination for the request.

In a further aspect, the method includes, following initiation of the transition, restricting the forwarding of requests to the first instance to a set time period from the start of the transition.

The invention also provides a system for providing access to an information system in which the information system comprises a plurality of instances; in which the system comprises: an input for receiving requests from a user for access to the information system; in which each request is associated with a session; a request processor arranged in use to identify the session to which each request belongs and arranged in use to operate in two states: in a first state, prior to initiation of a transition, the request processor is arranged to forward to the first instance each request that is the first request in a session; in a second, state, following initiation of a transition, the request processor is arranged to forward to the second instance each request that is the first request in a session.

In one aspect of the invention, in the first state, the request processor is arranged to forward to the first instance each request associated with a session for which a request has previously been forwarded to the first instance; and to forward to the second instance each request associated with a session for which a user request has previously been forwarded to the second instance.

In a further aspect of the invention, in the second state, the request processor is arranged to forward to the second instance each request associated with a session for which a user request has previously been forwarded to the second instance while continuing to forward to the first instance each request associated with a session for which a request has previously been forwarded to the first instance.

In a further aspect of the invention, the system comprises a default indicator for indicating a default instance from among the plurality of instances. In a further aspect of the invention, the system comprises a plurality of specific indicators, one per instance, each specific indicator for indicating an address of a specific one of the plurality of instances in which the default indicator indicates the specific indicator for the default instance.

In a further aspect of the invention in a third state, following initiation of a second transition, the request processor is arranged to forward to a third instance each request that is the first request in a session. In a further aspect of the invention in a third state, following initiation of a second transition, the request processor is arranged to forward to the first instance each request that is the first request in a session.

In a further aspect of the invention, in the third state, the request processor is arranged to forward to the first instance each request associated with a session for which a request has previously been forwarded to the first instance; to forward to the second instance each request associated with a session for which a user request has previously been forwarded to the second instance; and; to forward to the third instance each request associated with a session for which a user request has previously been forwarded to the third instance.

To aid understanding of the invention, embodiments will now be described by way of example only, with reference to the accompanying drawings in which:

Figure 1 shows a schematic of a conventional web-based IT system;

Figures 2 shows a schematic outlining a process associated with providing minimum downtime for web-based IT systems according to an embodiment of the present invention;

Figures 3, 4 and 5 show schematics with signal flows according to an embodiment of the invention;

Figure 6 shows a schematic with signal flows according to a further embodiment of the invention; Figure 7 illustrates an example of a transitioning request rule according to an embodiment of the invention;

Figure 8 illustrates an example of a transitioning response rule according to an embodiment of the invention;

Figure 9 illustrates an example of an access request rule according to an embodiment of the invention;

Figure 10 is a schematic of a server for implementing the invention.

We now describe in more detail embodiments of the invention using by way of example the Zeus ZXTM traffic manager which is a highly available (i.e. achieves high availability through high reliability), application-centric traffic management and load balancing product available from Zeus Technology Ltd of Mountain View CA 94043, USA. Alternative embodiments of the invention are also envisaged using other traffic managers such as a Cisco ACE, Cisco CSS or F5 traffic manager available from Cisco Systems, Inc. of San Jose, CA 95134, USA. In a further alternative embodiment, the required traffic management functionality could be built as a custom application.

Overview

Figure 2 outlines system components and signal flows associated with providing a web- based IT system (typically embodied in the form of an internet-facing website) exhibiting minimum downtime through a process called "transitioning".

Customer 22 generates a request for information, which is communicated as packets to a DNS (not shown) for mapping to a destination IP address. According to the present embodiment, the URI carried in the information request packets is mapped to the IP address of traffic manager server 14, to which the packets are subsequently routed.

The system for providing access to information held on a source of information such as a website, may be considered as comprised of multiple architectural tiers and, in this embodiment, we assume a 3 tier system architecture which includes components classified by tier, as shown in Figure 2 and described in the following. The website exists in more than one instance or "generation". In the embodiment of Figure 2, two instances 102, 104 exist in parallel, although the skilled reader would appreciate that the invention is equally applicable to systems with more than two instances of an information source.

Tier 1 : Traffic Manager Tier

Traffic management tier 14 involves the following sub-systems, typically provided by the traffic manager product:

• Traffic Pools - first pool 32, second pool 34 - are used to control access to alternative web server instances where a web server instance corresponds to a website "generation". Each of these traffic pools comprises one or more pointers: each pointer indicating a destination. More than one pointer is included per traffic pool if there is more than one server per web instance (e.g. as may be desirable in order to provide the opportunity for load-balancing within a web instance). In the present embodiment, each of these traffic pools corresponds to a web server - first pool 32 corresponds to first web server 36, second pool 34 corresponds to second web server 38 - and each traffic pool points to one or more servers corresponding to a different one of the available web servers; • According to a preferred embodiment, each pointer comprises a network IP address of a destination server;

• Virtual server 26 processes incoming network traffic. According to an embodiment, virtual server 26 comprises multiple virtual servers configured to manage traffic for different websites. The following are also configured within virtual server 26:

o Selector pool 30 - each virtual server has a selector pool. This pool determines the destination that general traffic for the website will be routed to unless a rule decides otherwise. In this regard, the selector pool points to one or other of the traffic pools 32, 34.

o Instance Access Rules 28 are applied by virtual server 26. A domain access rule can read the headers on a packet or the whole packet and, from the information obtained, it can select from a number of options: it can select a pool to send the packet to, close the connection or pass the packet on to a further rule.

One or more traffic manager virtual servers 26 may be deployed into a data centre within a high availability traffic manager cluster (not shown). Traffic manager tier 1 manages internet requests received from customer 22 for HTTP and HTTPS protocols. The received HTTP customer requests are handled by the traffic manager virtual server 26.

Typically, access to a website is via a DNS record (typically A-record or CNAME aliases). According to an embodiment, a number of DNS records are registered for each website to provide access to the "current generation" and "next generation" of the website. For example:

• www.web site.com relates to a public DNS record used by end customer 22; this DNS record always routes customers to the appropriate (current or next) generation of the website via selector pool 30;

• www.A1.web site.com relates to a private DNS record used by internal support staff 24; this DNS record always routes staff to the "current generation" of the website i.e. bypassing selector pool 30;

• www.A2.web site.com relates to an alternative private DNS record used by internal support staff 24; this DNS record always routes staff to the "next generation" of the website i.e. also bypassing selector pool 30.

Tier 2: Web Server Tier

Web server tier 16 comprises one or more web servers 36, 38 deployed into a data centre (not shown) and, optionally, co-located and/or co-hosted with tier 1 within a resilient configuration. Web servers 36, 38 may be implemented using SUN Java Web Server or OpenSource based Apache Web Server, as examples. The present embodiment will be described further with reference to a SUN Java Web Server available from Sun Microsystems, Santa Clara, CA 95054, USA. The SUN Java Web Server demonstrates flexibility in creating "classes" of configuration known as "virtual server classes". A virtual server class enables a group of virtual servers to abide to a common set of configuration and setup parameters within the SUNONE Java Web Server implementation. A virtual server class can, for example, specify the default document root (i.e., the location where static media artefacts are hosted) of a group of virtual servers. According to an embodiment, the virtual server class offers separation of "current generation" and "next generation" web server document root areas.

First web server 36 in Figure 2 is configured to route received HTTP customer requests to the "current generation" of the website artefacts (first website content 40). Artefacts here are typically static content media files such as html, jpg, gif, doc files hosted in a logical directory structure upon web server tier 16, for example, /docroot_web01/www. These artefacts are usually hosted via some shared storage such as NAS via NFS or CIFS protocols.

In addition to such artefacts, web server tier 16 is configured with a plugin (such as the BEA Weblogic server plugin - not shown) to enable requests to be routed to the "current generation" of the website application hosted within an application server in application server tier 18, such as a BEA Weblogic domain. The Weblogic server plugin enables requests from first web server 36 to be routed to the "current generation" of the website application hosted on first Weblogic domain 44 in application server tier 18

Analogous to first web server 36, second web server 38 is configured to route received HTTP customer requests to the "next generation" of the website artefacts (second website content 42). In addition, the Weblogic server plugin enables requests to be routed to the "next generation" of the website application hosted on second Weblogic domain 46 in application server tier 18.

Tier 3: Application Server Tier

Application server tier 18 is used to host the dynamic runtime component of a website that complements the static content hosted by web server tier 16. To achieve high availability, several application servers may be deployed into a data centre to form a cluster (multiple instances of an application server - not shown). According to an embodiment, application server tier 18 is Java J2EE or J2SE compliant as defined by Sun Microsystems Inc. The present embodiment will be described with reference to BEA Weblogic server (available from BEA Systems, Inc., San Jose, CA 95131 , USA) as the application server, however alternatives include Apache Tomcat (available from the Apache Software Foundation, Forest Hill, MD 21050-2747, U.S.A.or JBOSS (available from Red Hat Inc., Raleigh, North Carolina, USA). Multiple BEA Weblogic server instances (also known as "managed servers") are grouped together via a Weblogic domain (an administration unit for Weblogic server instances) and typically arranged into clustered managed servers which can be managed via a single administration server.

A website developed in Java technologies usually comprises of one or more web- applications (webapps). A web-application offers a discrete self-contained functional capability exposed via a URI within a website and accessed by end users through a browser (or thin client). A web-application uses the services offered by the application server for example to access databases through an API defining client access to the database, such as Java database connectivity (JDBC).

In Figure 2 this application server is identified as first Weblogic domain 44. The BEA plugin is a small software program that may be used to extend a WebLogic server implementation to other servers by supporting communication with applications deployed on Apache HTTP Server, Netscape Enterprise Server or Microsoft's Internet Information Server. The plugin configuration lists the BEA managed servers available (in other, equivalent, application server products these are generically referred to as Java virtual machines).

According to the present embodiment, web-applications are deployed into two Weblogic domains, although more domains could be employed. First Weblogic domain 44 hosts the "current generation" of web-application 48 whilst second Weblogic domain 46 hosts the "next generation" of web-application 50. This Weblogic domain-level segregation offers the ability to host a different instance of BEA Weblogic server product and separate software configurations for each generation of the website to support varying requirements across application generations.

Transitioning Operation of the system, described above, will now be described in more detail with reference to Figures 3, 4 and 5. Figures 3, 4 and 5 show signal flows across traffic management tier 14, web server tier 16 and application server tier 18. According to an embodiment, access rules have been set up in virtual server 26 to enable website transitioning. These additional rules offer two key pieces of functionality:

1. Gracefully transitioning of users from one instance of the website ("current generation") to another ("next generation") without disruption to existing user sessions. This is referred to as "dual instance transitioning".

2. Allowing support teams to access selected ones of the multiple instances of the website through a private access control path. This is referred to as "instance access".

To implement dual instance transitioning, two individual access rules are required, as follows:

• Instance Transitioning Request Rule 28a examines the HTTP/HTTPS request received from the user (e.g. customer 22); and

• Instance Transitioning Response Rule 28b examines the HTTP response from the website (tiers 16, 18) to the user.

Figure 3 shows customer 22 requesting access to the website at (1 ). As described, above, two different instances 102, 104 of the website are deployed. First instance 102 of the website comprises first web server 36 together with first application server 44.

Second instance 104 of the website comprises second web server 38 together with second application server 46. Virtual server 26 for the website comprises selector pool

30 which in this embodiment is set to direct requests to first pool 32 (thus indicating first instance 102 of the website).

According to this embodiment, the first request that customer 22 makes, see (1 ), will be routed to virtual server 26 for the website. Within virtual server 26, a request rule (instance transitioning request rule 28a) examines the request to detect if customer 22 has previously accessed the website and, if so, which instance (i.e. which web/application servers) they used (this is identified through a cookie which is written to the customer's browser on first accessing the website, as detailed, below). For a first request no cookie will be present in the request and rule 28a will pass the traffic to selector pool 30. Selector pool 30 then routes the traffic to first website instance 102, i.e. first web server 36 and first application server 48. This is shown by the sequence of solid arrows in the figure.

When web and application servers 36, 44 respond to this first request, the traffic is routed back to virtual server 26 en-route to customer 22 (as shown by the sequence of broken-line arrows in the figure). In virtual server 26, this response is intercepted and a second rule (instance transitioning response rule 28b) applied. Instance transitioning response rule 28b checks to see which instance of the website customer 22 has just accessed and then writes cookie 60 recording the appropriate website instance for the browser used by customer 22.

The handling of subsequent requests will now be described with reference to Figure 4. When customer 22 makes a subsequent request to access the website, instance transitioning request rule 28a is activated once more. This time the rule detects cookie 60 included with the customer's request and determines that customer 22 has a history of accessing the website and then reads from the cookie the instance of the website that customer 22 has accessed. As shown in Figure 4, the customer's request is then directed to the pool specific to the website instance that they previously accessed, bypassing selector pool 30. In this case the request is directed to first pool 32, indicating first website instance 102 (as shown by the sequence of solid arrows in the figure).

The response from web and application servers 36, 44 is treated in the same manner as for the first access, described above with reference to Figure 3. The response is intercepted by instance transitioning response rule 28b which re-sets the cookie record of the web application instance accessed and sets a new expiry time. Where there is a plurality of users, each user is treated in the above described manner: each having a cookie set to indicate the instance of the site they have accessed.

Figure 5 shows how transitioning to a new instance of the website is achieved according to a preferred embodiment of the invention. We consider, first, the introduction of a change of website instance without the benefit of the present invention. If a new instance (the "next generation") of the website were to be made available on the second set of web and application servers 38, 46 (I.e. second instance 104) and this was made "live" to the public without the benefit of the instance transitioning capability described here, the cut-over to the "next generation" would take the form of an immediate change to all users. The process of enforcing downtime would mean that any users accessing the "current instance" of the website could have their access interrupted in the middle of a transaction and typically would lose their session. This could have unfortunate consequence, for example, if a user was attempting to make a purchase, they would be required to re-start the shopping activity: having to log in to the website, select and add items to their basket all over again.

With the website instance transitioning capability described here, the solution advantageously enables support teams to gracefully effect the changeover, directing new users to the new website instance whilst users who are already using the website are allowed to continue to access the current website instance in order to complete their transactions without disruption. This is achieved with the two instance transitioning rules described above.

Referring to Figure 5, in order to make the new instance of the website "live", selector pool 30 is changed to now direct users to second pool 34. Any new users requesting access to the website who do not have a cookie that records an instance of a website that they have previously accessed, are routed to selector pool 30 and from there to second pool 34 and thus to second instance 104 of the website.

Users accessing the website prior to the new instance being deployed will have a cookie 60 indicating that they have accessed the old website (instance 102). Instance transitioning request rule 28a detects this and continues to direct them to first pool 32 and, hence, to first instance 102 of the website.

According to an embodiment, if a user's session lasts long enough and customer 22 is inactive (not accessing the website), their cookie will expire and they will then be treated as a new user and redirected to the new instance of the website. According to this embodiment, the cookie has an 'expiry time' which is typically set to 20 minutes after creation. Once the expiry time is reached, the cookie will be removed from the browser. Expiry of the cookie will end the current user session. The user will lose any data/context information previously provided by the cookie and will need to log on again if they wish to continue accessing the same website. The system will receive the new log on request and will note the absence of a valid cookie. The user request will therefore be treated as a new customer as shown at (2) in Figure 5.

Instance Access

Figure 6 shows how a user can obtain access to a specific instance of the website. "Instance access" is the principle of allowing privileged users (for example support staff) to specify direct access to any running instance of the website. This can be useful, for example in ensuring that thorough testing of a new website instance can be completed prior to the new website instance being made available to the public. Special DNS addresses (URIs) are created for this purpose, known only to the privileged user. Examples of such special URIs are:

• www.A1.web site.com

• www.A2.web site.com

Each special URI gives access to a specific website instance, e.g., www.A1.web site.com giving access to first instance 102 and www.A2.web site.com giving access to second instance 104. This is achieved by a new access rule applied to virtual server 26.

The new access rule examines received access requests to see if they correspond to either of the above special URIs. If a request for a special URI is detected, a further check is undertaken to ensure that the user 24 trying to access in this way is from a known and trusted source. This check will typically involve looking at the IP address of user 24 and checking that it belongs to a known list although other forms of user authentication will be apparent to a privileged maintenance worker. Users with IP addresses not belonging to the list will have their connection terminated. As shown in Figure 6, at (1) privileged user 24 sends a request with URI www.A1.web site.com- indicating first website instance 102 and, at (2) a request with URI www.A2.web site.com indicating second website instance 104. If user 24 has an IP address that is on the approved list, each of the user's requests is directed to the pool specific to the website instance specified in the request, bypassing selector pool 30, and from there is routed to the appropriate instance of the website. Hence, the user request at (1) is directed to first website instance 102 while the user request at (2) is directed to second website instance 104.

According to preferred embodiments, model implementation access rules for use with the solution are illustrated in the Figures 7 to 9. Figure 7 shows request rule for evaluating the received cookie and directing traffic accordingly. Figure 8 shows response rule for setting a new cookie value depending on the pool used. Figure 9 shows access request rule for specific access with destination determined by the user.

According to the invention, the two or more instances of a website are accessed using a single IP address under control of virtual server 26. The solution proposed here allows "controlled" parallel running of multiple instances of a data source without switching the IP address users quote to access the data source.

In a further embodiment, a second transition may be effected, following some time after the original transition, described above. This second transition may be effected by means of a third pool (not shown) indicating a third instance of the information source. In order to make the third instance of the website "live", selector pool 30 is changed to now direct users to the third pool. Any new users requesting access to the website who do not have a cookie that records an instance of a website that they have previously accessed, are routed to selector pool 30 and from there to the third pool and thus to the third instance of the website.

User requests for access to the website accompanied by a cookie are picked up by Instance Transitioning Request Rule 28a which determines that the user has a history of accessing the website and then reads from the cookie the instance of the website that the user has accessed. The user's request is then directed to the pool specific to the website instance that they previously accessed, bypassing selector pool 30.

In a further embodiment, the second transition may be effected so as to return first instance 102 to "live" status. In order to return first instance 102 to "live" status, selector pool 30 is changed to direct users once more to first pool 32. Any new users requesting access to the website who do not have a cookie that records an instance of a website that they have previously accessed, are routed to selector pool 30 and from there to first pool 32 and thus to first instance 102 of the website. User requests for access to the website accompanied by a cookie will be treated as before.

As will be understood by those skilled in the art, the invention may be implemented in software, any or all of which may be contained on various transmission and/or storage media such as a floppy disc, CD-ROM, or magnetic media so that the program can be loaded onto one or more general purpose computers or could be downloaded over a computer network using a suitable transmission medium. The computer program product used to implement the invention may be embodied on any suitable carrier readable by a suitable computer input device, such as CD-ROM, optically readable marks, magnetic media, punched card or tape, or on an electromagnetic or optical signal.

As will be understood by those skilled in the art, the or each data traffic management server 14, web server 16 and application servers 18 may be implemented on one or more commercially available server or similar processing means. Figure 10 shows a typical architecture for a processing means suitable for implementing the communications system according to a further embodiment of the invention. In practice, a number of such means will typically be required. The processing means comprises a central processing unit (CPU) 110 for executing software programs and managing and controlling the operation of the processing means. The CPU 110 is connected to a number of devices via a bus 111 , the devices including a storage device 112, for example a hard disk drive for storing system and application software and memory devices including ROM 114 and RAM 115. The computer further includes network interfaces 117 for interfacing to external network 119. The computer can also include user input/output devices such as a mouse and keyboard (not shown) connected to the bus 111 via an input/output port 116, as well as a display 118. It will be understood by the skilled person that the above described architecture is not limiting, but is merely an example of typical processing means architecture. It will be further understood that the described processing means has all the necessary operating and application software to enable it to fulfil its purpose. The above embodiments are to be understood as illustrative examples of the invention. Further embodiments of the invention are envisaged and will be evident to the skilled reader. It is to be understood that any feature described in relation to any one embodiment may be used alone, or in combination with other features described, and may also be used in combination with one or more features of any other of the embodiments, or any combination of any other of the embodiments. Furthermore, equivalents and modifications not described above may also be employed without departing from the scope of the invention, which is defined in the accompanying claims.

The text of the abstract is incorporated hereby: a system for providing access to an information system comprising a plurality of instances; in which the system for providing access comprises: an input for receiving requests from a user for access to the information system; in which each request is associated with a session; a request processor arranged in use to identify the session to which each request belongs and arranged in use to operate in two states: in a first state, prior to initiation of a transition, the request processor is arranged to forward to the first instance each request that is the first request in a session; in a second, state, following initiation of a transition, the request processor is arranged to forward to the second instance each request that is the first request in a session. The system for providing access may also, in the first state, forward to the first instance each request associated with a session for which a request has previously been forwarded to the first instance; and forward to the second instance each request associated with a session for which a user request has previously been forwarded to the second instance. The system for providing access may also, in the second state, forward to the second instance each request associated with a session for which a user request has previously been forwarded to the second instance while continuing to forward to the first instance each request associated with a session for which a request has previously been forwarded to the first instance

Claims

1. A method of accessing an information system comprising a plurality of instances, in which the method includes: receiving user requests; identifying a session associated with each request; forwarding each request that is the first request of a session to a first instance; initiating a transition to a second instance and where a request is received following initiation of the transition: forwarding each request that is the first request of a session to the second instance.

2. A method, as claimed in claim 1 , including, following initiation of the transition, forwarding to the second instance requests associated with a session for which a request has previously-been forwarded to the second instance while continuing to forward to the first instance requests associated with a session for which a request has previously been forwarded to the first instance.

3. A method, as claimed in any above claim, including, prior to initiation of the transition, forwarding to the second instance requests associated with a session for which a request has previously been forwarded to the second instance and forwarding to the first instance requests associated with a session for which a request has previously been forwarded to the first instance.

4. A method, as claimed in any above claim, including reading a HTTP request forming a part of the request and deciding, based on the HTTP request, which of the first and second instances to forward a request to.

5. A method, as claimed in any above claim, including reading a flag inserted in the request by an administrative user and modifying the forwarding based on the flag to allow the administrative user to determine the destination for the request.

6. A method, as claimed in any above claim including, following initiation of the transition, restricting the forwarding of requests to the first instance to a set time period from the start of the transition.

7. A system for providing access to an information system in which the information system comprises a plurality of instances; in which the system comprises: an input for receiving requests from a user for access to the information system; in which each request is associated with a session; a request processor arranged in use to identify the session to which each request belongs and arranged in use to operate in two states: in a first state, prior to initiation of a transition, the request processor is arranged to forward to the first instance each request that is the first request in a session; in a second, state, following initiation of a transition, the request processor is arranged to forward to the second instance each request that is the first request in a session.

8. A system as claimed as claimed in claim 7 in which, in the first state, the request processor is arranged to forward to the first instance each request associated with a session for which a request has previously been forwarded to the first instance; and to forward to the second instance each request associated with a session for which a user request has previously been forwarded to the second instance.

9. A system as claimed as claimed in any of claims 7 and 8 in which, in the second state, the request processor is arranged to forward to the second instance each request associated with a session for which a user request has previously been forwarded to the second instance while continuing to forward to the first instance each request associated with a session for which a request has previously been forwarded to the first instance.

10. A system as claimed as claimed in any of claims 7 to 9 comprising a default indicator for indicating a default instance from among the plurality of instances.

11. A system as claimed in claim 10 comprising a plurality of specific indicators, one per instance, each specific indicator for indicating an address of a specific one of the plurality of instances in which the default indicator indicates the specific indicator for the default instance.