CA2308801C - Method and apparatus for performing transactions in a stateless web environment which supports a declarative paradigm - Google Patents

Abstract

A method and system for processing multiple-request transactions in a stateless environment is provided. A cartridge execution engine (228) intercepts browser messages directed to a cartridge. The cartridge execution engine (228) determines whether the browser messages are associated with transactions. If it is determined that browses messages are associated with transactions, then the cartridge execution engine (228) sends transaction control messages to a transaction manager (606). In addition, the cartridge execution engine (228) sends operation messages to the cartridge. The cartridge then performs the operations specified in the operation messages. In response to the transaction control messages from the cartridge execution engine (228), the transaction manager (506) causes the multiple-request transactions to be either committed or rolled back as an atomic unit of work.

Description

1\Ll.ll).\.I:I~lA-111.1:.\1.110..\ 17. ..1'11-iJJ . ~11 1.:. ' ...J .
aa7w.J~./1..
.l.
METHOD AND APPARATUS FOR PERFORrHNG
TRANSACTIONS IN A S?ATELESS WEB ENVIRONMENT WHICH SUPPORTS
A DECLARATIVE PAIt.A.DI(~NI
FIELD OF THE INVENTION
This invention relates to processing transactions in networked computer sy stems, and more specifically to processing multiple-request transactions in a stateless web environment.
BACKGROUND OF T'HE INVENTION' The World Wide Web includes a network of servers on the Internet, each of which is associated with one or more 1'~ITML (Tlypertext Markup Language) pages. The 1-ITML pages associated with a server provide infvnnativn and hypertext links to other documents on that and (usually) other servers. Servers communicate with clients by using the Hypertext Transfer Protocol (HTTP). The servers listen for requests from clients for their HTML
paces, and are therefore o8en referred to as "listeners" .
Users of the Warld Wide Web use a client program, referred to as a browser, to request, decode and display information from listeners. When the user of a browser selects a link on an HTML page, the browser that is displaying the page sends a request over the Internet to the listener associated with the Universal Resource Locator (LJR.L) specified in the link. In response to the request, the listener transmits the requested information to the browser that issued the request. The browser receives the information, presents the received information to the user, and awaits thz next user request.
2S Traditionally, the information stored on listeners is in the foc~aa of static HTIvII, pages.
Static HTIvIL pages are created and stored at the listener prior to a request from a web browser. In response to a request, a static ~ITML page is merely read from storage and ixansttzitted to the requesting browser. Currently, there is a trend to develop listeners that respond to browser zequests by performing dynamic operations. For example, a listener may respond to a request by issuing a query to a database, dynamically constructing a web page containing the results of the query, and transmitting the dynanucally constructed HTML, page to the requesting browser. To perform dynamic operations, the Functianiality of the listener must be enhanced or augmented. Various approaches have been developed for extending listeners to support dynamic opeTadvns.

AMENDED SHEET

tW.\_\lJ:\~L:1'l1-.IInI:W ill.:..\_~-_ .. ..___~ 1~~~.:~~~._-- .._'_'~ .__ .._ -___ ._ .._______....___._ . _~=m~~_Wu~" .w Qne of the major characteristics of the web is that it provides a stateless environment.
That is, HTTP communicates information on a message-by-message basis without any mcchanisxn for designating relationships between messages. This means that a process servicing a current request cannot determine whether the current request came from .the same client as a previous request. In addition, the servicing process cannot determine how or if the cuzrent request relates to a previous request.
A disadvantage with using a stateless environment is that it is difficult to process multiple-request transactions. A multiple-request transaction is a set of operations that (I) are specified in more than one request, and (2) ziiust be performed as an atomic wait of work. For e~cample, a multiple-reauest transaction could consist of three separate operations, such as buying stoclG item A, selling stock item B and updating the inventory to reflect the number of stock items on hand. Each of these three operations may be specified in a separate request, but each operation should only be performed if all three operations can be performed. 1n. order to properly determine that buying stock item A, selling stock item B and updating the inventory are from the same single transaction requires that transaction state information be retained by the servicing process that receives the three requests.
One possible solution to the stateless problem is to spawn a servicing process for each request-issuing source (each ''client"), Each time a request from a client is received, the same servicing process is called upon to process the request. Because the same process is invoked for a given clzezlt, the transaction state information fax a particular transaction can be maintained by the associated servicing process, thus allowing for the processing of rnultiple-request transactions.
This solution has significant drawbacks, howe~~er. First, maintaining a separate servicing process for each client is wasteful since most clients do not continually make requests to the servicing process. Between client requests, the servicing process simply waits, consuming systeln resources, without performing any tvork. A second drawback with this solution is that it is non-scalable. rf a servicing process is spawned and maintained for each client, systez~c~ resources would quickly be consu~oaed, even for a relatively small number of clients. Therefore, spawning a servicing process fox each client is not a viable solution for large scale systems.
A second possible solution is to require each senzcing process to maintaiua the current state of the transactions that it is currently processing. By maintaining transaction state information, each sezvicing process can ensure that multiple-request transactions are processed correctly, Ai~ENDED SHEEN, hl:v. vi):v:l~l'y-vIILVI.IIL:v ty_ . . ..___'-11-:~J___ =s 1tt ~.__ _._ _WUlts .. L..-ll~l___. ._ tl:~ Zs:J :~a:J:l~l~.luir:Nl:!

For example, additional details on the background and the problem being solved by embodiments of the prGSent invention are found in an INTERNATIONAL APPLICATION
PUBLISHED UNDER THE PATENT COOPERATION TRLAT"Y' {PCT) {WO 97/40457), entitled "SYSTEM AND METI-I017 FOR DATA ACCESS", filed on 30 October 1997. In this document a client-server system is described that uses a stateless protocol to access server data. By linking the server system to the client system, improved network communication efficiency over the network is achieved. As explained, for each initial client system transaction request, the server generates a unique identifier, or token, which is returned over ., the network to the client system, the receipt of which tokrn acts to hold the logical connection to the server in an active or open condition until the client system is finished with the connection and releases it. At the server, the token is used to identify client state information, also referred to as user context information, retained at the server for use with following-on communications with the client. Follow-on cozumunications from the client include the token, which the server uses to identify the stored client state information. Thus, by keeping alive the network connection between server system and client system, the described system reduces network overhead thereby reducing the total system overhead, However, a drawback associated with requiring each servicing process to maintain transaction state information is that it puts a burden on the developer of each servicing process to write extra code in order to maintain the required transaction state information.
Based on the foregoing, it is desirable to provide a mechanism for processing rnultiple-request transactions in a stateless environment that does not require a servicing process to maintain transaction state information.
.- SUIvEVIARY OF THE TNVEN?ION
A method and system for processing multiple-request transactions in a stateless environment is provided.
According to oz~e aspect of the invention, a cartridge execution engine intercepts browser messages directed to a cartridge. The cartridge execution engine determines whether the browser messages are associated with transactions. If the browser messages are associated with transactions, then the cartridge execution engine sends transaction control messages to a transaction manager. The cartridge execution engine also sends operation messages to the carhidge. The cartridge performs the operations specified in the operation messages. )'n response to the transaction control messages from the cartridge execution engine, the transaction manager causes the multiple-request transactions to be either committed or rolled back as an atomic unit of work.

AMENDED SHEET

According to another aspect of the invention, the browses messages associated with transactions are associated with transaction IDs that can be used to identify a browses that is associated with a particular browses message.
According to another aspect of the invention, the browses messages associated with 5 transactions axe associated with transaction TDs and are used to identify a browses associated with a particular browses message.
According to another aspect of the invention, the transaction IDs are maintained as cookies on the browses that is associated with the particular browses message.
According to another aspect of the invention, the transaction IDs are maintained as URLs on the browses that is associated with the particular browses message.
In a broad aspect, then, the present invention relates to a method for processing multiple-request transactions in a stateless environment, wherein the multiple-request transactions involve operations specified in browses messages, the method comprising the steps of a cartridge execution engine intercepting browses messages directed to a cartridge;
said cartridge execution engine determining whether said browses messages are associated with transactions; if said browses messages are associated with transactions, then said cartridge execution engine sending transaction control messages that are based on said browses messages to a transaction manager that is implemented separately from said cartridge; said cartridge execution engine sending operation messages that are based on said browses messages to said cartridge in response to said operation messages from said cartridge execution engine, said cartridge performing the operations specified in said operation messages without the cartridge persistently maintaining state information for the multiple-request transactions to which the operations belong; and in response to said transaction control messages from said cartridge execution engine, said transaction manager causing the operations specified in said operation messages that are performed by said cartridge as part of the multiple-request transactions to be either committed or rolled back as an atomic 'unit of work.
In another broad aspect, the present invention relates to a computer readable medium carrying sequences of instructions for processing multiple-request transactions in a stateless environment, wherein the multiple-request transactions involve operations specified in -4a-browser messages, the sequences of instructions including instructions for performing the steps of a cartridge execution engine intercepting browser messages directed to a cartridge;
said cartridge execution engine determining whether said browser messages are associated with transactions; if said browser messages are associated with transactions, then said cartridge execution engine sending transaction control messages that are based on aid browser messages to a transaction manager that is implemented separately from said cartridge; said cartridge execution engine sending operation messages that are based on said browser messages to said cartridge in response to said operation messages from said cartridge execution engine, said cartridge performing the operations specified in said operation messages without the cartridge persistently maintaining state information for the multiple-request transactions to which the operations belong; and in response to said transaction control messages from said cartridge execution engine, said transaction manager causing the operations specified in said operation messages that are performed by said cartridge as part of the multiple-request transactions to be either committed or rolled back as an atomic unit of work.
In a further broad aspect, the present invention relates to a system for processing multiple-request transactions in a stateless environment, wherein the multiple-request transactions involve operations specified in browses messages, the system comprising: a memory; one or more processors coupled to the memory; and a set of computer instructions contained in the memory, the set of computer instructions including computer instructions which when executed by the one or more processors, cause the one or more processors to perform the steps of a cartridge execution engine intercepting browses messages directed to a cartridge; said cartridge execution engine determining whether said browses messages are associated with transactions; if said browses messages are associated with transactions, then said cartridge execution engine sending transaction control messages that are based on said browses messages to a transaction manager that is implemented separately from said cartridge; said cartridge execution engine sending operation messages that are based on said browses messages to said cartridge; in response to said operation messages from said cartridge execution engine, said cartridge performing the operations specified in said operation messages without the cartridge persistently maintaining state information for the multiple-request transactions to which the operations belong; and in response to said -4b-transaction control messages from said cartridge execution engine, said transaction manager causing the operations specified in said operation messages that are performed by said cartridge as part of the multiple-request transactions to be either committed or rolled back as an atomic unit of work.
In still another broad aspect, the present invention relates to a method for executing a transaction that involves a series of operations, the method comprising the steps of registering said transaction by storing metadata that establishes a mapping between transactions commands and message items; receiving a series of browser messages that request performance of said series of operations; in response to said series of browser messages, executing said series of operations as an atomic unit of work; and determining when to begin, commit and roll back said atomic unit of work based on message items in said series of browser messages and said metadata.
BRIEF DESCRIPTION OF THE DRAWINGS
The present invention is illustrated by way of example, and not by way of limitation in the figures of the accompanying drawings and in which like reference numerals refer to similar elements and in which:
Figure 1 is a block diagram of a computer system upon which an embodiment of the invention may be implemented;
Figure 2 is a block diagram of a distributed application server according to an embodiment of the invention;
Figure 3A is a portion of a flow chart illustrating steps for handling a browser request according to an embodiment of the invention;
Figure 3B is another portion of the flowchart illustrating steps for handling a browser request according to an embodiment of the invention;
Figure 4 is a block diagram of a table containing information maintained by a dispatcher according to an embodiment of the invention;
Figure 5 is a block diagram of a table containing information maintained by a resource manager according to an embodiment of the invention;
Figure 6 is a block diagram of a distributed application server for processing transactions according to an embodiment of the invention;

Figure 7A is a portion of a flow diagram illustrating steps for processing multiple-request transactions in a stateless environment according to an embodiment of the invention;
Figure 7B is another portion of the flow diagram illustrating steps for processing S multiple-request transactions in a stateless environment according to an embodiment of the invention;

Kl.~.~U.\~L:1;;1-11LC:.'.IItL:.~ y_ . . .__'~...tt',:lJ.__ !)yar '.__ -._ ~rw'~ -'W.=_m''--'__..-.____~~~ =..u,.._t,mu..m.~
-S' Figure 7C is another portion of the flew diagr~n illustrating steps for processizxg multiple-request tzaztsactions in a stateless environment according to as embodiment of the invention;
Figuxe 7D is anothor portion of the flow diagram illustrating steps for processing multiple-request transactions in a stateless en~rironmcnt according to an embodiment of the invention;
Figure 7E is another portion of the flow diagxam illus~ating steps for processing multiple-request transactions in a stateless environment according to an embodiment of the invention; '°
Figure 7F is another portion of the flow diagram illustrating steps for processing multiple-request transactions i1-1 a stateless cnvironmcaat according to an embodiment of the invention;
Figure 7G is another portion of the flow diagram illustrating steps for processing multiple-request transactions in a stateless environment according to an embodiment of the 1 S invention;
Figure 7H is another portion of the flow diagram illustrating steps for processing multiple-request transactions in a stateless environrnent according to an embodiment of the invention; and Figure 7I is another portion of the flow diagram illustrating steps for processing multiple-request transactions in a stateless environment according to an e~oabodiment of the invention.
DETAILED DESCRIPTION QF THE PREFERRED EMBODIMENT
A method and apparatus for processing multiple-request transactions over a network is described. Iz~ the following description, for the purposes of explanation, numerous specific details are set forth in order to provide a thorough understanding of the present invention. It will be apparent, however, to one skilled in the art that the present invention may be prachiced without these specific details. In other instances, well-known structures and devices axe shown in black diagram form in order to avoid unnecessarily obscuring the present invrntion.
HARDWAk~ OVERVIEW
Figure I is a block diagram that illustrates a computer system 100 upon which an embodiment of the invention may be implemented. Coz~nputer system 100 includes a bus 102 or other communication mechanism for communicating information, and a processor 104 coupled with bus 102 for processing information. Computer system 100 also includes a main mexnory 106, such as a random areeess memory {RAM) or other dynamic storage device.

AIL~Fr~.IfW ~ ..: _-Kl\. \l).~~1~I':1-,111.1:.W..IIL::v_ v1 -_ . ..__-~. 11-.v~y__ :~-t.'~ '.__ -_ __~_"' W ~.._______. ._ ~_t'~ :'~' .__'.y~~...~.a m.

