Technique for aggregate transaction scope across multiple independent web requests

[0002] 1. Field of the Invention

[0003] This invention relates to performance of commerce transactions via the Internet, and more particularly, it relates to a technique for aggregating transactional scope across multiple independent Web requests.

[0004] 2. Description of Prior Art

[0005] Electronic commerce is increasing exponentially, especially on the World Wide Web. Many businesses have set up virtual stores on Web sites that allow consumers to shop and purchase products on-line. Most commerce transactions on the World Wide Web utilize the HTTP protocol. HTTP protocol is designed as a state-less or session-less protocol with many benefits, such as rapid connections to web servers and jumping from one server to another as the subsequent hyperlinks in Web documents are referenced.

[0006] When clients/customers visit web sites, more frequently they may attempt multiple transactions which they may consider as the same event. For example, a prospective vacationer may visit a web site to purchase airlines tickets and to secure hotel accommodations. In the traditional transaction processing world it would be possible to ensure that either both transactions occur successfully or, that if either transaction fail, neither transaction occurs.

[0007] However, the state-less nature of the HTTP protocol creates a situation where independent requests must be sequentially executed, creating a situation where a failure of one transaction may leave the other transaction successfully completed. Furthermore, the design of a complete application to allow clients/customers to roll back previous transactions, e.g., cancel the airline reservation if there are no hotel accommodations available, is difficult and in many cases not possible.

[0008] Accordingly, there is a need for a method to coordinate multiple, independent Web transaction requests into a single transaction request initiated from any Web browser, in other words, aggregating transaction scope across multiple independent Web requests.

[0009] The present invention is an online transaction processing system for coordinating, in a client-server environment, multiple requests to a single server such that a client can execute requests within the scope of the same transaction. The system identifies web pages that are to be bound together to accomplish a transaction. Then the system communicates requests between the client and the server using a protocol that has either limited or no defined procedures for passing state information between the client and the servers. HTTP is an example of such a protocol that has limited procedures for passing state information. At the server, multiple independent requests involving one or more independent resource managers are executed and the actions of the resource managers, communicating among themselves in response to the request, are coordinated.

[0010] In preferred embodiments of the present invention the client authentication during a conversation and a group transaction requested by the client are coordinated. The client authentication during a conversation is accomplished by transmitting a request for a first action by a client to a server that requires transaction scope. The server then generates transaction identification information, which is maintained across the duration of multiple independent and state-less web requests.

[0011] The request for a second action is now transmitted by the client to the server that requires transaction scope. The transaction identification information preserved in the conversation and the transaction identification information maintained by the servers is included in the client's request transaction. Finally, a request is transmitted by a client to a server that requires transaction completion. The communication between the client and the server is performed using a protocol that has either limited or no defined procedures for passing state information between the client and the servers.

[0012] These and other features, aspects, and advantages of the present invention will become better understood with regard to the following detailed description, appended claims, and accompanying drawings.

[0013] The foregoing objects and advantages of the present invention may be more readily understood by one skilled in the art with reference being had to the following detailed description of a preferred embodiment thereof, taken in conjunction with the accompanying drawings wherein like elements are designated by identical reference numerals throughout the several views, and in which:

[0014] FIG. 1 is an overall architecture diagram of the preferred embodiment of the present invention;

[0015] FIGS. 2a-cis a flow diagram of a method for aggregating transaction scope over multiple independent Web requests in accordance with the preferred embodiment of the present invention;

[0016] FIG. 3 is a representation of a system of the present invention having features for performing on-line transaction processing over the World Wide Web while aggregating transaction scope; and

[0017] FIG. 4ais a structure of a hypertext link to a CGI program; and

[0018] FIG. 4bs the structure of FIG. 4amodified to include a Web transaction identifier (WTID).

[0019] The following are definitions of some terms used herein. Client— a program or an application that issues commands to a server.

[0020] Commit coordinator—a program or an application that coordinates the resolution of a transaction, its typical responsibilities include collecting votes from participants, determining the outcome of the transaction and informing all the participants of the outcome. For a discussion of the distributed two phase commit protocols, see J. Gray & A. Reuter, “Transaction Processing: Concepts & Techniques,” Morgan Kaufmann, 1993.

[0021] Common gateway interface (CGI)—a mechanism by which a client may request the execution of a program on a Web site. After receiving such request, the Web site runs the CGI program and sends the output of the program back to the client.

