Abstract:
A method of accessing data from a plurality of servers includes receiving a request for the data, the request including a first transport protocol independent message. The method further includes sending the request to a first server of the plurality of servers and receiving the data from the first server through a session, the data including a second transport protocol independent message. The method further includes adding a first session identifier that corresponds to the session to the second transport protocol independent message.

Description:
FIELD OF THE INVENTION  
         [0001]    The present invention is directed to data access to a remote server. More particularly, the present invention is directed to maintaining persistence to a single remote server that is accessed using any transport protocol.  
         BACKGROUND INFORMATION  
         [0002]    In order to provide responsiveness and availability to customers, many e-commerce sites on the Internet employ multiple servers and a load balancer. In essence, the load balancer makes the multiple servers look like a single, high-powered network resource to those accessing the site. It does this by selectively forwarding connections to the many servers arrayed behind it in an equitable manner, according to the server&#39;s operational health and the nature of the query.  
           [0003]    A problem exists because individual users must be tied to a single server and maintain persistence to that server for secure transactions and for enhancing the experience for the user. For example, navigating an online application, such as a shopping cart or stock trading system, requires a series of interactions between the visitor and the site&#39;s back-end applications. These applications need to know where a user was, so that they can decide where the user will be next. If a load balancer or other device redirects the user to a different web server during an interaction session, this may cause the connection to fail, and the user&#39;s session will be ended prematurely. In addition, the user&#39;s previously entered information, such as the contents of a shopping cart, may be lost.  
           [0004]    Initially, an Internet Protocol (“IP”) address was used to correlate an individual user session. However, as the Internet grew, IP addresses were no longer tied to an individual user or single machine. Instead, Internet Service Providers (“ISP”s) such as America Online (“AOL”) proxied user connections through a few IP addresses. This is now common practice at most corporations and ISPs. This problem is commonly referred to as the “mega proxy problem”.  
           [0005]    Web sites need some means to associate a user with a specific server. Many applications and web sites will simply not work without persistence. A likely result of the lack of persistence is that the user will leave the site unsatisfied and may never return.  
           [0006]    One way to overcome the mega proxy problem is for the user to accept cookies on the user&#39;s machine. The cookies allow the user to be directed to the correct server and maintain persistence to the server.  
           [0007]    Another solution to the mega proxy problem is referred to as “URL munging”. In Uniform Resource Locator (“URL”) munging, a session identifier is stored as part of the URL. Server software uses the session identifier to identify that user&#39;s session. However, URL munging requires the web links on each web page to be updated at runtime to uniquely identify the current session. This is a CPU intensive operation, which limits the servers capacity.  
           [0008]    Most client/server interactions described above are deployed over HyperText Transport Protocol (“HTTP”) or secure HTTP (“HTTPS”). The cookie and URL munging solutions to the persistence problem only work with HTTP or HTTPS protocol. However, future client/server interactions may run over non-HTTP protocols, such as Transmission Control Protocol (“TCP”), Simple Mail Transport Protocol (“SMTP”), etc.  
           [0009]    Based on the foregoing, there is a need for a method for maintaining persistence with a server while using a load balancer that functions with non-HTTP protocols. 
       
    
    
     BRIEF DESCRIPTION OF THE DRAWINGS  
       [0010]    [0010]FIG. 1 is a block diagram of a system in accordance with one embodiment of the present invention.  
         [0011]    [0011]FIG. 2 is a flow diagram of the functions performed by a load balancer and other devices of the system in accordance with one embodiment of the present invention.  
     
    
     DETAILED DESCRIPTION  
       [0012]    One embodiment of the present invention is a system that adds a session identifier (“Session ID”) to the header of a transport protocol independent message. A load balancer directs all subsequent requests from a user that includes the Session ID to a server identified by the Session ID.  
         [0013]    [0013]FIG. 1 is a block diagram of a system  50  in accordance with one embodiment of the present invention. System  50  includes the Internet  20  and a client computer  10  that is used to access Internet  20 . Client computer  10  can be any known personal computer or other device that includes a network application such as an Internet Web browser. The network application can be the Internet Explorer from Microsoft Corp., or any other type of application that communicates with other applications via a network. Client computer  10  accesses Internet  20  through known methods such as through an Internet service provider (not shown).  
         [0014]    System  50  further includes a load balancer  30  coupled to servers  41 - 45 . Servers  41 - 45  form a group of servers that provide the same or similar content to a user and can each respond to the same URL request or other type of request from a client. Load balancer  30  can be any known load balancer that is modified to implement the present invention. In one embodiment, load balancer  30  is the NetStructure 7180 e-commerce Director from Intel Corp. that has been modified to perform the functions described below. Load balancer  30  includes a processor and a memory or other type of computer readable medium.  
         [0015]    In one embodiment, client  10  accesses load balancer  30  and servers  41 - 45  via Internet  20  through the transmission and receipt of Simple Object Access Protocol (“SOAP”) messages. SOAP is a lightweight protocol for exchange of information in a decentralized, distributed environment. It is an Extensible Markup Language (“XML”) based protocol that consists of four parts: an envelope that defines a framework for describing what is in a message and how to process it, a transport binding framework for exchanging messages using an underlying protocol, a set of encoding rules for expressing instances of application-defined data types and a convention for representing remote procedure calls and responses. SOAP Version 1.1 is disclosed in a World Wide Web Consortium (“W3C”) note published on May 8, 2000, and available at www.w3.org/TR/SOAP.  
         [0016]    A SOAP message is an XML document that consists of a mandatory SOAP envelope, an optional SOAP header, and a mandatory SOAP body. Although the described embodiments of the present invention utilize SOAP messages, any known or future transport protocol independent messages having a header may be used instead of SOAP messages.  
         [0017]    In one embodiment, client  10  accesses load balancer  30  and servers  41 - 45  via Internet  20  over HTTP protocol. However, in other embodiments the access is over any other known or future protocol, including TCP, SMTP, File Transfer Protocol (“FTP”), etc. The present invention can operate in a transport protocol neutral environment through the use of transport protocol independent messages having a header such as SOAP messages.  
         [0018]    [0018]FIG. 2 is a flow diagram of the functions performed by load balancer  30  and other devices of system  50  in accordance with one embodiment of the present invention. In one embodiment, the functions are implemented by software stored in memory and executed by the processor of load balancer  30 . In other embodiments, the functions can be performed by hardware, or any combination of hardware and software. The functions can also be performed by a device that is separate from, but in communication with, load balancer  30 .  
         [0019]    At box  110 , load balancer  30  receives a SOAP message from client computer  10 . The SOAP message includes a request and is directed to a server or to a web site that is concurrently located on each of servers  41 - 45 . The SOAP message may be sent via HTTP, SMTP, TCP, or any other transport protocol. The SOAP message includes a header.  
         [0020]    At decision point  120 , load balancer  30  determines if the header of the SOAP message includes a Session ID that identifies a session on one of servers  41 - 45 . If the SOAP message header does not include a Session ID, then the SOAP message represents a new request and at box  150  load balancer  30  forwards the request to one of servers  41 - 45  based on the configured load balancing algorithm. Load balancing algorithms typically distribute requests or queries equitably among servers  41 - 45  in order to amortize load and improve availability by avoiding downed servers.  
         [0021]    If the SOAP message header includes a Session ID at decision point  120 , at box  130  load balancer  30  looks up the Session ID within the header. The session indicated by the Session ID is then validated at decision point  140 . In one embodiment, load balancer  30  validates the session by checking its internal server to the Session ID mapping table. If the session is valid, then at box  160  the SOAP message is sent directly to the server among servers  41 - 45  that has the session. If the session is not valid (e.g., either expired or no longer in the server to Session ID mapping table), the server is picked based on the configured load balancing algorithm at box  150 .  
         [0022]    At box  170 , the server among servers  41 - 45  that received the SOAP message processes the SOAP message. As a result, the server will return a response SOAP message to load balancer  30 .  
         [0023]    At box  180 , load balancer  30  inserts a Session ID into the SOAP message returned from the server. The Session ID corresponds to the session that generated the returned SOAP message.  
         [0024]    Finally, at box  190  the revised response SOAP message is sent to client computer  10 . Client computer  10  reads the SOAP message and inserts the Session ID included in the header on subsequent requests. Therefore, subsequent requests from client computer  10  at box  110  will now include a Session ID.  
         [0025]    As described, the present invention sends all requests from client computer  10  to the same server once a connection to that server has been set up. The association is maintained even if the connection is broken or closed by client computer  10  or the server during a session. Therefore, for example, if during a session a user is placing items in a shopping cart, the current status of the shopping cart will be maintained throughout the session.  
         [0026]    The present invention provides an advantage over cookies and URL munging because it is not HTTP dependent. This allows the present invention to utilize both non-HTTP and HTTP protocols in load balanced web service environments.  
         [0027]    Several embodiments of the present invention are specifically illustrated and/or described herein. However, it will be appreciated that modifications and variations of the present invention are covered by the above teachings and within the purview of the appended claims without departing from the spirit and intended scope of the invention.  
         [0028]    For example, in the embodiments described, the Session ID is generated by the load balancer. However, in other embodiments Session ID may be generated at the client computer and can be inserted into the transport protocol independent message header at either the client computer or the server. In these embodiments, the client and the server generate a Globally Unique ID (“GUID”).