coupled to bus I02 for storing information and instructions to be executed by processor x04.
lvlain memory 106 also tray be axed for storing temporary variables or other intermediate information dining execution of instructions to be executed by processor 104.
Computer system 100 further includes a read only memory (ROlvl) 108 or other static storage device coupled to bus 102 for storing static information and instructions for processor 104. A storage device 110, such as a magnetic disk or optical disk, is provided and coupled to bus 102 far storing information xnd instructions.
Computer system 100 may be coupled via bus 102 to a display 112, such as a cathode ray tubb (CRT), for displaying information Lo a computer user. An input device 114, including alphanumeric and other keys, is coupled to bus 102 for cvznmunicating information and comtxn.and selections to processor 104. Another type of user input device is cursor control '''116, such as a mouse, a trackball, or cursor direction keys for communicating direction information and command selections to processor 104 and for controlling cursor movement on display 112. Thia input device typically has two degrees of freedom in two axes, a first axis (e.g., x) and a second axis (e.g., y), that allows the d.cvice to specify positions in a plane.
The invention is related to the use of computer system 100 to perform specific operations in response to messages froir. browsers. According to one embodiment of the invention, the operatioz~,s are performed by computer system 100 in response to processor 104 executing one or more sequences of one or more instxvetions contained in main memory 106.
Such instzuctions may be read into main memory 106 from another computer-readable medium, such as stozage device 110. Execution of the sequences of instructions contained in main memory 106 causes processor 104 to perform the process steps describzd hereiut. In alternative embodiments, hard-wired circuitry may be used in place of or in combination with software instructions to implement the invention. 'Thus, embodiments of the invention are not limited to any specific combination of hardware circuitry and software.
The term "computer-readable medium" as used herein refers to any medium that participates in prrwiding instntctions to processor 104 for execution. Such a medium may take many forms, iuneluding but not limited to, non-volatile media, volatile media, and bca:nsmission media. Non-volatile media includes, for example, optical or magnetic disks, such as storage device 110. Volatile media includes d;~namic memory, such as main metxxvry 106.
Transmission media includes coaxial cables, copper wire and fiber optics, including the wires that comprise bus 102. Transmission media can also take the form of acoustic or light waves, such as those generated Bluing radio-wave and inbca-red data communications.

e1 '.~~ _.. : .' ~tY~l... .L.'~~... ~r4 1~~ t KC.l.ll)~\~l:l':1-:lll.L:.vllll:v ~1_ W tt'JJ ~ ~.>~::.~ ~ !vJ') .:1 ~.~ym y.!
.u.i ...r:W'W ..amrW

Common forms of computer-xeadable media include, for example, a ffvppy dish, a flexible disk, hard disk, magnetic tape, or any other magnetic medium, a CD-ROM, any other optical medium, punchCards, papertapc, any other physical medium with patterns of holes, a RAM, a PROM, and EPROM, a FI,AS~T-EPROM, any other memory chip or cartridge, a cazzier wave as described hereinafter, or any other medium fzom which a computer can read.
Various fornls of computer readable media may be involved in carrying otte or more sequences of one or more ixtstzuctions to processor 104 for execution. For example, the instructions play initially be carried on a magnetic disk of a remote computer. The xernate computer can load the instructions into its dy3tamic memory and send tlxe instructions over a telephone line using a modem. A modem local to computer system 100 can receive the data on the telephone line and use an infra-red transmitter to convert the data to an infra-red signal. An infra-red detector coupled to bus 102 can receive the data carried in the iuafra-red signal and place the data on bus I02. l3us 102 carries the data to main memory 106, from which processor 104 retrieves and executes the instructions. The instructions received by main memory 106 may optionally be stored on storage device 110 either before or after execution by processor 104.
Gomputer system I00 also includes a communuication interface 11$ coupled to bus 102. Communication interface 11$ provides a two-way data conununicatian coupling to a network link 120 that is connected to a local network 122. For example, communication intez~face 118 may be an integrated services digital network (ISI?N) card or a modem to provide a data communication connection to a corresponding type of telephone line. As another example, communication interface 118 may be a local area network (LAN) card to provide a data comxnurucation connection to a compatible LAN. Wireless links may also be implemented. In any such implementation, communication interface 118 sends and receives electzical, electromagnetic or optical signals that carry digital data streams representing various types of infornoation.
Network link 120 typically provides data cornmunication through one or more networks to other data devices. Far example, network link 120 may provide a connection through local network 122 to a host computez I 24 or to data equipment operated by an Internet Service Provider (ISP) 126. ISP 126 in turn provides daxa communication services though the world wide packet data cornmurueation network now commonly referred to as the "Interrxet" x 28. Local network 122 and Internet 128 both use electrical, electromagnetic or optical sigia,ls that carry digital data streams. The signals through the various networks and the signals on network link 120 and through communication interface 118, which carry the AMENDED SHEET

KC.~.4Ui\~I:I'(\m111_I~,Vt.IIL.~ IJ_.' . __ i:'-,1 l-.J:l-_- _.~'I:I '.__ -._ WIW -~1..=~fLV =_.._t'tJ bJ .Y:.i:I:J-t:ru.~.irLtf -g-digital data to and from computer system 100, are exemplary forms of carrier waves transporting the information.
Computer system 100 can send messages and receive data, including program code, through the network(s), network link 120 and communication interface 118. en the rnternet example, a server I30 might transmit a requested code for an application program through Interzret 12$, ISP 126, local network 122 and communication iwterface 118.
The received code may be e~;ecuted by processor 104 as it is received, and/or stored in storage device 110, yr other non-volatile storage For later execution. In this manner, computer system 100 may obtain application cede in tie form of a carrier wave.
FUNCTIONAL QVERVIEW OF APPLICATrON SIrRVfilt Figure 2 is a block diagram of a system 200 designed according to au embodiment of the invention. The system 200 inchrdes a plurality of browsers 202, 204 and 206 that communicate with a plurality of listener's 210, 216 and 222 over the Internet 20$ according to the I-ITTp protocol. In response to requests from the browsers, the listeners cause a yveb application server Z80 to inVOke software modules, referred to herein as cartridges. In the illustrated embodiment, web application server 280 has uaitiated the execution of three cartridges 230, 234 and 238.
The web application server 280 is composed of numerous components, including transport adapters 212, 21$ and 224, dispatchers 214, 220 and 226, an authentication server 252, a virtual path manager 250, a resource manager 254, a cor>,figuration provider 256 and a plurality of cartridge execution engines 228, 232 and 236. The various components of the web application server 280 shall be described hereafter in greater detail.
. Significantly, the numerous components ofweb application server 280 communicate through an inter-machine commuzxication mechanism, such as an Object Request Broker 2$2.
'Using an inter-machine communication mechanism, cartridge instances that perform the operations specified in browser requests may execute on different macbanes than the listeners that receive the requests and the browsers that issue the re9uests. Because the cartridge ' instances are an different machines than the listeners, the listeners are better insulated against faulty cartridge instances, thus enhancing the reliability and security of the system. In 34 addition, the scalability of the system is greatly increased by spreading the processing burden of executing the cartridge instances among many machines, rather than the same machine that is executing the listener. The ability to distribute cartridge instance execution across multiple machines allows numerous types of load balancing techniques to be used in deciding when and whexe to spavlm new cartridge instances.

AiviENDED SIiE~~, Ivll. \w,~.~L:1'w-vH.L:.wm_.~ ~m ~m ~ m .~:~ ~ .. . . .. ...
_g_ A typical operation within system 200 generally iacludes the following stages:
A browser transmits a request aver the xz~ternet 208.
A liste~ncr receives the request and passes it thmugh a transport adapter to a dispatcher.
The dispatcher coznmunicatcs with virtual path manager 250 to identify a cartridge selected by the browser request and to determine whether the cartridge requires authentication If the cartridge requires authentication, the dispatcher coznmunicatcs with the authentication server 252 to determine whether the browser is authorized to access the selected cartridge.
If the authentication server 252 dete'rrnines that the browser is not authorized to access the selected cartridge, the browser is notified that access has been denied.
However, if access is authorixed or the virtual path manager 250 determines that authentication is not required, the dispatcher dons one of two things. If the dispatcher knows about an unused instance for that cartridge, the dispatcher sends the request to that instance. Ff there are no unused cartridge instances for that cartridge, the dispatcher asks the resource manager 254 to create a new cartridge instance. After the instance starts up successfully, the cartridge notifies the resource manager of its existence. The resource manager 254 then notifies the dispatcher of the new instance. The dispatcher creates a revised request based on the browser request and sends the revisett request to the new instance.
Tlae cartridge instance handles the revised request and sends a response to the dispatcher.
The dispatcher passes the responso back through the listener to the client.
These stages shall be described in greater detail hereafter.
CA1ZTRIDCrES
Cartntdges are modules of code for performing specific application or system functions. A cartridge forms the basic unit of distribution in the system Z00.
According to one embodiment of the invention, cartridges are named using Universal Resource Locators {URLs). Thus, a cartridge nano~e {i.e. URL) has two parts: the IP address of the server on which the cartridge resides, and the virtual path in the sewer directory structure of the compiled cartridge code. Hecause cartridges are named using URr.s, the cartridge name space is global and cartridges may be accessed using the sanne messaging techniques as are used to access other web resources, such as documents.
According to one ezrxbodiment of the invention, each cartridge has a standard interface which provides a common overall structure for all cartridges. The standard interface defines the interface of routines that are invoked by the web application server Z80 under particular ~iE~.,~~__ - _ .

hCl:~ . ~ UV: L'.I'f~-:111 ~1'..W_I IL::V ty :7- a a -:J:J ~ .~ ~ W l , t-wp .
n ~ _..u v u.
.._. _. __ __ ._ . .___..._. .___ _.._.. .__ _._ .___ ._ .._______.._'r:~_).r _y,i.rrW a~~r_ conditions. According to one embodiment of the invention, the abstract cartridge interface is as follows:
interface Cartridge Boolean init.;
Boolean authentieatc(in Principal user~asswd);
Boolean exec(in Request rec~obj, out Response rasp obj);
Boolean shutdowns; '' }
The init0 routine is responsible for intializing the cartridge instance. This n~,ay include invoking the cotlstructors of several subobjects, preforking threads a:r~d acquiring all other reqwired shared resources.
The shutdawnQ routine is responsible for cleaning up all of the resources and shutting down the cartridge instance. Once the shutdown() routine is invoked on a cartridge izxstance, it immediately becomes unavailable for servicing subsequent requests.
The authenticated routine validates whether the client requesting the services ofthe cartridge is authorized to use those services.
The exec() routine is the generic way to dispatch all service requests to the cartridge.
z0 EXEMPLARY CARTRIDGES
Each cartridge is either eonfieured as a cartridge that performs a well-defined function, or as a pragxammable cartridge that acts as an interpreter or a routine envirorument for an application An example of a programmable cartridge is a PL/SQL runtime, configured to process database queries according to the Oracle-based Programming Language using Structured Query Language (PLISQL). The PLISQL runtime executes a browser request having a database query. The PLISQL ruiZtixnc processes the request, for exacnplc, by accessing a database server in communication with tlxe cartridge instance via a data link.
Another example of a programmable cartridge is a JAVA runtime interpreter. The JAVA runtirr~e interpreter cartridge enables web application developers to write server-side JAVA applications to process bmwscr requests. Similarly, a custom server may be configured as a cartridge in order to provide dynamic operations such as, for exannple, accessing processes executed by a third party server.

~,~~ f I

Kl:\.\(h\:I.l'~l-~~11~;W.IIL:.\ O=_ .___~-.lm:l:~___ _p .v ~.__ _._ _1~W --rv.._'m'=__. _ _t-~'_m -~~~:m~tv~r~m_~

DhSP.A,TCI~RS
Dispatchers are software modules con,fLgured to route the requests received by listeners to the appropriate cartridges. According to one embodiment of the invention, dispatchers are implemented as server-side program extensions (i.e. "plug-ins" ). As such, the dispatchers are loaded into and execute within the same address space as the listeners to which they belong.
The dispatchers may be linked with the listener code at compile tune or dynamically loaded at runtime_ In the illustrated ezzxbodizneztt, dispatchers 214, 220 and 226 are associated with listeners 210, 216 and 222, respectively. Dispatchers 214, 220 aztd 22~
selectively route L O browser requests received by listeners z 10, ~ 1 s and 222 to cartridges.
For example, assume that listener 210 receives a browser request over the Internet 20$
w delivered in the form of a Unuifvrm Resource Locator (URL). The browser request serves as an identifier for a web object, for example an HTML page or an operation to be performed.
The listener 210 hands off the browser request to dispatcher 214 without any attempt at 15 interpreting the browser request. Upon receiving the browser request, the dispatcher 214:
(I) communicates with virtual path manager 250 to identify a cartridge selected by the browser request and to determine whether the cartridge requires authentication, (?) if the cartridge requires authentication, communicates with the authentication server 252 to determine whether the browser is allowed to access the selected cartridge, 20 (3) if access is authorized, communicates with th;e z~ourco manager to dcterniirLe the specific instance ofthe selected cartridge to which the browser request should be sent, and (4) creates and dispatches a revised browser request for execution by the specified instance of the cartridge.
The revised browser request repackages inlforlxlation received in the original browscr 25 request. The revised browser request rnay include, for example, a context abject that contains data required far the proper operation of the cartridge. The data required for proper operation of a cartridge inlay include, for example, a transaction ID that identifies a transaction with which the browser request is associated.
If the cartridge replies to the request, the cartridge sends the reply to the dispatcher and 30 the dispatcher passes the reply up to the listener for transmission to the browser that initiated the request.
CONFIGURATION PRO'V'IDER
According to one embodiment of the invention, cartridges that are to be used with web application server 280 are first registered with web application server 280.
During the _ , . _.

Kl:~. ~l).V:Ia':1-.111:L:WIIL::~ u'= :~-11 -:1:~ ~ .~..i .mo _. ~ _m w- rn:m.r .,:..~:~;~.mlu::.n...:

registration process, infoz~nation about the cartridges is supplied to the configuration provider 256. Conf guration provider 256 stares the information as >cuetadata 258 for later access by the eompoz~ents ofthe web application server Z80.
The metadata 258 may include, for example, (1 ) the cartridge name;
(2} the minimum number of required instances;
(3) the maximum number of instances;
(4) the location of the code that implements the cartridge;
(5) the pragram-dependent functia~i names used by the cartridge execution eng~izae to execute the callback functions (izuitialization, request handler, shutdown);
(6} a list of machines for running the cartz~idge;
(7) the idle time for the cartridge (the amount of time instances of the ca;txidge are allowed to remain idle before they aae shut down);

(8) an object identifier; and (9) data indicating the type of authentication service, if any, to be used with the cartridge.
The object identifier specifies the data that must be supplied by a bmwscr ncqnest for requesting performance of an operation by the corresponding cartridge. The object type xnay be a specific word, a ZIRL, yr may include a virtual path such as "/java".
Once the configuration provider 256 has stored the configuration information for a particular cartridge in the lnetadata 258, that cartridge is automatically registered when web application server 280 is started.
After a cartridge is registered with the w eb application server 280, the resource manager 254 initiates the minimum inlstances for the cartridge. Once the minimum nmnber of instances has been initiated, the web application server 280 is prepared to process browser requests.
THE VIRTUAL PATH MA~1AGER
As nnentioned above, dispatchers communicate with the virtual path manager 250 to determine where to route each revised browser re~,uest. Specifically, each browser request typically includes a UItL. Upon receiving a browser request, the dispatcher sends the URL in the request to the virtual path manager 250. The virtual path manager 250 responds by sending the dispatcher data that identifies the cartridge, if any, associated with the L~t.L.
In order to supply the required information to dispatchers, virtual path manager 250 consults the metadaia 258 that maps URLs to cartridges. rn response to receiving a brovcrser AiUENDED SHEET

ItW.lu.v:niy-.Nlb.wIIL.y ~y_ . .__ ~.v.i~'~~___ .°..'.' __ _ _ _~~!m -~y_s_yu=__ _r'r'J ct:J =;s:~al~_mir:i:rrv:.3 request, the virtual path manager 250 uses the mapping data to determine the cartridge, if any, to which the UItL contained in the browser requests corresponds.
For example, if the browser request is a URI, request beginning with the virtual path "/java", the mapping may indicate that the JA,'VA interpreter cartridge is configured to handle requests having the virtual path "ijava".
According to one embodiment of the invention, the virtual path manager 250 also determines whether the cartridge associated witH the URL requires authentication. If the cartridge requires authentication, the virtual path manager 250 indicates in the response that the virtual path manager ?50 sends to the dispatcher that authentication is required. If authentication is not required, the dispatcher creates and sends a revised brawser request to an instance of the cartridge without invoking the authentication server 252. If authentication is required, the dispatchar sends the revised request to an instance of the cartridge only a,ftcr the authentication server indicates that the revised request may be submitted to an instance of the cartridge.

'fhe resource manager 254 of the web application server 280 manages the execution of each of the cartridges by initiating a predetermined minirr~um number of instances for the cartridges, load balancing betvsreen the instances of each cartridge, and initiating new instances of cartridges as necessary up to a predetermined maximum number of instances of a given cartridge.
For example, assume that the metadata for a particular cartridge (C 1 ) includes the following information-Name = C I
lVlinimum instances = I O
Maximum Instances = 50 Host Machines = M 1, M3, M8 Idle time ~ 30 seconds Based on this metadata, when caz'tridge C1 is first registered, resot~ce manager 254 will initiate ten instances of CI . Resource manager 254 will initiate the ten instances on the machines associated with the labels M1, M3 and M8.
Upon receipt of requests from dispatchers to access C I, resource manager 254 determines whether any existing instance of CI is available for use. If no instance ofCl is ~~itrStiJGE~ SliEE1', !tt'1 , v u\ : LI'.1-VII~LW . I 11::v m_~ :3- 1 J -:)J : a : '.: t ~UUU =. 1 ~t~ m ~-. -r~i :ms:.~ ~iJ:l:l~l ~Ftii~ : y 1 available when a request is received, resource manager 254 determines whether the maximum number of instances of C1 are already running. If the maximum number of instances of C1 are not already running, then resource manager 254 initiates a new instance of Cl on one of the possible host machines and transmits a message that identifies the new instance to the dispatcher that issued the request. If the maximutxt number of instances of C1 are already running, then resource manager 254 sends a message to the dispatcher that issued the request to indicate that the request canztot be handled at this time.
LOAD >3Ai.ANCING
According to one embodiment of the invention, resource manager 254 applies a set of load balancing rules to determine where to initiate instances of cartridges where there is more than one possible host machine. Thus, in the above example, M 1, M2 and M3 are all capable of executing instances of cartridge C 1. If Ml, M2 and M3 have the same processing capacity, it may be desirable to distribute the instances evenly across the three machines. However, if M1 has tent times the processing power of M2 and M3, it may be desirable to initiate all instances of C 1 on M 1 up to a certain point, and then to distribute additional instances evenly among Ml, M2 and M3.
To assist resource manager 2d4 in determining how to load balance among possible machines, the metadata stored for each cartridge may include additional details. For example, the metadata ~atay specify a separate minimu.ut and maximum number of instances for each tztachine. Resource manager 254 rnay then distribute new instances among the machines based on which machine has the lowest ratio of actual instances to maximuzrt instances.
The zztetadata may also specify an order for the machines that can run a cartridge. The machine at the N+1 position in the order is only used to execute instances of the cartridge when the machine at the Nth position in the order is akeady executing its maximum number of instances.
CA~tTRIDGE INSTANCE STATUS TTtACK~NG
According to one etnbodimcnt of the invention, the resource manager 254 maintaizts state information to keep track of cartridge instaztces that have been created. The state information includes data that identifies the instance, identifies the machine executing the instance, and identifies the listener to which the instance has been assigned.
Figure 5 illustrates a table S00 that may be maintained by resource manager 254 to store this state information. Table 500 includes an instance column 502, a cartridge column 504, a listener column 506 and a zxtachine column 508. Each row of table 500 corresponds to a distinct cartridge instance. Wiihin the row for a given cartridge instance, cartridge column f ~ ~~ ".';1 i~..~_ -. n ~ ~ ~ ='r ~5i..~..... . , hl.~'. ~()~'~I~l'~1-:~II~L.~~IIIL;v W' _ .__..' 1 L-.'U:1.~ -~! _- _. _ _iv't' .t t.._-~'O~-__. .. r_~~' ".l -~:aJ~r;lw.~..~..., 504 identifies the cartridge associated with the cartridge instance and instance column 502 indicates the instance number of the cartridge instance. Fax example, row 510 corresponds to an instance of cartridge C 1. 'Wherefore, cartridge colutnzt 504 of row 510 indicates cartridge C1. Instance column 502 of row 510 indicates that the cartridge instance associated with row 510 is instance 1 of cartridge C 1.
histener column 506 indicates the listener to which the cartridge instance associated with a row has been assigned. Machine column 508 indicates the machine on which the cartridge instance associated with a row is executing. For example, the cutxidge instance associated with row 510 has been assigned tb listener 210 and is executing on machine M1.
Similar to resource manager 254, each dispatcher rnaintazns state information far the cartzidge instances that have been assigned to the listener to which the dispatcher is attached.
Such state information may be maintained, for example, in a table 400 as shown in Figure 4.
Similar to table 500, table 400 includes an instance column 402 and a cartridge column 404 that respectively hold instance numbers and cartridge identifiers. However, while table 500 I S includes one entry for every cartridge instance assi~ed by xesourcc manager 254, Eable 400 only includes entries for cartridge instances that have been assigned to a particular listener.
For example, table 400 includes entries for only those carfxidge instances listed in table 500 that have been assigned to listener 210.
In addition to instance column 402 and cartridge column 404, table 400 includes a status column 406. For each row, the status column 406 holds a value that indicates the status of the instance associated with the row. For example, the status column 40b of row 408 indicates that instance 1 of cartridge C 1 is currently busy. In the illustrated embodiment, the status column 406 holds a flag that indicates that a cartridge instance is either HUS~C' or FREE.
The significance of the cartridge status shall now be describe with reference to the operation of resource manager 254 and dispatchers 214 and 220.
INTERACTION HETyVEEN DISPATCHERS AND
THE RESOURCE MANAGIrR
As explained about, dispatchers communicate with resource manager 254 when they need to send a revised browser request to a particular cartzidge. According to one embodiment of the invention, dispatchers first determine whether an instance of the appropriate cartridge (1) has already been assigned to it and (2) is available to process the new revised browser request. If an appropriate cartridge instance has already been assigned to the dispatcher and is currently available to process the new revised browscr zequest, then the dispatcher forwards ,n-. , 1i(:1. 1Ui\:I:1'A-lllL~l~l.lll~y ~1'= _ . ___~..,1 t,-J:~.___ _ .... __ _. _ _'iw~<> W 1..=='!" ._. ._ r_~;~ ~;~ =Jalwl_lw..l..:_m the revised browser request to the cartridge instance without further communication with resource manager 254.
For example, assume that listener 210 receives a browser request that, according to virtual path manager 250, must be processed by cartridge C1. Assumle also that table 400 reflects the current list and status ofeartridge instances that have been assigned to listener 210.
Upon receiving the browser request from listener 210, dispatcher 214 inspects table 400 to locate a F1ZEE instance of cartridge C1. In the illustrated table 400, row 410 indicates that instance 3 of cartridge C 1 is currently FREE. Consequently, dispatcher Z Z 4 forwards a revised browser request directly to instance 3 of cartridge C1 without fiuther communication I O with resource manager 254. In response to sending the revised browser request, dispatcher 214 changes the status value in status column 406 ofrow 410 to BUSY.
If a listener has not already been assigned an appropriate cartridge instance that is cuzrently available, then the dispatcher associated with the cartridge requests a cartridge instance from the resource manager 254. if the resource manager 254 determines that an 15 instance of the requiz'ed cartridge is not available and the number of existing instances of the rerluired eamidge is below the maximum, then the resource manager 254 initiates a new cartridge. Upon initiating a new cartridge, the resource manager 254 inserts an entry for the new cartridge instance in table 500.
Assume, for example, that listener 210 receives a browser request that must be 20 processed by cartridge C3. Assume also that instance 3 of cartridge C3 has not yet been initiated. Under these conditions, dispatcher 214 sends to resource manager 254 a request for a handle to an izistance of cartridge C3. In response to this request, resource manager 254 --'; initiates instance 3 of cartridge C3 on machine M3. In addition, resource manager 254 inserts into table 500 the entry found at row 512.
25 After inserting row 512 for instance 3 of cartridge C3 in table 500, resource manager 254 sends back to the dispatcher 214 a handle to the newly created instance.
In rrsponse to receiving this handle, dispatcher 214 inserts an entry (row 412) for the new instance in its status table 400. The dispatcher 214 then transmits a revised browser request to ilz~stance 3 of cartridge C3.

According to one embodiment of the invention, listeners do not automatically release ownership of cartridge instances when the cartridge instances finish responding to outstanding browser requests. For example, assume that instance 3 of cartridge C3 receives a revised browser request, processes the revised browser request, and sends a response back to ~ ~l'.i a ~: ~ i...

It1:4.41):a:l~;t'J\-~4llL:\1;111::v ~1'!_ .___'x.'11-:~;~___ _t='a ~.__ _ _ _'~'~!~ -_'..cWa =_ _T'!~ uJ =J:r:ru.nu.~.N_~

dispatcher 214. Dispatcher 214 passes the response to listener 2I0 to be sent back tv the browser that issued the browser request.
At this point, listener Z10 no longer requires ownership of instance 3 of cartridge C3.
However, rather thaw transferring ownership of instance 3 of cartridge C3 back to z~esauxce manager 254, dispatcher 214 merely changes the status column 406 of zow 412 from BUSY to FREE.
Chaztgixtg the value in status column 406 of row 412 to FREE indicates that instance 3 of cartridge C3 is no longer worldug on a request, and is therefore ready to handle subsequent requests. However, because table 400; whieTr indicates that instaxxce 3 of cartridge C3 is available, is maintained locally by dispatcher 214, instance 3 of cartridge C3 is only available for subsequent browser requests arriving at listener 2I0. Row 512 of table 500 maintained by resource manager 254 cont~ir~ues to indicate that instance 3 of cartridge C3 is owned by listener 210.
Because listeners do not automatically release cartridge instances every time a request is serviced, overhead associated with comuruxtication between the resource manager 254 and the various dispatchers is signifccantly reduced. For example, assuxne that a listener 210 receives ten successive requests that must be cammunicated to cartridge C3.
Rather than communicating with resource manager 254 for each of the ten requests, dispa.teher 214 may connmunicate with resource manager 254 in response to the first request. The subsequent nine requests can be handled by dispatcher 214 without communicating with resource manager 254 because the dispatcher 2I4 uses the same instance of C3 that processes the first request to process the nine subsequent requests.
Wluile not automatically releasing listener ownership of cartridge instances when each request is serviced can increase the efi~ciency of web application server 280, listeners cannot maintain ownership of cartridge instances indefinitely. For example, instances that have not been used for long periods of time should be passed back to the resource ma.cxager 254 so they can be de-allocated to free up resources. in addition, it is nor efficient for one listener to maintain ownership of the instance of a cartzidge that it has not used for a relatively long time when other listeners requixe instances of that cartridge.
Consequently, resource manager 254 communicates to each listener a maximum idle time for each cartzidge instance passed to the listener. The maximum idle time indicates the maximum amount of tune a cartridge instance can go unused before the listener must release ownership of the cartridge instance. For example, assume that the resource manager 254 indicates to listener 210 that the maximum amount of idle time for instance 3 ofcartridge C3 KC\.WV:t_yA-dilL:vcl~L\ U1_ . . .__.'-11-.:3~_._ _3.~-'.3 '.__ _._ _~ua .'rt..~:31a=_.._~r=j u:~:~;i:~a.1-ltis:~,_yt -1 g-is 10 minutes. Based on this information, listener 210 may co~atznue to use instance 3 of cartridge C3 to process bmwscr requests for cartridge C3 as long as instance 3 of cartridge C3 does not remain idle or FREE for more than 10 minutes.
If izastance 3 of cartridge C3 is idle far more than 10 minutes, dispatcher 214 removes xow 412 from table 400 and sends a message to resource manager 254 that listener 210 is releasing ownership of instance 3 of caxbcidge C3. In response to this message, resource manager 254 updates row 512 to indicate that instance 3 of cartridge C3 is not owned by any listener and may thus be reassigned to another listener or terminated.
In an alternative embodiment, dispatchers do not automatically release cartridge instances when the idle time for the cartridge instance has expired. Instead, the dispatcher sends a message to resource manager 254 offering to release the expired instance. Resource manager 254 may respond to the offer by requesting that the listener release the cartridge instance, or by allowing the listener to retaua ownership of the expired cartridge instance.
According to one cmbodiouent of the invention, resource manager 254 maintains a I5 queue of the requests that carmot be immediately serviced. When it becomes possible to service a queued request, the request is z'ernoved from the queue and processed.
For example, assume that listener 222 receives a browser request that must be processed by cartridge C1, and that listener 222 has not been assigned any instances of cartridge C 1. Dispatcher 226 sends a request for an instance of C 1 to resource manager 254.
Assume further that a xrlaximum of 50 instances of C1 are allowed, and that 50 instances of C1 have been assigned to listener 210. Under these conditions, resource manager 2S4 cannot service the request from listener 222. Therefore, resource manager 254 puts the request on a queue. When listener 210 releases an instance of C1, resource manager 254 communicates to listenez 222 that an instance of C 1 is available.
Under certaita conditions, resource manager 254 znay preemptively cause a listener to release a cartridge instance. Far example, rcsouzce manager 254 may detect a system overload situation and respond by terminating a set of cartridge instances, either befoze or after informing the listeners that currently have been assigned the cartridge instances that the cartridge instances are going to be terminated.
Resource manager 254 may also preemptively cause listeners to release cartridge instances to implement fairness policies between listeners. For example, reso»ce manager 254 may cause a listener that holds the most instataccs of a given cartridge to release an instance of the cartridge when another listener has waited more than a predetermined threshold of amount of time for an instance of the cartridge. For example, if listener 210 has been ~~~nc~~~ sNEEt .

kCI.W h\:~I':\-~lll~LW:IIL:~\ u_!_ .__=?.-.il-J:J_-_ _s='as '.__ _._ _'~~um ::~1.,__3)u =_.._*~u t~:r =a_:1:!'1--ivi:~:rt_':~

assigned 50 i~astanlccs of cartridge C1 and C1 has a maximum of 50 instances, then resource manager 254 may cause listener 210 to release an instance of C1 ten seconds after receiving a request for an instance of C1 from another listener.
CARTRIDGE EXECUTION ENGINES
According to one embodiment of the invention, each cartridge instance is composed of a cartridge execution engine and a cartridge. A carhridge execution engine is a cede module that insulates cartridges from the complexities of the web application server 280 and the inter-module communication mechanism. A cartridge is made available to a cartridge execution engine by storing in a function table painters to the cartridge functions.
According to one embodiment, all cartridges provide the functions specified in the exemplary cartridge interface described above. By haviz>,g all cartridges Support the same interface, a single standard cartridge execution engine can be used with all cartridges.
According to one embodiment of the invention, cartridges aze iznplemented as shared libraries, 'and cartridge execution engines are executable programs that invoke the routines in the shared libraries using the standard cartridge interface. The cartridge execution engine provides the interface between caztridges and the dispatcher, dizeets cartridge flow of control, and provides services far cartridges to use.
When the resource manager 254 requires the creation of a new cartridge instance, the resource manager 254 causes a cartridge execution engine to be instantxated.
In rum, the instance of the cartzidge execution engine thus created causes the appropriate cartridge to be instantiated. The resource manager 254 can cause the cartridge execution engine to be instantiated, for c.~ample, by invoking a "cartridge execution engine factory"
that zesidt$ oz~
. , the machine on which the carizidge is to be executed. The instance of the cartridge execution engine can cause the cartridge to be instantiated, for example, by malting a call to oue of the routines in the shared library that constitutes the cartridge.
As shown in Figure 2, the web application server 280 includes cartridge execution engines 228, 232 and 236 for each of the cartridges 230, 234 and 238. The camidge execution engines control execution of the instances of the concesponding cartridges by rxaaking calls into the cartridges through the standard cartridge interface. By establishing basic callback functions between the cartridge execution engine and a cartridge, any cartridge can be integrated into the web application server 280 by configuring the cartridge to respond to the callback functions, and then zegistering the cartridge in the Configuration provider 256, as descn'bed below.
Thus, if the dispatcher 214 determines that the PL/SQL runtime cartridge is the appropriate cartridge to process a request, the dispatcher 214 dispatches the request to a ~,l,~~r_i~.l~: i_ ~ ~ ~1-iEL~

h:(:~ . ~ U\ : ~l'A-X11: ~\l'lll:n W~ a- i l -:1J : : S : W t . uuti _ ~ 1 .u :1:- r~t~:J tS.J =:~:;:mwiw.~ . ,i:_w cartridge instance that includes a cartridge execution engine gssociatcd wits the PL/SQL
runtime cartridge.. If a new instance needs to be initiated, the resource manager 254 creates a new instance of the PL/SQL runtime eartxidgr in a separate address space and dispatches the request to the cartridge execution engine 228 of the new instance. The address space used to execute the instance of the program znay be within memory of the computer system upon which one or more of the components of web application server 2$0 is executing, or on another computer system.
In response to a message from a dispatcher, the cartridge execution engine issues a request handler callback futxction to the cartridge, causing the cartridge to process the request.
The cartridge executing the request returns the result to the cartridge execution engine, which forwards the result to the dispatcher. In the event that the web application server 280 detects a fault in the operation, the cartridge execution engine issues a shutdown function of the cartridge_ Hence, the cartridge execution engine provides an application programming interface to the web application server 280 that specifies predetermined operations to be performed.
Use of the standard cartridge interface enables progratruxiers of the cartridges to configure each cartridge for high-level integration into the web application server 280 independent of the protocols used by the particular web listener with which the cartridge will be used.
za TRANSPORT ADAPTERS
f,isteners enable the use of server-side plug-ins by providing a programming interface and protocol for use by such plug-ins. Unfortunately, the programming interfaces and protocols provided by listeners vary froui listener to listener. For example, Netscape Server Application Programming Interface (NSAPI), Internet Server Application Prograrrzming z5 Interface (ISAP~ and Application Development Interface (ADI) are three examples of distinct programming interfaces currently provided by listeners.
Transport adapters insulate dispatchers from the proptietary protocols and interfaces used by web listeners. Specifically, each transport adapter is configured to recognize the protocols ofdiffcrent listeners, and to convert the browser requests received from the listeners 34 into converted bzowser requests having a standard dispatcher protocol that is independent from the protocol of the listener. Similarly, transport adapters convert the replies from the dispatcher to the transport protocol of the listeners.

. _' w ,. . , ~C:4.lUV:L1'r1-~111:L~i(:Ilt~:\ !i:.'_ . . .__ L'-11'.JU___ _'1'~'1' .__ _._ _'I~U~ '-'-~1,.=_sl~i =_. ._.*_wi ~J :_a:J:rl-tv:.~:rlal fence, the transport adapter enables the web application server 280 to be used with listeners from different vendors. Moxaa~er, transport adapters may be configured to accommodate different server architectures and operating systems.
OPERATION OF THE WEB APPLrCATION SERVER
Figures 3A and 3B are a flaw diagram illustrating s method of responding to a browser request according to and embodiment of the present invezttion. The browser request is received in step 350 by a listener. For the purposes of explanation, it shall be assumed that the browser request was issued by browscr 202 and received by listener 2I0.
Upon receiving the browser request, the listener 210 forwards the request to the web application server 280 in step 352. Specifically, listener 210 passes the request to the transport adapter 2X2 using the proprietary programming interface of the listener 210.
The transport adapter 212 converts the request as necessary to pass the request to dispatcher 214 using a standard dispatcher programming interface.
laispatcher 214 identifies the request object type that corresponds to the browser request in step 354 based on the virtual path specified in the browser request by communicating with the virtual path manager 250. If the request obj ect type corresponds to a cartridge, the virtual path manager also indicates to the dispatcher 214 whether authentication is required.
The dispatcher 214 determines in step 356 if the request object type corresponds to an identifiable cartridge. If the request object type does not correspond to an identifiable cartridge, the request is resumed to the listener 210 in step 358 (see Figure 313). Ifin step 358 the listtner 210 recogni2es the request as a request for a static FITML page, the listener accesses the static HTML page, and sends the HTIVIx, page to the browser 202 in step 360. If the browser request is not recognized by the listener 210, the reply is sent to the browser 202 in step 360 indicating that the request was unrecognizable.
If in step 356 the dispatcher 214 determines that the request must be sent to a cartridge, then the dispatcher performs any necessary authentication by eonntriunicating with the authentication server 252. The authentication process will be described in greater detail hereafter. In addition, if in step 3S6 it is determined that listener 210 has not been assigned any instances of that cartridge that are currently FREE, then the dispatcher 214 coxnrnutucates with the resource manager 254 to be assigned an instance of the cartridge 230 to whzeh the browser request can be stet.
In step 362, shown in Figure 3B, the resource manager 254 determines whether an instance of the identified cartridge is available (unowned) among the existing number of il::~._ , . ,., , IZC:\ . 1 c),\: LNt1-\ll:li\l:lil~:y u'' _ . . . . __!'_',t .i -.a;J _~ _~i._-~l. _ _ _ . _ __3'~'Z3 .° i 1_.'_-'._3l U __ . _ ~ '~ fi~ '~~3''.3'.1~!-~l~tiu : n ~s~' instances. For the purposes of explanation, it shall be assumed that the request is associated with cartridge 230, and that cartridge 230 is a fL/SQL z'uatinie cartridge.
If in step 362 the resource manager identit~cs an available instance, for example instance 260 of the PL/SQL runtime 230, the resource manager 254 informs the dispatcher 214 that the request should be sent to instance 260. The dispatcher 214 them creates and sends a revised browser request to the cartridge execution engine 228 of the instance 260 in step 368 to cause the available instance 260 to process the request, as described below.
However, if in step 362 no instance of the cartridge 230 is available, the resource rxianagcr 254 dotermines in step 364 if the existing number of irxstances exceeds a maximum prescribed number. If the existing number of instances exceeds the maximum prescribed number iza step 364, the resource manager 254 indicates to the dispatcher 214 that the request cannot be processed at this time. In response, the dispatcher 214 returns the request to the listener 210 in step 358, after which the web listener 2I0 sends a reply to the brov~~ser 202 over the network in step 360 indicating the request was not processed.
Alternatively, when a cartridge instance is not currently available to handle a request, listener 210 may place the request on a waiting list for that cartridge instance. When a cartridge instance becomes available, the revised browser request is removed firm the waiting list and forwarded to the cartridge instance. If the revised browser request rerxlains on the waiting list for rtaore than a predetermined amount of time, listener 210 may remove the request from the waiting list and send a message to the browser 202 to indicate that the request could not be processed.
If in step 364 the existing number ofinstances does not exceed the maximums prescribed number, the cesource manager 254 initiates a new instance of the idenGficd program and infozms the dispatcher 214 that a revised browser request based on the browstr request should be sent to the new instance. 'fhe dispatcher 214 then dispatches a revised browser request to the cartridge execution engine of the new instance.
For example, assume that the resource manager 254 initiated instance 260 in response to the browser request. poring the initialization, the stored sequences of instructions for the PL/SQL runtime are accessed to create a new instaxiee 260 ofthe cartridge 230 in an address space that is separate frorzx the address space in which dispatcher 214 is executing. According to one embodiment, initialization is performed by loading the cartridge execution engine 228 and having the cartridge execution engine call the initialization routine in cartridge 230.
Once the n~cw instactce 260 is running, the dispatcher 214 dispatches the request to the cartridge execution engine 228 associated with the new instance 260 in step 368. The cartridge AA~IENDED SHEET

~tC~ . ~ o\ : l~.Nr1-VII: I:,\c:lUl::: uy _ . __ ~ W 1. -~:) _ __ . j.-'.~ '.
_ _ _ . _ ~yts '-: ~ 1 . _;l 1u =_ . _ +'1u ~~ :-~~~~~:p : r~~3:-i execution engine 228 sends a callback message tv the new instance 260 requesting execution ofthe request. ~n the callback rnlessagc, the cartridge execution engine 228 passes any parameters necessary for the instance 260 to process the request. Such parameters may include, for example, passwords, database s~ac~ch keys, or any other argument for a dynamic operation executed by the instance 260.
The instance 260 then executes the request. Dozing the execution of the request by the instance in step 368, the dispatcher 214 nrlonitors the instance to determine the occurrence of a fault in step 370. If in step 370 the dispatcher 214 detects a fault, the dispatcher 214 caps the corresponding cartridge execution enginc'228 in step 372 to abort the instance 260 having the fault. The corresponding cartridge execution engine 228 in tom issues a shut down conunand across the APZ to the faulty instance. The instance, responding to the shut doRm command by the cartzidgc execution engine Z28, will shut down withaut affecting any other process in any other address space.
If in step 370 rlo fault is detected, the dispatcher 214 receives a reply fronx the instance 250 upon completion of execution in step 374. The dispatcher 214 in step 375 forwards the reply to the listener 210, which responds to the browser with the reply from the executed instance 260. AEer executing the instance 260, the dispatcher 214 in step 378 maintains the instance in the memory, as shown in step 378 to enable cx~cution of a subsequent request.
DISTRIBUTED ARCHITECT'CTRE OF WEB SERVER
Significantly, the various components of the vV~cb application server 280 communicate with each other using a communuication mechanism that does not require the components to be executing in the same address sparse or even on the same machine. Tn the illustrated embodiment, the components of the web application server 280 are configured to communicate through an Object Request Hroker (ORB) 282. Object Request BrokeTS
are descn'bed in detail in "Common Object Request Broker: Architecture and Specification (CORBA)" . This and other documents relating to CORBA can be found on the World Wide Web at http:/lwww.omg.org.
While the embodiments of the present invention shall be described with reference to communications through a CORBA-compliant ORB, othez- cross-platform communication mechanisms may be used. For example, the components of web application server 280 znay alternatively communicate with each other using Remote Procedure Calls (RPC), a TJNIX
pipe, Microsoft COM.
Because the various components of the web application server 280 communicate with each other using a machine independent communication mechanism, there ate no inherent Ai~Fl:idpED SHEET, ~IZC~'. 1'U:\:t:l'A-VII:I:WItt~i U:1- .__ ~..'.O:-.'~~'.3___ ~_=6 '.__ _. _ _'~~!u v_ l..-Uln =_. ._~'t~;~ ti:) ,:.-!'J;lf~Etiti:pa;~b -2a-restrictions with respect to where the components arc located with respect to each other. For example, listeners 210, 216 arid 222 may be executing on the same machine, or on three completely different machines, each with a diff'er~nt operating system.
Sinularly, the authentication server 252, virtual path manager 250, resource manager Z5~1 and conf guration provider 256 may be executing on the same machine or on four different machines. Further, those four different machines may not have any overlap with the three machines executing listeners 210, 216 and 222.
Cartridge e~cecution engines ~8,,~232 and 236 incorporate all of the necessary Iogic to communicate with the other components of the web application server 280 through the object request broker 282. Consequently, the location of the cartridge instances thcn~elvcs is not inherently restricted by the cor»munication rrAechanism. Thus, instance 260 may be executing in a completely different machine and operating system than dispatchers from which it receives requests. Irikewise, instance ?60 tray be on a different machine and operating system than the resource manager 254 or any of the other components of the web application server I S 280, including instances of other cartridges that are being managed by the same web .
application server 280.
Significantly, the location-independence enjoyed by cartridges used by web application server 280 is achieved through the cartridge execution engine communication logic, not through any custom programauing in the caztridges themselves.
Consequently, the cartridges do not need to be specially designed for execution in a distributed application server environment. Cartridge designers are thus insulated from the comple.cities of a distributed system, and can concentrate their efforts on the logic associated with the tasks far which the cartridges were created.
PROCESSING TRANSACTIONS
According to an embodiment of the invention, transactions are implemented in a stateless environment through the use of metadata that indicates specific information for specific types of transactions. A piece of information about a transaction that is supplied in the metadata is referred to herein as an attribute of the transaction. The use of metadata to indicate specific attributes of a transaction, allows for a system in which cartridges az~e not required to persistently maintain state infonn3tion. Transactions izx such a system are declarative rather than programmatic in that the messages themselves indicate the transactions w which they belong. For example, the metadata for two particular types of txansactions, TX1 arc'. 'TX2, could be as follows:
[TXI]
ca o23ossoi Zooo-o4-is '~e,~w~E~ SHEET
'~~.W :.t~

RC\ . \ (h~i: i?I'A-~Itl!L:~C.'111'.'.\ ~!_' :~- l l -Vii.) : ~i : _y: :1.()ti '.! i l =:)1 V-~ t-1;J t3;1 '?:.ia~.J~l--~EiS : II:.iS

[sT01?EFRONT] ..
naive = STOREACCOUNTS
belong-to-list = (STOREFRONT
BANKING
resource-list = !SEARS
BANTtl begin = Istorefront/apen session commit = /storefront/commit session rollback = lstorefrontlrollbac~k session [TX2]
[EMPLO~'EE]
name ~ EI~P~,O'Y'EEACCOLJNTS
belong-to-list = IEMP>:,OYEE
BANKrNG
resource-list ~ /PERSONNEL

begin ~ /employeelopen session commit = /employeeJcommit session rollback = /employee/rollback session For each type of transaction the metadata includes various attributes.
According to one embodiment, the attributes include a cartridge name, a transaction name, a belong-to-list, a resource-list, begin, commit and rollback TRANSACTrO'N LTRLs. In the example girren above, the cartridge name for TX1, is STOREFRONT, the transaction name is STQREACCOLJIVTS, the belong-to-list consists of /STOREFRONT and BANKING, the resource-list consists ofISEARS and BANK(, the begin transaction URL is /storefrontlopen session, the commit transaction tJRI. is Jstorefrontlconurlit session and the rohbaek transaction UR,L is /storefrontlrollback session.
The cartridge name attribute identifies the particular type of cartcidgc that the w dispatcher communicates with to perform the operations of the transaction. The transaction name attribute uniquely identifies the type of transaction relative to other transaction types.
The belong-to-list of a transaction type lists the cartridges that may participate in the performance of the transaction. The resource-list is the list of resources that are affected by the performance of transactions that are of the transaction type. The begin transaction UR.L is the T,JR.L that signals that a transaction of this type is about to begin. The commit transaction URL

~,, C .,~ r ;:
n,an . ...
~'~::w.' t-....r "... ",...,.,._ _. ~ __ __ _ ___..._. ___ _ _. __ _ _ ____ _ . ______ _ _._.
__ _ is the IJRL that signals that a transaction of this type that is currently in progress should be committed. The rollback transacMon URL is the URL that signals that a transaction of this type that has already started should be rolled back. How each of these attribute values is used during the performance of a transaction shall be described in greater detail below.
TRr~N'SACTION OVER~1IEW
Figure b is a block diagram of a system 600 that provides for the processing of multiple-request transactions in a stateless environment according to one embodiment of the invention. Figure 6 is similar to Figure 2 and therefore like components have been numbered alike. Within this document, the term brow ~r request and the term transaction request ace used interchangeably. The ternn multiple-request transaction is used to refer to a single transaction that is comprised of two or more browser requests.
As described earlier, cartridge execution engine 228 communicates with a pluzality of dispatchers (e.g. one or more of dispatchers 214, 220 and 226) through object request bmker 282 to receive browser messages. These browser messages may be sent from a plurality of browsers connected to the Internet 208. Irt addition t4 the plurality of dispatchers, cartridge execution engine 228 also communicates with a cartridge 230, configuration provider 256 and transaction manager 606. As previously described above, the cartridge 230 represents a znadule of coda that is either conf gored as a cartridge that performs a well-defined function, or as a prograixtmablc cartridge that acts as an interpreter or a routine environment for an application. The combination of cartridge executive engine 228, tzansaction manager 806 and cartridge 230 constitute a cartridge instance.
A, particular cartridge may be associated with a plurality of database servers for access to a plurality of databases. In this example, cartridge 230 has the ability to process database transactions according to the Structured Query Language (SQL) by accessing database 610 2~ and database 6 l 4 through database server 608 and database server 612 respectively.
Transaction manager 606 represents a coordinating znodulc that is associated with carnidge execution engine 22$ and functions to coordinate the execution of mulCiple-request transactions in the stateless web environment. In coordinating the execution of multiple-request transactions, transaction manager 606 retains no state information for the rnultiple-request transactions. The transaction manager 606 communicates with cartridge execution engine 228 to receive transaction control messages. Using the information contained in the transaction control messages, the transaction manager 606 interacts with database servers 608 and 512 to cause changes made during multiple-request transactions to respective databases 610 and 614 to be either committed or rolled back as am atomic unit of work.

AMENDED SHEET

I\L~. 1ll\~L.1,1\-1111).vv.lA...:-. .. . .-._. . -. . . ._. ~-~.~ ... -.- .---.. .....---.. ..._... . .. .. ~..u .. i.

T~ENTIFYIN(I ?RANSACTIONS
Browser requests that arc associated with multiple-request transactions include a globally unique transaction 1p. The globally uluque transaction ID within a browser r~uest is used to identify the multiple-request transaction to which the browser request belongs.
According to one embodiment, when a browser request is recei~,~ed that contains a begin transaction UItL, the transaction n~at~ager creates a globally unique transaction ID. This globally unique transaction ID is returned to the sending browser, and is sent by the brow~ser in subsequent browser requests that are associated with the same multiple-request transaction.
In certain em6odzrnents, when retuzned to the browser from which a multiple-request transaction was initiated, the globally unique transaction ID associated with the particular multiple-request transaction is stored as coolie information on the client executing the ,. browsar. When a subsequent browser request is sent by the browser, the dispatcher determines if the subsequent request contains a begin transaction UrRL. If the request does not contain a begin transaction URL, then the dispatcher obtains the globally unique transaction ID
associated with the browser request by reading the sending browser's cooltie information using the HTTP protocol standards.
For example, when a brawser 202 sends a first browser request associated with a tzansaction and a begin transaction IJRh, the transaction manager 606 creates a unique browser identifier and sends it to the dispatcher 214. The dispatcher 214 then causes the globally unique transaction ID to be stored as cookie information on browser 202, fVhen browser 202 sends a sexond browser request that is associated with the same transaction, the dispatcher 214 obtains the globally unique transaction ~ contained in the cookie information - of browser 202. ~~
Using the globally unique transaction ID, the database servers that ultimately process the browser request can determine that both the first browser request and the second browser request are associated with the same multiple-request transaction. Because a particular browser may be executing more than one transaction at a time, in certaizs embodiments, the cartridge name for the particular transaction is contained within each globally unique transaction ID and is used to help idontif~ the particular transaction to which the globally unique transaction ID corresponds.
In certain situations cookie information may not be available on a particular browser.
For example, a particular browser may not support the use of cookies or a particular user may choose to deny access to the browser cookie information. Therefore, in certain embodiments, the transaction identifiers are embedded in the messages returned to a browser, and sent out by Ai~hCNDED SHEET

hl.\. \ll.\~L:l't1-.lll.l:.v1111:.1 W w11 :~..~ . .~~m ,.., .._. _. _.. __ __ ... ..__...._.. .._.. _._. .__ .._ ____ ._ ..______.. _.____ . .-_m~_'y..r.. ...i., -2 $-the browser in subsequent browser requests. This can be accomplished by annotating the URLs that are associated with the hyperlinks of the I~TMh page that is returned to the b~wser 202. Based upon the globally unique transaction ID that is sent out as part of the browser request tJRI,, the database servers that ultimately perform the operations specified.in the browser requests can use the globally unique transaction lIa to identify ttzo multiple-reduest transaction to which each particular browser request belongs.
TRANSACTION CARTRIl7Cr$ INSTANTIATiON
Each browser request contains URL information that is sent from the sending browser in response to a user of the browser selecting a hypertext fink on an HTML
page. The URL
information includes a Uniform I~esourct Indicator {tIRI) portion and a header section. The URI portion includes transaction state information and a cartridge name. The transaction state information is used to identify the particular state of a multiple-request transaction. The cartridge name is used to idtntify the cartridge type and allows the cartzidge execution engine to identify the metadata that is associated with the browser request.
The header section is used to store a globally unique transaction JD that is used by the database servers to identify the multiple-request transaction that is associated with a particular transaction request.
When a listener receives the bzowser request, it passes the browser request to the dispatcher. The dispatcher then communicates with the virtual path manager to determine the cartridge type that is associated with the browser request. In ono embodiment, the dispatcher forwards the information contained in the URI to the virtual path manager.
Using the information in the URI, the virtual path manager communicates with the configuration provider to determine the cartridge type that is associated with the browser message.
Once the cartridge type is identified, the virtual path manager returns data that identifies the cartridge type to the dispatcher. The dispatcher then searches a cartridge instance pointer list that includes pointers to cartridge instances that have previously been associated with the particular dispatcher. If the dispatcher locates a pointer to a earn-idge instance that is of the cartridge type that is associated with the browscr request, the dispatcher uses the pointer to send a revised browser message to the cartridge instance.
If the dispatcher does not locate a pointer to the type of catrtridge instance that is associated with the brawscr request, the dispatcher communicates with the resource manager to obtain a cartridge instance of that type. In obtaining the cartridge instance, the dispatcher sends a message to the resource manager that includes the cartridge type that was previously identified by the virtual path manager.

i~i.:~!.~!'~;_~) ._, ;HEi?' Kl.v. WW ~uW -,u ~:.wu-.. ~ ~. .. ...

Upon receiving the dispatcher message, the resource manager determines if a cartridge instance of the request type is available for use by searching a cartridge instance pointer table.
if a cartridge instance pointer of the requested type is located in the cartridge instance pointer table, the resource manager sends a pointer to the available cartridge instance back to the dispatcher.
However, if a cartridge instance of the requested type is not available, the resource manager causes a cartridge instance of the request type to be instantiated.
In one embodiment of the invention, the resource manager causes a cartzidge instance of the requested type to be instantiated by request~g a particular cartridge factory process to create a cartridge instance of the request type. Cartridge factory processes rnay be located across multiple machines. When a particular cartridge factory process is requested to instantiate a cartridge instance, it instantiates the cartridge instance on the same machine that the caztridge factory is currently executing on. Therefore, the resource manager selects which cartridge factory to use based an the particular machine the resource manager chooses to instantiate the cartridge instance.
Upon receiving a request to instantiate a cartzidge instance, the cartridge factory process instantiates an instance of a cartridge execution engine. Once the cartridge execution engine is instantiated, the cartridge execution engine obtains the transaetian information, if any, that is associated with the requested cartridge type. For example, if the requested cartridge type is of type STOREFRONT as described in Txl above, the cartridge execution engine obtains and stores the metadata information that is associated with TX1. This metadata information is used by the cartridge instance to process transactions.
After obtaining the metadata information, the cartridge execution engine instantiates a cartridge of the requested camidge type. The instance of the caztzidge that is created is dynamically linked with the cartridge execution engine. The cartridge execution engine then instantiates a transactian manager. The transaction manager instance is dynamically linked with the cartridge and the cartridge executiozr angina to form a cartridge instance.
Once the cartridge instance is formed, the transaction mazaager uses the metadata information that was previously stored by the cartridge execution engine to open conaecdons with the databases that were identified in the resource-list of the metadata.
These connections are retained by the transaction manager and later used to provide database handles to the associated cartridge and to control the processing of multiple-request transactions. Foz example, if the requested cartridge type is of type STOREFRONT, the resource-list is associated with a SEARS and 13ANK1 database. Using the resource-list information, the .r'.:' .

m.~ . ~v.v.m .ysu u.~,wn_.~ ... _ __='-.~ ~.-.~;:'-__ _'-- __ _._ -':: .
_'..=W'_'___. ._ .____ . . ._ _ . .~ . ... .

transaction manager vpcns a connection with the SEARS database and the B_4NK1 database by respectively estabIis~uing connections with the database servers associated. with the SEARS
and $ANKl databases. These connections are retained by the transaction manager and ate used fvr processing transactions of type TXI.
After the transaction manager establishes its connectians with the appropriate databases (i.e. through the database servers associated with the appropriate databases), the cartridge execution engine notifies the cartridge factory that a cartridge instance has been instantiated by returning a pointer to the cartridge instance back to the cartridge factory. Upon receiving the cartridge instance pointer, the cartridge factory sends the caztridge instance pointer to the resource manager.
The resource manager then registers the cartridge instance pointer into its cartridge .. instance poiunter table. The resource manager then sends the cartridge instance pointer to the dispatcher. LTpon receiving the cartridge instance pointer from tlao resource manager, the dispatcher stores the cartridge instance pointer into its associated cartridge instance pointet~
list. The dispatcher then uses the cartridge instance pointer to send a revised browser message to the cartridge instance.
CREATING REVISED HROWSER MESSAGES
Upon obtaining a cartridge instance pointer, the dispatcher creates a revised browser message using the information associated with the browser request. This revised browser message includes the URT, header information, the cartridge type and a dispatcher pointer that allows messages to be returned to the dispatcher. For example, a revised messaga for a transaction of type T~1 as described above, may include the following information:
URI = lstorefrontlopcn session header = N'C.JhL
cartridge name = [STOREFRONT]
dispatcher pointer ~ address ~7CXx 1n this example, the LTR~ is a begin transaction URI (a C)~ that is used by the cartridge execution engine to identify the beginning of a multiple-request transaction).
Because the URI is a begin. transaction LJRI, a globally unique transaction XD has not yet been associated with the multiple-request transaction. Hake, the header that would contain the transaction ID
is set tv NULL. For ongoing multiple-rcduest transactions (i.e. when the browser request does not contain a URI of /storefront/open session)and in Which cookies are used to store the globally unique transaction ID, the header will contain the unique transaction ID. This unique ~~::;._ ~ -~ .
-~.J

I~l.\.1\/.\~1~1,:1-lllL.\t.tii. '-- .. . .---...m.. ~ ..... ~..~.. .-. .._ .... .. .......--~..-.__-- . . . .. ~~.. ...

transaction ID allows the database servers to associate a transaction request with an ongoing multiple-request transaction.
The cartridge name identifies the cartridge type and is used by the cartridge execution engine to identify the metadata that contains information about the transaction type associated with the particular browser request. In this example, the cartridge name of STOREFRONT
identifies the rnetadata associated with TX1 as being associated with the browser request.
After creating the revised browser message, the dispatcher uses the previously obtained cartridge instance pointer to send the revised browser message to the cartridge instance. 'When tlae cartridge instance receives the revised l~rowser message, the caztridgc instance uses the caztridge type information to identify the metadata that is associated 'with the browser request.
A,fier identifying the nretadata, the cartridge execution engine uses the URI
information to detcrrnine the state of the transaction associated with the bmwser request.
For example, it shall be assumed that the browser request included a URI of "Istorefrontlopen session" and a cartridge type of STOREFRONT.
By looking at the metadata associated with the cartridge type of STOREF~0~1T
(i.e.
the metadata described in TXl above), the cartridge execution engine 22$
determines that the URI of /storefront/open session corresponds to a "begin" transaction state.
Using this same mechanism, the cartridge execution engine 228 can determine that a browser request containing a URI of /store&ont/comrnit session corresponds to a "commit"
transaction state and that a browser request ~;vntaining a URI of /storefront/rollback session corresponds to a"rollback" transaction state.
Try the case where the URi dots nat include a particular state (i.e. a URI
consisting only of (storefront), the cartridge execution engine 228 assumes that the browser zequest is associated with an ongoing multiple-request transaction that is not ready to be eithtr committzd or rolled backed.
When the cartridge execution engine receives a revised browser message that is not associated with a "begin" transaction, the cartridge execution engine checks the header to determine if it spzei;Des a globally unique trazr,,action rD. If the header specifies a globally unique transaction ID, then cookie information was used to store the globally unique transaction T~. tf the header does not specify a globally unique transaction )D, the cartridge execution engine then searches the URI to identify the globally unique trausactaon ID that is associated with the browser request. Once the cartridge execution engine locates the globally unique transaction TT3, the cartridge execution engine includes the transaction TD in the transaction control messages that are sent to the transaction manager. The transaction ANtE~DED SHEET

i\\".1 . 1\/.\~1.1 :1-.11. L.\\.IIL.\ \ V 11 aJa ~ . « n . .~

manager then uses the globally unique transaction ITa in communicating with the associated database servers to cause multiple-request transactions to be either committed or rolled back as an atomic unit of work.
PROCESSING TRANSACTIONS
Figure 7A through 7I are a flow diagram illustrating a method for processing multiple-tequest transactions in a stateless environment according to an embodiment of the invention.
At step 702, a revised browser message that was directed to cartridge 230 is intercepted by cartridge execution engine 228. For the purposes of explanation, it shall be assumed that the revised browser message vas sent by dispatcher 214 and that the revised browser message is associated with transaction TX1 as described above.
At step 704, cartridge execution engine 22$ determines i.f the revised bmwser message is associated with a transaction. If the revised browser message is not associated with a transaction, at step 706, cartridge execution engine 228 forwards the revised browser message to cartridge 230 for cartridge 230 to perform the requested non-transactiona.I
functions associated with the revised browser message. puce the cartridge performs the requested non-transactionai functions, control returns to step 702 in order for the cartridge execution engine 228 to intercept the next revised browser message.
Otherwise, if the revised browser message is associated with a firansaction, at step 708, cartridge execution engine 22$ determines the state of the transaction by fir,t detcrrnining whether the revised browser message is associated with a begin transaction URI. In determining whether the revised browser message is associated with a begin transaction URI, the cartridge executioa engine 228 uses the cartridge name to identify the previously stored metadata that includes the transaction attributes of the traasac;tion type idanti~ed in the revised browser message. Using the previously stared metadata, the cartridge execution engine 228 determines if the revised browser message is associated with a begin transaction URI.
For example, it shall be assumed that the revised browser message contained a cartridge name of STOREFRONT and a UrLI of /storefrontlopen session. Using the STOREFRONT cartridge name, the cartridge execution engine 22$ determines that the revised browser message is associated with the metadata for transaction TXI.
Using this metadata, the cartridge execution engine 228 determines that the URI of /storefrontJopcn session is associated with a begin transaction.
If the cartridge execution engine 228 deternr~incs that the revised browser message is not associated with a begin transaction, then control proceeds to step 744.

K1.1 . 1 V:\ ~ I:1'tl Wlll l:.Vl.llL:.\ V. J- 1 L ' a!J ~ a) ~ ..1 ~ ~cwn .~..
1 ~v 1. V- ml al . s.) ~a~.JiJ'1"CtJ.! ~ rI'1~..1 If the cartridge execution engine 228 determines that the revised. browses message is associated with a begin transaction, then at step 712, the cartridge execution engine 228 includes a begin transaction identifier (tx begin) in a transaction control message. The cartridge execuhion engine 228 then sends the transaction control message to the transaction manager 606.
At step 714, upon receiving the begin transaction identifier, the transaction manager 606 creates a globally unique transaction 1D that is used to identify subsequent browser requests that are associated with this multiple request transaction. In certain embodiments of the invention, the transaction ID is formed ifsing the brnwser ZP address, the transaction name and a particular timestamp value.
At step 7x6, the cartridge execution engine 228 sends an operation message to cartridge 230 that is formed from information that is contained in the revised browser message. The operation message also includes a dispatcher pointer that identifies the dispatcher that sent the revised browser request (dispatcher 2x4). This pointer allows the cartridge 230 to write informatian back to the dispatcher. At step 718, upon receiving the operation message, the cartridge 230 sends a message to the transaction manager 606 requesting handles for access to the databases that arc associated with the transaction.
At step 720, transaction r~aanager 606 returns handles to the appropriate database servers to allow the cartridge 230 to process the transaction request. For example, assuming database 610 is associated with the SEARS database and database 614 is associated with the BANK1 database, transaction manager 606 will return handles to database server 60$ and 612 respectively.
At step 722, caztxidge 230 uses the handles returned from transaction manager 60b to execute the operations identi~~ed in the operation message that was sent by the carrsidge execution engine 228.
At step 724, the cartridge 230 determines whether the sending brawser allows cookie information to be associated with the browser. rf the browser does not allow for cookie information to be associated with the browser, at step 726, the cartridge 230 causes the hyperlinks o~the H'TML page that was generated in response to executing this transaction request to be annotated to include the globally unique transaction 117. Hy annotating the hyperlinks of the HTMr, page, the LTRIs contained in subsequent browser request will contain the globally unique transaction fT3.
At step 72$, the cartridge 230 uses the dispatcher pointer to return back to the dispatcher 214 the HTML page that was generated in response to executir~ the transaction ~'~EI'.~DE~ SHEET

I\Y..1. 1V Y'LI=1, dl=t~.1Y.111.. ~~ .. . ~--,. ..~. . -.. .. ~.. ... ~. ~ ~---.. ......-... ...--~~ . . . . ~m n~ W

w request. The cartridge 230 then notifies cartridge execution engine 228 that execution of the transaction request is complete.
At step 730, the cartridge execution engine 228 sends a message to the transaction manager 606 requesting it to suspend the transaction At step 732, the transaction manager S 606 sends a suspend request to database servers 608 and 612 to cause them to suspend execution of the transaction. The suspend request includes the globally unique transaction ~
so that the database servers 608 and 612 lrnow which transaction to suspend.
By sending a suspend request to database servers 608 and 612, it allows other browse~rs to execute transactions that arc associated with databases 610 and 614.
At step 734, transaction manager 606 sends the globally unique transaction D7 to the cartridge execution engine 22$. At step 736, the cartridge execution engine 228 determines __ whether the sending browser allows far cookie information to be associated with the browser.
if the browser does not allow for cookie information to be associated with the browser, at step ?38, the dispatcher 214 is notified that the processing of the revised browser request is complete. Control then returns to step ?02 to intercept another revised browser message.
If the browser does allow far cookie information to be associated with the browser, at step 740, the cartridge execution engine 228 uses the globally unique transaction m to create cookie information to be associated with the sending browser.
At step 742, cartridge execution engine 228 forwards the cookie information to dispatcher 214 so that it may be transmitted to the sending browser and notifies the dispatcher 214 that the processing of the revised browser request is complete. Control then returns to step 702 to intercept another revised browser message.
At step 744, the cartridge execution engine 228 determines whether the revised ::.:=:'.
browser message is associated with a commit transaction i.JRI. rn determining whether the revised browser messagr is associated with a commit transaction 1_JRi, the cartridge execution engine 228 uses the cartridge name to identify the previously stored metadata for the type of transaction associated with the revised browser messago. Using the previously stored metadata, the cartridge execution engine 22$ determines if the revised browser message is associated with a commit transaction URI.
For example, it shall be assumed that the zevised browser message contained a cartridge name of STOR)rFRONT and a URT of /storefrontlcommit session. Using the STOR,EFitONT cartridge name, the cartridge execution engine 228 determines that the revised browser message is associated with the metadata for transaction TX1.
Using dais r t-f' K~.\ . \ UN ~ LI'/\-:SIL.~L::W I II;:V l.1_ :)- I. 1 -:J:1 . ut ~ ..J .
~l~lJ~) . . 1 .J 1 lJw r~,:J U:J ~J:J:J~b~lJiJ ~ li~1~.) mctadata, the cartridge execution engxioie 22s determines that the UR~ of /storefront/cornmit~session is associated with a commit transaction.
If the cartridge execution engine 228 determines that the revised browser message is not associated with a commit transaction, then control proceeds to step 774.
If the cartridge execution eztgine 228 determines that the t~evised browser message is associated with a commit transaction, then at step 746, the cartridge execution engine 228 determines whether the header section of the revised browser message contains cookie information. If cartridge execution engine 228 determines that the header section of the revised browser message contains coolQe~in'formatian, then at step 74$ the cartridge execution engine 22$ extracts the globally unique transaction ?Z7 from the cookie infazznation. Control then proceeds to 752.
if caraidge execution engine 228 determines that the header sectiprl of the revised browser message does not contain cookie information, then at step 750 the cartridge execution engine 228 extracts the globally unique transaction ID from the annotated URI.
At step 752, the cartridge execution engine 228 packages a resume transaction identifier (tx_resume) into a tzansaction control raessage. The cartridge execution engine 228 then sends the transaction control message to the transaction manager 606.
At step 754, upon receiving the resume transaction identifier, the transaction manager 606 sends a resume request to database servers 60$ and 6I2 to cause them to resume execution ZO of the transaction. The resume request includes the globally unique transaction Xla wLvch allows the database servezs 60$ and 612 to identify the multiple-request transaction that is associated with the current transaction request.
At step 756, the cartridge execution engine 228 sends an operation message to cartridge 230 that is based on the transaction information contained in the revised browser message. The operation message also contains a dispatcher pointer that identifies the dispatcher that sent the revised browser request (dispatcher 214) az~d allows the cartridge 230 to write information back to the dispatcher. At step 75$, upon receiving the operation message, the cartridge 230 sends a message to the transaction manager 606 requesting handles for access to the databases that are associated with the transaction.
At step 760, transaction manager 606 returns handles to the appropriate database servers to allow the cartridge 230 to process the transaction request. For example, assuming database 610 is associated with the SEARS database and database 614 is associated with the BANK.I database, transaction manager 606 will return handles to database server 608 and 612 respectively.

AtviEi~lGhu SI ;=~T

v.y . . w.v . .. . . ~ _ _ -- .- . . .--~. . .~.~. ,aLW ~~ ~ .~. . . ... . . ---- . . ..----~ -_ . . - . _ _ _ _'vl ~ ~WII,W ~'1. O'4V

At step 762, cartridge 230 uses the handles returned from transaction manager 606 to execute the operation specified by the operation message that was sent by the cartridge execution engine 228.
At step 764, the cartridge 230 determines whether the sending browser allows cookie information to be associated with the browser. If the brawser does not allow for cookie information to be associated with the browser, at step 766, the cartridge 230 causes the globally unique transaction ID to be removed from the annotated hyperlinks of an,y H~fi~.
page that is associated with the transaction. By removing the Cransaction ID
annotations from the hyperliztlcs of the H~'l~, page, subsequent browser requests that are issued in response to selection of a hyperlink from the HTML page will not contain the globally unique transaction ID and, therefore, will not be mistakenly associated with this multiple-request transaction.
At step 7b8, the cartridge 230 uses the dispatcher pointer to return the HTIVIL page generated in response to performing the operation specified in the browser request to the dispatcher 214 and notifies cartridge execution engine 228 that execution of the transaction request is complete.
At step 770, the cartridge execution engine 228 sends a transaction control message to the transaction manager 606 requesting it to commit the transaction. At step 77I, the iransactioz~ manager 606 seztds a commit request to database servers 608 and 612 to cause all changes mach in response to the various browser requests that belonged to the multiplc-request transaction to be committed as an atomic unit of work. 'fhe comxxzit request includes the globally unique transaction 117 which allows the database servers 608 and 612 to identify the associated multiple-request transaction.
At step ??2, the cartridge execution engine 228 notifies the dispatcher 214 that the processing of the revised browser request is complete and signals the dispatcher 214 to cause the cookie information associated with the committed multiple-request transaction to be removed from the sending browser. By removing the transaction ED from the cookie information associated with the sending browser, subsequent browser requests will not contain the globally unique transaction TD and, therefore, will not be mistakenly associated with the committed multiple-request transaction. Control 'then returns to step 702 to intercept another revised browser message.
At step 774, the cartridge execution engine 228 determines whether the revised browser message is associated with a rollback transaction ~J1~T. In determining whether the revised browser message is associated with a rnllback transaction URI, the cartridge execution engine 228 uses the cartridge name to identify the previously stored metadata that corresponds CA 02308801 2000-04-is j~~~~L~,i~~p SHEET

l\L1.1\.\~1.1,.1~.11L1....'111.\-- .. . .--~..11.. ..~~ ~.'~~~~: ... ~.- ..-.
.. . ............... . . .. ~ W~n .11.

to the transaction type indicated in the revised bnowstr message. Using the previously stored rnetadata, the cartridge execution engine 228 determines if the revised browser nacssase contains a rollback transaction URI.
For example, it shall be assumed That the revised bmwser message contained a cartridge nancce of STQREFRONT and a URI of (storefront/ rollback session.
Us'lng the STQREFRONT cartridge name, the cartridge execution engine 228 deterrnincs that the revised browser message is associated with the rnetadata for transaction TX1.
Using this metadata, the cartridge execution engine 228 determines that the URI of /storefront) rollback session is associated with a rollback transaction.
if the cartridge execution engine 22$ determines that the revised browser message is not associated with a rotlback transaedon, then control proceeds to step 8Q4.
. . rf the cartridge execution engiune 228 determines that the revised browser message is associated with a rollback transaction, then at step 776, the cartridge execution engine 228 determines whether the header section of the refused browser massage contains cookie 1 S information. If cartridge execution engine 228 determines that the header section of the revised browser message contains cookie information, then at step 778 the cartridge execution engine 228 extracts the globally unique transaction ZT7 from the cookie informarion. Control then proceeds to 782.
If cartridge execution engine 228 determines that the header section a~the revised browser message does not contain cookie information, then at step 780 the cartridge execution engine 228 extracts the globally unique transaction ID from the annotated URI.
At step 7$2, the cartridge execution engine 228 incorporates a resume transaction identifier (tx resume) in a transaction control message. The cartridge execution engine 228 then sends the transaction control message to the transaction manager 606.
At step 784, upon receiving the resume transaction identifier, the 4ransaction manager 606 sends a resume request to database servers d08 and 6 t 2 to cause them to resume execution of the transaction. The resume request includes the globally unique transaction 1D which allows the database servers 608 and 612 to identify the multiple-request transaction that is associated with the current transaction request.
At step 786, the cartridge execution engine 228 sends an operation message to cartridge 230 that is based on the transaction information cuntaiuaed in the revised browser message. The operation message also contains a dispatcher pointer that identifies the dispatcher that sent the revised browser request (dispatcher 214) and allows the caztridge 230 to write information back to the dispatcher. At step 788, upon receiving the operation CA 02308801 2000-04-18 ~~-- -~~i'il...:;:rCU OI.

1\~.L. 1\. ~~L-1.=. '~_ . ~ -- .. _- .--~. .... . ~ .~~ ~..~... ... . . ...-.. ..._..--.- .~ ..-.. . . .. - ... .. ...

w message, the cartridge 230 sends a message to the transaction manager 606 requesting handles for access to the databases that are used in the specified typo oftransaction At step 790, transaction manager 606 returns handles to the appropriate database servers to allow the cartridge 230 to process the transaction request. For example, assuming database 610 is associated with the SEARS database and database 614 is associated with the BANK1 database, transaction manager 606 will return handles to database server 608 and 612 respectively.
At step 792, cartridge 230 uses ttxe handles returcaed from transaction manager 606 to execute the transaction information associated with the operation message that was sent by the cartridge execution engine 228.
At step 794, the cartridge 230 determines whether the sending browser shows cookie information to be associated with the browser. 1;f the browser does not allow far cookie information to be associated with the browser, at step 796, the cartridge 230 causes the globally unique transaction Ila to be removed from the annotated hyperlinks of any HTML
page to be returned to the browser. By removing the transaction 1D annotations from the hyperlinks ofthe HTML page, subsequent browser requests will not contain the globally unique transaction ID and, therefore, will not be mistakenly associated with this multiple-request transaction.
At step 798, the cartridge 230 uses the dispatcher poizuer to return the HTML
page that is associated with executing the transaction back to the dispatcher 214 and notifies cartridge execution engine 228 that execution of the transaction request is complete.
At step 800, the caztridge execution engine 228 sends a transaction control message to the transaction manager 606 requesting it to rollback the transaction. At step $O1, the ::, transaction manager 606 sends a rollback request to database servers 608 and 612 to cause all changes made in response to the browser requests that belong to tha multiple-request transaction to be rolled back as an atomic unit of work. The roll back request includes the globally unique transaction m which allows the database servers 60$ and 612 to identify a~ad roll back the correct znultiplo-request transaction.
At step 802, the cartridge execution engine 228 notifies the dispatcher 2I4 that the processing of the revised brvwscr request is complete and signals the dispatcher 214 to cause the cookie information associated with the rolled back multiple-request transaction to be removed from the sending hrowser. By removing the transaction >I3 frazn the cookie information associated with the sending browser, subsequent browser requests will not contain the globally unique transaction ID and, therefore, will not be mistakenly associated with the ;,-i~r.;

..,... ."., ~~ ,. . _ ., _ _ . . .__ .... _.. .. __ . _ ~ - . - . _ -. _... _ . . . .. ...

rolled back multiple-request transaction. Control then rctmns to step 702 to intercept another revised browser message.
At step 804, the cartridge execution engine 228 determines v~~hether tire header section of the revised browser message contains cookie information. Z;f'cartr'idge exeGUtion engine 228 doterrnines that the header section of the revised browses message contains cookie infonnatian, then at step 806 the cartridge execution engine 228 extracts the globally unique transaction B7 from the cookie information. Control then proceeds to 810.
If cartridge execution engine 228 determines that the header section of the revised -, browses message does not contain cookie information, then at step 808 the cartridge execution engine ZZ8 extracts the globally unique transaction ID from the annotated URI.
At step 810, the cartridge execution engine 22$ packages a resume transaction identifier (tx,~resumc) in a transaction control message. The cartridge execution engine 228 then sends the transaction control message to the transaction manager 606.
At step 812, upon receiving the resume transaction identifier, the transaction manager 606 sends a resume request to database servers 60$ and 6I2 to cause them to resume execution of the transaction. The resume request includes the globally unique transaction B7 which allows the database servers 608 and 612 to identify the multiple-request transaction that is associated with the current transaction request.
At step 814, the cartridge execution engine 228 sends an operation ~o;lessage to cartridge 230 that is based on the transaction information contained in the revised browses message. T'he operation message also contains a dispatcher pointer that identifies the dispatcher that sent the revised browses request (dispatcher 214) and allows the cartridge 230 to write information back to the dispatcher. At step 816, upon receiving the operation message, the cartridge 230 sends a message to the transaction manager 606 requesting handles far avcess to the databases that are associated with the transaction.
At step 818, transaction manager 606 returns handles to the appropriate database servers to allow the cartridge 230 to process the transaction request. For example, assuming database d 10 is associated with the SEARS database and database 614 is associated with the BANK1 database, transaction manager 606 wilt retwn handles to database servers 608 and 612 respectively.
At step 820, cartridge 230 uses the handles returned from transaction manager 606 to execute the operation specified in the operation message that was sent by the cartridge execution engine 228.

t\l1 . 1 vJ~\ ~ L.1;!\ W 11_C.\l Itl.;\ t! _- . . . .--~~.. .~ ). ~,:JiJ -__ J=) I ... . - . 1 "t~ ~_ 1..=-__ _ -_ . .. :. ..I y . . . ~J.W .m..~u ~ m .
-40.
At step 822; the cartridge 230 deteru~incs whether the sending browser allows cookie information to be associated with the browser. If the bmwser does not allow for cookie information to be associated with the browser, at step 824, the cartridge 230 causes the hyperlinks of an HTML page generated in response to perfozming the operation to be annotated to include the globally unique transactiotx ZD. $y annotating the hyperlinks of the I-~TvII, page, the >:IRIs in subsequent browser requests that are xssue~ in response to selecting the links in the HTML. page will contain the globally unique transaction Ib.
At step 826, the cartridge 230 uses the dispatcher pointer to return the HT1VIL page thus generated back to the dispatcher 214 and notifies cartridge execution engine 228 that execution of the transaction request is complete.
At step 828, the cartridge execution engine 228 sends a message to the transaction manager 606 requesting it to suspend the transaction. At step 830, the transaction manager 606 sends a suspend reque'si to database servers 608 and 612 to cause them to suspend execution of the transaction. The suspend request includes the globally unique transaction Il~
which allows the database servers 608 and d 12 to accurately identify the multiple-request transaction to be suspended. Contml then returns to step 702 to intercept another revised .
browser message.
TRANSACTION TIMEOUTS
According to one embodiment of the invention, a tinaeout value is associated with each transaction. The tizzaeout value is used to identify multiple-request transactions that have not been active for a specified time period. In one embodiment, each database server maintains a timeout value fox the multiple-request transactions that are being serviced by the database server. Thus, whenever a multiple-request transaction begins to execute, the associated database server initializes the timeout value for the particular transaction.
Upon receiving a Z5 resume transaction request that is associated with a globally unique trarasacdon ID, the database server resets the timcout value for the multiple-request transaction that is associated with the globally unique transaction ID. If a multiple-request transaction times out, the database server causes all changes made as part of the multiple-request transaction to be rolled back as an atomic unit of work. Once the multiple-request transaction is rolled back, a message is then sent to the associated browser to indicate the state of the transaction.
COND'(JCTING TRA>.'VSACT10NS TN A STATELESS VVEB EN'VTltONMENT
The present invention provides a practical and highly scalable mechanism for conductiz~,g multiple-request transactions in a stateless environment, such as the web.
According to the invention, a transaction manager is used to coordinate the overall transaction AAAG'Alnrn hht. tv.v~L-1. \-lW.y.W u.~__ _ . .__ ''~.._~. " ._.. ...... '.__ .. _ ___,-.. . ______.. _.____ .__ w ~ process. Preferably; the transaction manager coordinates the process in such a way that state information is maintained for a transaction without requiring the transaction manager itself to persistently maintain the state information.
In a preferred embodiment, processing of a client request is performed as follows. The transaction manager receives a request from a client, and if the request is a transaction request, the manager initiates a transaction with a transaction processing mechanism, such as a database management system (DBMS). Ozxce the transaction is initiated, the manager preferably forwards the request to another entity, such as an application, which actually processes the request. Af3er the request is processed, control is returned to the manager, and at that point, the manager asstznbles a set of state information associated with the transaction.
This state infarmation may includt the identity of the client, the 1D and status ofthe transaction, and what has already transpired in the transaction, Once assembled, the state information, along with the response to the client request, is sent back to the client to be maintained by the client. The state information may be sent to the client in the form of a "cookie" or it may be incorporated into a UR.L that is returned to the client.
While it is possible to do so, state information is preferably not persistently maintained by the manager or by the application that processed the request.
When the client submits a second request relating to the same transaction, the client sends along the state information previously provided by the manager. iJpon receiving the second request, the manager extracts the state information from the request, and uses it to resume the previously izxitiated transaction with the DB1VIS. Once the trazzsaction is resumed, the nrxanager sends the second request, including the state information, to another entity (the same or a different application) for processing. After the secand reqacst is processed, the managcx updates the state information associated with the transaction, and sends the updated state information, along with the response to the second request, to the client. The client will send this updated state information in a future request to resume the transaction. This process repeats until the transaction is either committed or rolled back.
The present invention provides several significant advantages. First, note that the transaction manager and the applications that process the requests remain stateless. That is, the transaction manager and the applications are not required to maintain any of the state information for the transaction. All of that information is maintained by the client. This means that no overhead is incurred for storing the information. More importantly, the fact that the client maintains its own state information mans that any request from the client can ba AMENDED SHEET

w..v. w.c.u n-.w_a:.w.m.v ..._ ..-am-...~ ~ .,.,._ . .,.., _ ,.
.. . ..--_.... -~~ . . -. ..- __. ......--_. ....-_w/ =-~Lll...l./.:( processed°by any thread, process, or node. This significantly improves scalabilily because it eliminates the need to have a dedicated process or thread for each client.
Another point to note is that even though the client is maintaining the state information, the client is not aware that it is maintaining transaction-specific state information.
As discussed above, the state information is provided to the client by the transaction manager.
The client simply sends this infarmabion back to the transaction manager when it makes its next request. The client xs not, nor does it need to be, aware that it is maintaining state infozmation. This is a very advantageous aspect of the present invention because it obviates the need to put any state management logic an the client. This in turn means that no changes ax add.itions need to be made to the client for the present invention to operate properly.
Hence, the present invention provides a practical, scalable, and effective mechanism far conducting transactions in a stateless envizo~ament. These and other advantages of the invention will become apparent as the invention is described in further detail.
INCORPORATIQN OF STATE INFORMATION IN URLS
The present invention provides an effective and highly scalable mechanism for supporting multiple-request operations (including but not limited to traztsactions) in a stateless environment, such as the web. According to the invention, a server is preferably used to coordinate the overall processing of client requests. Preferably, the server performs this coordination function in such a way that: (1) state information associated with muItipIe-request operations is maintained by the clients making the requests; (2) the clients are unaware that they are maintaiziing operation-specific state information; and (3) the server itself is not required to persistently maintain the state information, thereby remaining stateless.
In a preferred embodiment, processiztg of a client request is performed as follows. The server recEives a request from a client, and if the request is for a multiple-request operation, the server initiates an operation. Qnce the operation is initiated, the server may either forward the request to another entity (such as an application) for processing, or the server may process the request itself. After the request is processed, the server assembles a set of state information associated with the operation, This state information may iuaclude the identity of the client, the 1b and status of the operation, what has already transpired in the operation, and any other context information associated with the operation. Once assembled, the state information is incorporated into a URL. This URL, along with the response to the client request, is sent back to the client to be maintained by the client. This state information is preferably not persistently maintained by the server.
ca o23ossoi Zooo-o4-is ~i~,ir~~,_~; l;~~Fr Ivl.~. \U:v~LI't1-.vll.L.W Itl:w W _ .. .__ ~_.«',:~:.u-__ _'~'W ',__ .. _ _~_'a' m u.=~m~r =_ .. ~_1_r _~:~ _.~µnu.~.m.s~, -43~
When the client submits a second request relatiulg to the same operation, the client sends the UItL that was previously provided by the server which contains the stale information. Upan receiving the second request, the server extracts ttxe state information from the URL, and uses it to resume the previously initiated operation. With the benefit of this stale infon~nation, the server can resume the operation at tlxe exact point at which the previous request stopped. Once the operation is resumed, the server either processes the request, or forwards it to another entity for processing. After the second request is processed, the server updates the state infaxznatioa associated with the operation, and incorporates the updated state information into another URL. This URL, along with the response to the second request; is sent back to the client to be raaantained by the client. The client will send this T_TRI, in a future request to resume the operation. This process repeats until the operatiozt is either completed or canceled.
The present invention provides several significant advantages. First, note that the server remains stateless. That is, the server is not required to maintain any of the state information for the transaction. All of that information is maintained by the client. This means that zoo overhead is incurred for storing the information, Mare importantly, the fact that the client maintains its own state information means that any request from the client can be processed by any thread, process, or node. This significantly improves scalability because it eliminates the need to have a dedicated process or thread far each client.
Another point to note is that even though the client is maintaining the state information, the client is not aware that it is maintaining operation-specif c state information.
As discussed above, the state information is provided by the server to the client in the form of a UI~L. The client simply sends this URL whenever it requests service from the server. The client treats this URL like arwy other URL. The client is not, nor dots it need to be, aware that this U'RL contains state information. This is a very advantageous aspect of the present invention because it obviates the need to put any state management logic on the client. This in turn means that no changes or additions need to be made to the client for the present invention to operate properly.
Hence, the present invention provides a practical, scalable, and effective mechanism for supporting multiple-request operations in a stateless environment. These and other advantages of the invention will become apparent as the invention is described in Rather detail.
In the foregoing specification, the invention has been described with refeseioice to specific embodiments thereof It will, however, be evident that various modifications and .,~;.,~_~";~;_.. :.~~Etf IW.1 . t Vn\ ~ 1.1'!\-wll.; C~\\.Ill:.yV~ - . . _.. '~ 1.1 -'1'~ '. _ ..'~ .'-IJ ' _ _ _ _ ._~!'t~W . ! 1 ~..~ 1_U-._ _ ,'y:~ t :l .~.y:~:rlyi-W .~ ~ yo-1 changes may be made thereto without depaz'ting from the broader scope of ttte invention. The specification and drawings aro, accordingly, to be regarded in au illustrative rather than a restrictive sense.

Afv9ENDED SHEET

Claims (48)

What is claimed is:

1. A method for processing multiple-request transactions in a stateless environment, wherein the multiple-request transactions involve operations specified in browses messages, the method comprising the steps of:
a cartridge execution engine intercepting browses messages directed to a cartridge; said cartridge execution engine determining whether said browses messages are associated with transactions;
if said browses messages are associated with transactions, then said cartridge execution engine sending transaction control messages that are based on said browses messages to a transaction manager that is implemented separately from said cartridge;
said cartridge execution engine ending operation messages that are based on said browses messages to said cartridge in response to said operation messages from said cartridge execution engine, said cartridge performing: the operations specified in said operation messages without the cartridge persistently maintaining state information for the multiple-request transactions to which the operations belong; and in response to said transaction control messages from said cartridge execution engine, said transaction manager causing the operations specified in said operation messages that are performed by said cartridge as part of the multiple-request transactions to be either committed or rolled back as an atomic unit of work.

2. The method of claim 1, wherein the step of causing the operations specified in said operation messages to be committed includes the step of said transaction manager sending commit messages to one or more database servers, wherein the commit messages cause said one or more database servers to commit changes associated with said multiple-request transactions as an atomic unit of work.

3. The method of claim 1, wherein the step of causing the operations specified in said operation messages to be rolled back includes the step of said transaction manager sending rollback messages to one or more database servers; wherein the rollback messages cause said one or more database servers to roll back changes associated with said multiple-request transactions as an atomic unit of work.

4. The method of claim 1, wherein the browser messages associated with transactions are associated with transaction IDs, wherein the transaction IDs identify a browser associated with a particular browser message.

5. The method of claim 4, wherein the transaction IDs are maintained as cookies, wherein the cookies are maintained on the browser that is associated with the particular browser message.

6. The method of claim 4, wherein the transaction IDs are maintained as URLs that are associated with one or more tags in one or more Web pages that are displayed at the browser that is associated with the particular browser message.

7. The method of claim 1, wherein the step of said cartridge execution engine determining whether said browser messages are associated with transactions includes the steps of:
obtaining a URL that is associated with a particular browser message; and using the URL associated with the particular browser message to determine the state of a transaction that is associated with the particular browser message.

8. The method of claim 4, wherein the transaction IDs are associated with a timeout period, wherein the expiration of the timeout period indicates that the transaction associated with the transaction ID should be deemed invalid.

9. The method of claim 1, wherein:
prior to intercepting browser messages directed to the cartridge, registering the cartridge, wherein the cartridge is registered by storing metadata that defines a set of attributes that is associated with one or more transaction types.

10. The method of claim 1, wherein the step of said cartridge execution engine determining whether said browses messages are associated with transactions includes the steps of:
retrieving metadata based on the intercepted browses messages; and using the retrieved metadata to determine whether the browses messages are associated with transactions.

11. A computer readable medium carrying sequences of instructions for processing multiple-request transactions in a stateless environment, wherein the multiple-request transactions involve operations specified in browses messages, the sequences of instructions including instructions for performing the steps of:
a cartridge execution engine intercepting browses messages directed to a cartridge;
said cartridge execution engine determining whether said browses messages are associated with transactions;
if said browses messages are associated with transactions, then said cartridge execution engine sending transaction control messages that are based on said browses messages to a transaction manager that is implemented separately from said cartridge;
said cartridge execution engine sending operation messages that are based on said browses messages to said cartridge in response to said operation messages from said cartridge execution engine, said cartridge performing the operations specified in said operation messages without the cartridge persistently maintaining state information for the multiple-request transactions to which the operations belong; and in response to said transaction control messages from said cartridge execution engine; said transaction manager causing the operations specified in said operation messages that are performed by said cartridge as part of the multiple-request transactions to be either committed or rolled back as an atomic unit of work.

12. The computer readable medium of claim 11, wherein the browses messages associated with transactions are associated with transaction IDs, wherein the transaction IDs identify a browses associated with a particular browses message.

13. The computer readable medium of claim 11, wherein the step of said cartridge execution engine determining whether said browser messages are associated with transactions includes the steps of:
obtaining a URL that is associated with a particular browser message; and using the URL associated with the particular browser message to determine the state of a transaction that is associate with the particular browser message.

14. A system for processing multiple-request transactions in a stateless environment, wherein the multiple-request transactions involve operations specified in browser messages, the system comprising:
a memory;
one or more processors coupled to the memory; and a set of computer instructions contained in the memory, the set of computer instructions including computer instructions which when executed by the one or more processors, cause the one or more processors to perform the steps of a cartridge execution engine intercepting browser messages directed to a cartridge;
said cartridge execution engine determining whether said browser messages are associated with transactions;
if said browser messages are associated with transactions, then said cartridge execution engine sending transaction control messages that are based on said browser messages to a transaction manager that is implemented separately from said cartridge;
said cartridge execution engine sending operation messages that are based on said browser messages to said cartridge;
in response to said operation messages from said cartridge execution engine, said cartridge performing the operations specified in said operation messages without the cartridge persistently maintaining state information for the multiple-request transactions to which the operations belong; and in response to said transaction control messages from said cartridge execution engine, said transaction manager causing the operations specified in said operation messages that are performed by said cartridge as part of the multiple-request transactions to be either committed or rolled back as an atomic unit of work.

15. The system of claim 14, wherein the browses messages associated with transactions are associated with transaction IDs, wherein the transaction IDs identify a browses associated with a particular browses message.

16. The system of claim 14, wherein the step of said cartridge execution engine determining whether said browses messages are associated with transactions includes the steps of:
obtaining a URL that is associated with a particular browses message; and using the URL associated with the particular browses message to determine the state of a transaction that is associate with the particular browses message.

17. The method of claim 1, wherein:
the step of said cartridge execution engine intercepting browses messages includes the step of said cartridge execution engine intercepting browses messages that include a begin transaction command; and in response to said cartridge execution engine receiving a browses message that includes a begin transaction command, said cartridge execution engine sending a transaction control message to said transaction manager to cause said transaction manager to begin said transaction.

18. The method of claim 1, wherein:
the step of said cartridge execution engine intercepting browses messages includes the step of said cartridge execution engine intercepting browses messages that include a commit transaction command; and in response to said cartridge execution engine receiving a browses message that includes a commit transaction command; said cartridge execution engine sending a transaction control message to said transaction manager to cause said transaction manager to commit said transaction.

19. The method of claim 1, wherein:
the step of said cartridge execution engine intercepting browses messages includes the step of said cartridge execution engine intercepting browses messages that include a rollback transaction command; and in response to said cartridge execution engine receiving a browser message that includes a rollback transaction command, said cartridge execution engine sending a transaction control message to said transaction manager to cause said transaction manager to roll back said transaction.

20. The method of claim 17, further comprising the step of receiving said begin transaction command in the form of a URL at said cartridge execution engine in response to selection of a control associated with a tag of a Web page displayed at the browser.

21. The method of claim 18, further comprising the step of receiving said commit transaction command in the form of a URL at said cartridge execution engine in response to selection of a control associated with a tag of a Web page displayed at the browser.

22. The method of claim 19, further comprising the step of receiving said rollback transaction command in the form of a URL at said cartridge execution engine in response to selection of a control associated with a tag of a Web page displayed at the browser.

23. The computer readable medium of claim 11, wherein the step of causing the operations specified in said operation messages to be committed includes the step of said transaction manager sending commit messages to one or more database servers, wherein the commit messages cause said one or more database servers to commit changes associated with said multiple-request transactions as an atomic unit of work.

24. The computer readable medium of claim 11, wherein the step of causing the operations specified in said operation messages to be rolled back includes the step of said transaction manager sending rollback messages to one or more database servers, wherein the rollback messages cause said one or more database servers to roll back changes associated with said multiple-request transactions as an atomic unit of work.

25. The computer readable medium of claim 11, wherein the step of said cartridge execution engine intercepting browser messages includes the step of said cartridge execution engine intercepting browses messages that include a begin transaction command; and the computer readable medium further comprising instructions for performing the step of, in response to said cartridge execution engine receiving a browser message that includes a begin transaction command, said cartridge execution engine sending a transaction control message to said transaction manager to cause said transaction manager to begin said transaction.

26. The computer readable medium of claim 11, wherein the step of said cartridge execution engine intercepting browser messages includes the step of said cartridge execution engine intercepting browser messages that include a commit transaction command; and the computer readable medium further comprising instructions for performing the step of, in response to said cartridge execution engine receiving a browser message that includes a commit transaction command, said cartridge execution engine sending a transaction control message to said transaction manager to cause said transaction manager to commit said transaction.

27. The computer readable medium of claim 11, wherein the step of said cartridge execution engine intercepting browser messages includes the step of said cartridge execution engine intercepting browser messages that include a rollback transaction command; and the computer readable medium further comprising instructions for performing the step of, in response to said cartridge execution engine receiving a browser message that includes a rollback transaction command, said cartridge execution engine sending a transaction control message to said transaction manager to cause said transaction manager to roll back said transaction.

28. The computer readable medium of claim 12, further comprising instructions for maintaining the transaction IDs as cookies, wherein the cookies are maintained on the browser that is associated with the particular browser message.

29. The computer readable medium of claim 12, further comprising instructions for maintaining the transaction IDs as URLs, wherein the URLs are associated with one or more tags in one or more Web pages that are displayed at the browser that is associated with the particular browser message.

30. The computer readable medium of claim 12, further comprising instructions for associating a timeout period with the transaction IDs, wherein the expiration of the timeout period indicates that the transaction associated with the transaction ID should be deemed invalid.

31. The computer readable medium of claim 11, further comprising instructions for performing the steps of prior to intercepting browser messages directed to the cartridge, registering the cartridge, wherein the cartridge is registered by storing metadata that defines a set of attributes that is associated with one or more transaction types.

32. The computer readable medium of claim 11, wherein the step of said cartridge execution engine determining whether said browser messages are associated with transactions includes the steps of:
retrieving metadata based on the intercepted browser messages; and using the retrieved metadata to determine whether the browser messages are associated with transactions.

33. The computer readable medium of claim 25, further comprising instructions for performing the step of receiving aid begin transaction command in the form of a URL
at said cartridge execution engine in response to selection of a control associated with a tag of a Web page displayed at the browser.

34. The computer readable medium of claim 26, further comprising instructions for performing the step of receiving said commit transaction command in the form of a URL
at said cartridge execution engine in response to selection of a control associated with a tag of a Web page displayed at the browser.

35. The computer readable medium of claim 27, further comprising instructions for performing the step of receiving said rollback transaction command in the form of a URL
at said cartridge execution engine in response to selection of a control associated with a tag of a Web page displayed at the browses.

36. The system of claim 14, wherein the step of causing the operations specified in said operation messages to be committed includes the step of said transaction manager sending commit messages to one or more database servers, wherein the commit messages cause said one or more database servers to commit changes associated with said multiple-request transactions as an atomic unit of work.

37. The system of claim 14, wherein the step of causing operations specified in said operation messages to be rolled back includes the step of said transaction manager sending rollback messages to one or more database servers, wherein the rollback messages cause said one or more database servers to roll back changes associated with said multiple-request transactions as an atomic unit of work.

38. The system of claim 14, wherein the step of said cartridge execution engine intercepting browses messages includes the step of said cartridge execution engine intercepting browses messages that include a begin transaction command; and in response to said cartridge execution engine receiving a browses message that includes a begin transaction command, said cartridge execution engine sending a transaction control message to said transaction manager to cause said transaction manager to begin said transaction.

39. The system of claim 14, wherein the step of said cartridge execution engine intercepting browses messages includes the step of said cartridge execution engine intercepting browses messages that include a commit transaction command; and in response to said cartridge execution engine receiving a browses message that includes a commit transaction command, said cartridge execution engine sending a transaction control message to said transaction manager to cause said transaction manager to commit said transaction.

40. The system of claim 14, wherein the step of said cartridge execution engine intercepting browses messages includes the step of said cartridge execution engine intercepting browses messages that include a rollback transaction command; and in response to said cartridge execution engine receiving a browses message that includes a rollback transaction command, said cartridge execution engine sending a transaction control message to said transaction manager to cause said transaction manager to roll back said transaction.

41. The method of claim 1, further comprising the steps of:
prior to intercepting browses messages directed to said cartridge, storing metadata that establishes a correlation between one or more transaction commands and one or more message items;
in response to intercepting browses messages directed to said cartridge, comparing the message items that are within each browses message with said metadata to determine whether a particular transaction command needs to be executed;
and if it is determined that a particular transaction command does need to be executed, including data within a transaction control message that will cause said transaction manager to perform the particular transaction command.

42. The computer readable medium, of claim 11, further comprising instructions for performing the steps of:
prior to intercepting browses messages directed to said cartridge, storing metadata that establishes a correlation between one or more transaction commands and one or message items;
in response to intercepting browses messages directed to said cartridge, comparing the message items that are within each browses message with said metadata to determine whether a particular transaction command needs to be executed;
and if it is determined that a particular transaction command does need to be executed, including data within a transaction control message that will cause said transaction manager to perform the particular transaction command.

43. The system of claim 14, further comprising the steps of:
prior to intercepting browser messages directed to said cartridge, storing metadata that establishes a correlation between one or more transaction commands and one or more message items;
in response to intercepting browser messages directed to said cartridge, comparing the message items that are within each browser message with said metadata to determine whether a particular transaction command needs to be executed;
and if it is determined that a particular transaction command does need to be executed, including data within a transaction control message that will cause said transaction manager to perform the particular transaction command.

44. A method for executing a transaction that involves a series of operations, the method comprising the steps of:
registering said transaction by storing metadata that establishes a mapping between transactions commands and message items;
receiving a series of browses messages that request performance of said series of operations;
in response to said series of browser messages, executing said series of operations as an atomic unit of work; and determining when to begin; commit and roll back said atomic unit of work based on message items in said series of browses messages: and said metadata.

45. The method of claim 44, wherein the step of registering said transaction further comprises the step of storing metadata that establishes a belong-to-list, wherein the belong-to-list identifies a set of one or more cartridges that may participate in performing said transaction.

46. The method of claim 44, wherein he step of registering said transaction further comprises the step of storing metadata that establishes a resource-list, wherein the resource-list identifies a set of one or more resources that are affected by performing the transaction.

47. The method of claim 44, wherein the step of registering said transaction further comprises the step of storing metadata that establishes a cartridge name, wherein the cartridge name identifies a particular type of cartridges that may be used to perform the transaction.

48. The method of claim 44, wherein the step of registering said transaction further comprises the step of storing metadata that establishes a transaction name, wherein the transaction name uniquely identifies a type of transaction relative to other transaction types.