[0022] Continuation—a new request that a client may send to a server, which was provided by the server in response to a previous request by the client. Hypertext links or hyperlinks are examples of continuations in client-server communications. Whenever a client makes a request to a server, the server may include one or more continuations in its response. Although a continuation provided by the server could be any valid request, useful continuations are generally logically related to the original request by the client.

[0023] Conversation—a sequence of communications between a client and a server in which the server responds to each request from the client with a set of continuations, and the client always picks the next request from the set of continuations provided by the server. On the World Wide Web, hypertext links are examples of continuations. A client engages in a conversation with a server whenever it follows the hypertext links provided by the server. More formally, a series of HTML Web pages h₁, h₂, . . . , h_nconstitutes a conversation if:

[0024] 1. pages h₁, h₂, . . . , h_nwere all viewed by a client; and

[0025] 2. for all i such that 1<i<=n, page h_iwas obtained by following a hypertext link on page h_i.1.

[0026] In an uninterrupted conversation, the client simply follows n−1 hypertext links to get from page h₁to h_nwithout ever backtracking. In an interrupted conversation, the client backtracks at least once. Backtracking refers to the process where a client:

[0027] 1. initially visits a page hi, where 1<=i<n;

[0028] 2. views other pages either by following hypertext links, explicitly requesting URLs, or using the Web browser's cache; and

[0029] 3. returns to page h_iby reloading h_ifrom memory, such as from the browser's cache.

[0030] Home page—a table of contents that guides a World Wide Web user to information that is stored on a Web site. Often, a home page contains multimedia content.

[0031] Hyperlink or hypertext link—a network address, such as a Universal Resource Locator, that is embedded in a word, phrase, icon, or picture activated when selected. When a client activates a hyperlink, information corresponding to the hyperlink is returned to the client and displayed using a Web browser.

[0032] HyperText Markup Language (HTML)—the language used by Web servers to create and connect Hypertext documents that are viewed by Web clients. Other uses of Hypertext documents are described in U.S. Pat. Nos. 5,204,947, 5,297,249, and 5,355,472 which are herewith incorporated by reference herein.

[0033] Transfer Protocol (HTTP)—a protocol used by the World Wide Web to transfer data between computers. HTTP allows a client to obtain data from a server either by requesting a file or invoking a CGI program. HTTP is a stateless protocol, which means that every request from a client to a server is treated independently. No record is kept by the server of previous connections with a particular client. “http:” at the beginning of a URL, indicates the protocol to be used is HTTP.

[0034] Internet—a collection of computer networks and gateways connected to each other using the TCP/IP protocol.

[0035] Server—a program or an application that performs a task at the command of a client. A Web site may be a server. The term server is not synonymous with the Web servers that support Web sites.

[0036] Thread of execution—refers to an execution unit where a Web request will execute. For a CGI request it would be equivalent to the process in which the actual request was executed, while for an ICAPI request it would be the thread on which the request ran.

[0037] transaction—refers to an atomic, consistent, isolated, and durable (ACID) unit of work.

[0038] Transaction scope—refers to a collection of individual and independent requests that logically constitute a transaction

[0039] Transaction identifiers refers to an identifier that uniquely identifies a transaction in a network. A transaction identifier is unique for all time i.e., it will not be reused.

[0040] Transmission Control Protocol/Internet Protocol (TCP/IP) —is a collection of protocols that divides digital data into packets, routes the packets through the network, and reconstructs the packets at their destination.

[0041] Universal Resource Locator-13 (URL) is a way to uniquely identify or address information on the Web. A URL can be considered to be the Web equivalent of an e-mail address. URLs can be cumbersome if they belong to documents buried deep within others, but they can often be accessed with a hyperlink. An example of a URL is:

[0042] “http://www.macbeth.com:80/table.html”. A URL has four components, starting from the left, they are:

[0043] http —the protocol to be used, it is separated from the rest of the URL by colon;

[0044] www.macbeth.com—the hostname or Internet Protocol (IP) address of the target host. This component is delimited on the left by // and on the right by / or a colon;

[0045] 80—optional port number, delimited on the left by a colon and on the right by a /; and

[0046] table.html—the actual file name or program name.

[0047] Web browser—a client program that allows a person to display the hypertext documents on the World Wide Web. A

[0048] Web browser—acts as an Internet tour guide, complete with pictorial desktops, directories and search tools, which can be used to navigate or surf the Internet.

[0049] Web transaction identifiers (WTID)—refers to an identifier that uniquely identifies a transaction in a network. A transaction identifier is unique for all time i.e., it will not be reused.

[0050] World Wide Web (Web)—a collection of hypertext documents on the Internet. A hypertext document contains hyperlinks to other documents, which may be used to navigate from document to document. In practice, people seeking information on the Internet can use the Web to switch from server to server and database to database by selecting hyperlinks, which are usually displayed as highlighted words or phrases in documents. The resources on the Web are accessible through URLS. The Web utilizes the HTML to display the information corresponding to URLs and to provide a point-and-click interface to other URLs.

[0051] FIG. 1 shows the client 101 using a web browser 102, communicating with the server 103 via Internet 100 using a communications protocol, such as HTTP 109, which has limited or no defined procedures for maintaining client state information. The server 103, includes a page assembler component 104, a Web communication resource manager (CRM) 105, and a commit coordinator 106. The server 103 has access to underlying resource managers, such as web pages 107 and web applications 108. Limited or no defined procedures for maintaining client state information means that for a non-empty subset of types of communications between a client and a server using the protocol, it is difficult or impossible to preserve state variables such as the client's previous requests in a conversation using the procedures defined by the protocol so that the state variables can be subsequently retrieved by a server 103 during the remainder of the conversation.

[0052] The Web Communications Resource Manager 105 provides transactional management on the server side and has special logic to aggregate multiple web requests into a single aggregated transaction scope. The Commit Coordinator 106 provides an implementation of a well known distributed two phase commit protocols.

[0053] Optionally and commonly, the client 101 may use a Web browser 102 to visually display the results of its request and input new requests.

[0054] The server 103 coordinates the requests of the client 101 as if they were part of the same transaction. The client 101 issues a request to the server 103 to begin a transaction for a URL using the HTTP protocol by touching the URLs that are designated or tagged as transactional. FIGS. 2a-cshow a preferred embodiment of the present invention in which a request is issued in step 500.

[0055] In step 530, the server 103 (FIG. 1) determines whether the request is for a static HTML page. If a static Web page has been requested, then the processing continues in step 550, where the HTML page designated by the URL is fetched from the storage medium, such as, but not limited to RAM, disk and CD. However, if it is determined that a static Web page has not been requested then processing continues at step 535, where the server 103 (FIG. 1) contacted by the client determines whether the URL requested is a well-known URL, i.e., a URL with implicit semantics.

[0056] In step 600, the server scans the web page to determine if there are any transactional keywords in the page. The page could contain keywords such as “WTID=TXCODE” embedded in the URL, such as the URL 401 shown in FIG. 4a.As mentioned previously, there must exist “well-known” URLs that have implicit transaction semantics. These URLs must be designated by a transactional keyword. They could be represented by COMMIT, ABORT or DONE buttons on a Web page. An end user would select the button in order to end a transaction. If there are no transactional keywords found in step 600, then at step 625 the Web Page is returned to the client 101 (FIG. 1) as would an existing Web Server.

[0057] However, if it was determined in step 600, that there are transactional semantics, i.e., additional transactions associated with the Web Page, then a determination is made in step 605 if a WTID exists for this conversation. If a previous request initiated the transaction then a continuation technique may be used to propagate the WTID into the static web page currently being processed. To continue across static pages it may be passed as a WTID keyword on the current URL or it may be based on the client identity using well-known techniques such as client IP address or Netscape cookies.

[0058] Where no WTID exists for this conversation, step 610 creates the WTID and optionally, may set a timer at step 615, for the purpose of providing a technique to terminate the work in progress if the client does not respond in an appropriate time. The WTID that was either located in step 605 or created in step 610 is inserted into the Web Page at step 620, resulting in URL 402 as shown in FIG. 4b.Step 625 returns the Web Page to the client 101 (FIG. 1). As shown in FIG. 2(c), if a well-known URL has been entered in step 535 (FIG. 2a), the process continues to step 510 where the Web CRM extracts the Web Transaction Identifier (WTID) from the URL and determines if the transaction it represents is valid. In step 510, two possible validity checks include:

[0059] 1) a test of whether the transaction has timed out; and

[0060] 2) a test of whether the transaction identifier is meaningful to this server, i.e., known to or generated by this server.

[0061] Additional validity checks may be performed. If the WTID is invalid, in step 515 the server rejects the client request. The conversation may be terminated with an error message.

[0062] If the WTID is determined to be valid, then at step 520, the server 103 (FIG. 1) initiates commit processing by invoking a call to the commit coordinator 106 (FIG. 1). The commit coordinator 106 (FIG. 1) handles all commit processing and recovery related to the transaction.

[0063] Referring back to FIG. 2(c), at step 525, the Web communication resource manager terminates the timer set for the transaction since the timer is only needed when the transaction is active, i.e., the time prior to transaction commit processing. Once local commit processing is complete as indicated at step 530, the server 103 (FIG. 1) returns an indication of the transaction outcome to the client via the implemented protocol.

[0064] Referring back to FIG. 2(a), if the test for a well-known URL in step 535 was negative, then the process continues at step 540, FIG. 2(b), to determine whether WTID is present in the URL, indicating that an application must be scheduled, e.g., a CGI based program. If WTID is not present, then a request is scheduled in step 585, in a manner similar to a standard server, and the output page is generated in step 580. If the generated page contains any indicators of transactional requests, e.g., WTID keywords, then the current WTID must be substituted into the page as described with reference to step 620 FIG. 2(a). The page is then returned to the client in step 590 via the implemented transaction protocol. Returning to step 540, if the WTID is present in the URL, then the validity of the WTID is determined at step 545. These checks may be the same as described with respect to step 510 FIG. 2(c). If at step 545 the WTID is determined to be invalid, then the client request is rejected at step 560. However, if the WTID is valid then it is associated with the current thread of execution in step 555, and the request for scheduling is then issued in step 565.

[0065] During the execution of the request, a determination is made at step 570 whether a recoverable resource has been accessed. If a resource has not been accessed, the processing proceeds to step 580. If a recoverable resource has been accessed, then interest in the transaction is expresses at step 575 indicating that the issuing resource manager is a participant in the transaction.

[0066] Finally, at step 580, the output page is generated. If the generated page contains any indicators of transactional requests, e.g., WTID keywords, then the current WTID must be substituted into the page in a manner as described with respect to step 620. The page is then returned to the client in step 590.

[0067] A system of the present invention for performing on-line transaction processing over the World Wide Web while aggregating transaction scope may be constructed as shown in FIG. 3. The system comprises a Web Server 211, a Resource Manager 210, CGI applications 208, and a Common Commit Coordinator 212. The Web Server 211 and the Common Commit Coordinator 212 components constitute the server 103 (FIG. 1).

[0068] The Web Server 211 runs a HTTP daemon, which may optionally provide interfaces for passing parameters to separate internal or external programs. The interfaces CGI 206 and ICAPI 205 allow, based on URL information, user-written applications to execute. The Web Server 211 components may include:

[0069] a. the SSI/Page 214 representative of the page assembler 104 (FIG. 1), for scanning web pages to determine if there are any transactional keywords in the page and inserting WTID into Web pages being served:

[0070] b. the SSI/RM 201 consists of functions to demarcate transactions and establish timers in a manner described herein in connection with FIG. 2; the SSI/RM 201 and Web Threads 204 together constituting the Web CRM 105 (FIG. 1);

[0071] c. the Web Threads 204 consisting of functions used to associate WTID with threads in the case of ICAPI applications 207, or the processes of execution in the case CGI applications 208; and

[0072] d. ICAPI applications 207 which together with CGI applications 208, represent specific types of Web Applications 108 (FIG. 1) that may dynamically generate Web pages.

[0073] The ICAPI applications 207 and the CGI applications 208 may optionally interact with the Resource Manager 210 using interfaces 209, 213 respectively. Interfaces 209, 213 may be different, however they must allow for a WTID associated with the initiating thread or process of execution to be communicated implicitly or explicitly to the Resource Manager 210.

[0074] The Common Commit Coordinator 212 interacts with the SSI/RM 201 through the CC interface 202 and with the Resource Manager 210 through the CC interface 203.

[0075] While the invention has been particularly shown and described with respect to illustrative and preferred embodiments thereof, it will be understood by those skilled in the art that the foregoing and other changes in form and details may be made therein without departing from the spirit and scope of the invention that should be limited only by the scope of the appended claims.