Disabling and enabling transaction committal in transactional application components

Abstract

A run-time environment implemented as system services and component integration interfaces provides a capability for components of a component-based server application to reversibly disable committal of a transaction in which the component participates. On return from a call to the component which leaves the component's transactional work in an invalid state, the component can disable commit of the transaction so as to avoid premature committal of the component's transactional work. On return from a call to the component which renders the component's transactional work in a valid state, the component re-enables commit of the transaction. If committal of the transaction is initiated when any component in the transaction disables commit, the transaction is aborted.

Claims

We claim:

1. In a distributed computer network, a method of coordinating work of a plurality of software components as an atomic transaction, comprising:

tracking a state of work of each component in a transaction, where the state of work may be reversibly set to a disable commit state;

on receiving a request to commit the transaction, determining whether a state of work of any component in the transaction is the disable commit state; and

disallowing committal of all work of the components in the transaction if a state of work of any component in the transaction is the disable commit state.

2. The method of claim 1 further comprising:

aborting all work of the components in the transaction if a state of work of any component in the transaction is the disable state.

3. The method of claim 1 wherein the state of work of a component also may be set to an abort state, the method further comprising:

aborting all work of the components in the transaction if a state of work of any component in the transaction is the abort state.

4. The method of claim 1 further comprising:

maintaining context data of the components external to the components, the context data comprising the state of work of the components in the transaction.

5. An execution environment of component-based server applications for avoiding premature committal of work by server application components in a transaction, comprising:

a transaction manager for selectively committing or aborting work of a plurality of server application components in a transaction as an atomic unit; and

an interface for calling by the server application components, the interface having an abort function for causing the transaction manager to abort the transaction, a disable commit function for temporarily and reversibly disabling commit of the transaction by the transaction manager, and an enable commit for reversing the disabling of commit of the transaction;

whereby one of the server application components can prevent premature committal of as yet incomplete work in the transaction by calling the disable commit function.

6. The execution environment of claim 5 further comprising:

a second interface having a commit function for initiating committal of the transaction by the transaction manager, the transaction manager being operative to suppress committal when committal is initiated and any of the components in the transaction has disabled commit.

7. The execution environment of claim 6 further comprising:

a second interface having a commit function for initiating committal of the transaction by the transaction manager, the transaction manager being operative to abort the transaction when committal is initiated and any of the components in the transaction has disabled commit.

8. An execution environment of component-based server applications for avoiding premature committal of work by server application components in a transaction, comprising:

a component context associated with each component for recording a value indicating a state of work of the associated component in the transaction;

an interface having a disable commit function for calling by a component to set the value in its associated component context to indicate a disable commit state, and having an enable commit function for calling by the component to set the value in its associated component context to indicate an enable commit state; and

a transaction manager operative responsive to a commit signal to determine whether a state of work of any component is the disable commit state, and to disallow committal of the transaction if a state of work of any component in the transaction is the disable commit state.

9. The execution environment of claim 8 wherein the transaction manager is operative to abort the transaction if a state of work of any component in the transaction is the disable commit state.

10. A computer readable storage medium having computer executable instructions stored thereon for avoiding premature committal of transactional work of a component-based server application, the instructions comprising:

code for reversibly disabling committal of a transaction on return from a first call to a component of the server application in which transactional work of the component is left in an invalid state;

code for again enabling committal of the transaction on return from a second call to the component in which the component's transactional work is left in a valid state; and

code for suppressing committal of the transaction if any component in the transaction currently disables committal of the transaction.

11. The computer readable storage medium of claim 10 wherein the instructions further comprise:

code for aborting the transaction if, when committal is initiated, any component in the transaction currently disables committal of the transaction.

Description

FIELD OF THE INVENTION

The present invention relates to a server application programming model using software components, and more particularly relates to the component having control over whether a transaction in which the component participates can be committed.

BACKGROUND AND SUMMARY OF THE INVENTION

In many information processing applications, a server application running on a host or server computer in a distributed network provides processing services or functions for client applications running on terminal or workstation computers of the network which are operated by a multitude of users. Common examples of such server applications include software for processing class registrations at a university, travel reservations, money transfers and other services at a bank, and sales at a business. In these examples, the processing services provided by the server application may update databases of class schedules, hotel reservations, account balances, order shipments, payments, or inventory for actions initiated by the individual users at their respective stations.

Often, server applications require coordinating activities on multiple computers, by separate processes on one computer, and even within a single process. For example, a money transfer operation in a banking application may involve updates to account information held in separate databases that reside on separate computers. Desirably, groups of activities that form parts of an operation are coordinated so as to take effect as a single indivisible unit of work, commonly referred to as a transaction. In many applications, performing sets of activities as a transaction becomes a business necessity. For example, if only one account is updated in a money transfer operation due to a system failure, the bank in effect creates or loses money for a customer.

A transaction is a collection of actions that conform to a set of properties (referred to as the "ACID" properties) which include atomicity, consistency, isolation, and durability. Atomicity means that all activities in a transaction either take effect together as a unit, or all fail. Consistency means that after a transaction executes, the system is left in a stable or correct state (i.e., if giving effect to the activities in a transaction would not result in a correct stable state, the system is returned to its initial pre-transaction state). Isolation means the transaction is not affected by any other concurrently executing transactions (accesses by transactions to shared resources are serialized, and changes to shared resources are not visible outside the transaction until the transaction completes). Durability means that the effects of a transaction are permanent and survive system failures. For additional background information on transaction processing, see, inter alia, Jim Gray and Andreas Reuter, Transaction Processing Concepts and Techniques, Morgan Kaufmann, 1993.

In many current systems, services or extensions of an operating system referred to as a transaction manager or transaction processing (TP) monitor implement transactions. A transaction is initiated by a client program, such as in a call to a "begin.sub.-- transaction" application programming interface (API) of the transaction monitor. Thereafter, the client initiates activities of a server application or applications, which are performed under control of the TP monitor. The client ends the transaction by calling either a "commit.sub.-- transaction" or "abort.sub.-- transaction" API of the TP monitor. On receiving the "commit.sub.-- transaction" API call, the TP monitor commits the work accomplished by the various server application activities in the transaction, such as by effecting updates to databases and other shared resources. Otherwise, a call to the "abort.sub.-- transaction" API causes the TP monitor to "roll back" all work in the transaction, returning the system to its pre-transaction state.

In systems where transactions involve activities of server applications on multiple computers, a two-phase commit protocol often is used. In general, the two-phase commit protocol centralizes the decision to commit, but gives a right of veto to each participant in the transaction. In a typical implementation, a commit manager node (also known as a root node or transaction coordinator) has centralized control of the decision to commit, which may for example be the TP monitor on the client's computer. Other participants in the transaction, such as TP monitors on computers where a server application performs part of the work in a transaction, are referred to as subordinate nodes. In a first phase of commit, the commit manager node sends "prepare.sub.-- to.sub.-- commit" commands to all subordinate nodes. In response, the subordinate nodes perform their portion of the work in a transaction and return "ready.sub.-- to.sub.-- commit" messages to the commit manager node. When all subordinate nodes return ready.sub.-- to.sub.-- commit messages to the commit manager node, the commit manager node starts the second phase of commit. In this second phase, the commit manager node logs or records the decision to commit in durable storage, and then orders all the subordinate nodes to commit their work making the results of their work durable. On committing their individual portions of the work, the subordinate nodes send confirmation messages to the commit manager node. When all subordinate nodes confirm committing their work, the commit manager node reports to the client that the transaction was completed successfully. On the other hand, if any subordinate node returns a refusal to commit during the first phase, the commit manager node orders all other subordinate nodes to roll back their work, aborting the transaction. Also, if any subordinate node fails in the second phase, the uncommitted work is maintained in durable storage and finally committed during failure recovery.

In transaction processing, it is critical that the client does not pre-maturely commit a server application's work in a transaction (such as database updates). For example, where the activity of a server application in a transaction is to generate a sales order entry, the server application may impose a requirement that a valid sales order entry have an order header (with customer identifying information filled in) and at least one order item. The client therefore should not commit a transaction in which the server application generates a sales order before both an order header and at least one order item in the sales order has been generated. Such application-specific requirements exist for a large variety of server application activities in transactions.

Historically, pre-mature client committal of a server application's work in a transaction generally was avoided in two ways. First, the server application can be programmed such that its work in a transaction is never left in an incomplete state when returning from a client's call. For example, the server application may implement its sales order generation code in a single procedure which either generates a valid sales order complete with both an order header and at least one order item, or returns a failure code to cause the client to abort the transaction. The server application's work thus is never left in an incomplete state between calls from the client, and would not be committed prematurely if the client committed the transaction between calls to the server application.

Second, the client and server application typically were developed together by one programmer or a group of programmers in a single company. Consequently, since the programmers of the server application and client were known to each other, the server application programmers could ensure that the client was not programmed to commit a transaction between calls that might leave the server application's work in an incomplete state. For example, the client's programmers could be told by the server application programmers not to call the commit.sub.-- transaction API after a call to the server application that sets up an order header and before a call to the server application that adds an order item.

These historical approaches to avoiding pre-mature committal of server application work in a transaction are less effective for, and in some ways antithetical to, component-based server applications that are programmed using object-oriented programming techniques.

In object-oriented programming, programs are written as a collection of object classes which each model real world or abstract items by combining data to represent the item's properties with functions to represent the item's functionality. More specifically, an object is an instance of a programmer-defined type referred to as a class, which exhibits the characteristics of data encapsulation, polymorphism and inheritance. Data encapsulation refers to the combining of data (also referred to as properties of an object) with methods that operate on the data (also referred to as member functions of an object) into a unitary software component (i.e., the object), such that the object hides its internal composition, structure and operation and exposes its functionality to client programs that utilize the object only through one or more interfaces. An interface of the object is a group of semantically related member functions of the object. In other words, the client programs do not access the object's data directly, but must instead call functions on the object's interfaces to operate on the data.

Polymorphism refers to the ability to view (i.e., interact with) two similar objects through a common interface, thereby eliminating the need to differentiate between two objects. Inheritance refers to the derivation of different classes of objects from a base class, where the derived classes inherit the properties and characteristics of the base class.

Object-oriented programming generally has advantages in ease of programming, extensibility, reuse of code, and integration of software from different vendors and (in some object-oriented programming models) across programming languages. However, object-oriented programming techniques generally are antithetical to the above described historical approaches to avoiding pre-mature committal of server application work.

First, object-oriented programming techniques encourage accomplishing work in multiple client-to-object interactions. Specifically, object-oriented programming encourages setting an object's properties in calls to separate member functions, then carrying out the work with the set properties in a call to a final member function. For example, a money transfer object may provide a set of member functions that includes a SetDebitAccount( ) function, a SetCreditAccount( ) function, a SetTransferAmount( ) function, etc. that the client program calls to set the object's properties. Finally, the client program may call a TransferMoney( ) function to cause the object to perform the money transfer operation using the accumulated object properties (also referred to as the object's state). Between these separate client-object interactions, server application work may often be left in an incomplete state. The object-oriented programming style thus is contrary to the above described approach to avoiding pre-mature committal wherein server application work is never left incomplete on return from a client call.

Second, object-oriented programming also encourages integration of objects supplied from unrelated developers and companies. When the server application is built from object classes supplied from unrelated vendors, there is less opportunity for direct collaboration between developers of the server application and the client. Without direct collaboration, the developer of an object used in a server application generally cannot ensure that the developer of a client will not commit a transaction between calls to the server application object which leave the server application's work in an incomplete state. Thus, the second above described approach to avoiding pre-mature committal also is less effective in component-based server applications.

The present invention avoids premature committal of component-based server application work by allowing a server application component to have control over whether the client can commit a transaction involving the component's work. According to one aspect of the invention, an execution environment for server application components provides functions that a server application component calls to temporarily and reversibly enable and disable, respectively, committal of a transaction in which the component participates. The component calls the function to disable committal upon returning from a client call that leaves the components work in an incomplete state. On the other hand, if the component's work is in a complete or valid state, the component calls the function to enable transaction committal on return from the client call. The invention thus implements an approach to avoid premature committal that allows a server application to leave its transactional work in an incomplete state between client interactions, and allows easier integration of application components from independent sources (e.g., by not relying on direct collaboration between developers to avoid premature committal).

Additional features and advantages of the invention will be made apparent from the following detailed description of an illustrated embodiment which proceeds with reference to the accompanying drawings.

BRIEF DESCRIPTION OF THE DRAWINGS

FIG. 1 is a block diagram of a distributed computer system that may be used to implement a method and apparatus embodying the invention for avoiding premature committal of work in a transaction.

FIG. 2 is a block diagram of a server application component execution environment provided by a server executive on a server computer in the distributed computer system of FIG. 1.

FIG. 3 is a block diagram of the structure of a server application component in the execution environment of FIG. 2.

FIG. 4 is a flow chart of a method performed by the server executive in the execution environment of FIG. 2 to automatically control transaction processing of server application components' work.

FIGS. 5-7 are flow charts illustrating use of disable commit and enable commit during transaction processing in a client process, server application component, and transaction manager within the execution environment of FIG. 2.

DETAILED DESCRIPTION OF THE ILLUSTRATED EMBODIMENTS

The present invention is directed toward a method and system for avoiding premature committal of server application work. In one embodiment illustrated herein, the invention is incorporated into an application server execution environment or platform, entitled "Microsoft Transaction Server," marketed by Microsoft Corporation of Redmond, Wash. Briefly described, this software provides a run-time environment and services to support component-based server applications in a distributed network.

Exemplary Operating Environment

FIG. 1 and the following discussion are intended to provide a brief, general description of a suitable computing environment in which the invention may be implemented. While the invention will be described in the general context of computer-executable instructions of a computer program that runs on a server computer, those skilled in the art will recognize that the invention also may be implemented in combination with other program modules. Generally, program modules include routines, programs, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the invention may be practiced with other computer system configurations, including single- or multiprocessor computer systems, minicomputers, mainframe computers, as well as personal computers, hand-held computing devices, microprocessor-based or programmable consumer electronics, and the like. The illustrated embodiment of the invention also is practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. But, some embodiments of the invention can be practiced on stand-alone computers. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.

With reference to FIG. 1, an exemplary system for implementing the invention includes a conventional server computer 20, including a processing unit 21, a system memory 22, and a system bus 23 that couples various system components including the system memory to the processing unit 21. The processing unit may be any of various commercially available processors, including Intel x86, Pentium and compatible microprocessors from Intel and others, including Cyrix, AMD and Nexgen; Alpha from Digital; MIPS from MIPS Technology, NEC, IDT, Siemens, and others; and the PowerPC from IBM and Motorola. Dual microprocessors and other multi-processor architectures also can be used as the processing unit 21.

The system bus may be any of several types of bus structure including a memory bus or memory controller, a peripheral bus, and a local bus using any of a variety of conventional bus architectures such as PCI, VESA, Microchannel, ISA and EISA, to name a few. The system memory includes read only memory (ROM) 24 and random access memory (RAM) 25. A basic input/output system (BIOS), containing the basic routines that help to transfer information between elements within the server computer 20, such as during start-up, is stored in ROM 24.

The server computer 20 further includes a hard disk drive 27, a magnetic disk drive 28, e.g., to read from or write to a removable disk 29, and an optical disk drive 30, e.g., for reading a CD-ROM disk 31 or to read from or write to other optical media. The hard disk drive 27, magnetic disk drive 28, and optical disk drive 30 are connected to the system bus 23 by a hard disk drive interface 32, a magnetic disk drive interface 33, and an optical drive interface 34, respectively. The drives and their associated computer-readable media provide nonvolatile storage of data, data structures, computer-executable instructions, etc. for the server computer 20. Although the description of computer-readable media above refers to a hard disk, a removable magnetic disk and a CD, it should be appreciated by those skilled in the art that other types of media which are readable by a computer, such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, and the like, may also be used in the exemplary operating environment.

A number of program modules may be stored in the drives and RAM 25, including an operating system 35, one or more application programs 36, other program modules 37, and program data 38. The operating system 35 in the illustrated server computer is the Microsoft Windows NT Server operating system, together with the before mentioned Microsoft Transaction Server.

A user may enter commands and information into the server computer 20 through a keyboard 40 and pointing device, such as a mouse 42. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 21 through a serial port interface 46 that is coupled to the system bus, but may be connected by other interfaces, such as a parallel port, game port or a universal serial bus (USB). A monitor 47 or other type of display device is also connected to the system bus 23 via an interface, such as a video adapter 48. In addition to the monitor, server computers typically include other peripheral output devices (not shown), such as speakers and printers.

The server computer 20 may operate in a networked environment using logical connections to one or more remote computers, such as a remote client computer 49. The remote computer 49 may be a workstation, a server computer, a router, a peer device or other common network node, and typically includes many or all of the elements described relative to the server computer 20, although only a memory storage device 50 has been illustrated in FIG. 1. The logical connections depicted in FIG. 1 include a local area network (LAN) 51 and a wide area network (WAN) 52. Such networking environments are commonplace in offices, enterprise-wide computer networks, intranets and the Internet.

When used in a LAN networking environment, the server computer 20 is connected to the local network 51 through a network interface or adapter 53. When used in a WAN networking environment, the server computer 20 typically includes a modem 54, or is connected to a communications server on the LAN, or has other means for establishing communications over the wide area network 52, such as the Internet. The modem 54, which may be internal or external, is connected to the system bus 23 via the serial port interface 46. In a networked environment, program modules depicted relative to the server computer 20, or portions thereof, may be stored in the remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.

In accordance with the practices of persons skilled in the art of computer programming, the present invention is described below with reference to acts and symbolic representations of operations that are performed by the server computer 20, unless indicated otherwise. Such acts and operations are sometimes referred to as being computer-executed. It will be appreciated that the acts and symbolically represented operations include the manipulation by the processing unit 21 of electrical signals representing data bits which causes a resulting transformation or reduction of the electrical signal representation, and the maintenance of data bits at memory locations in the memory system (including the system memory 22, hard drive 27, floppy disks 29, and CD-ROM 31) to thereby reconfigure or otherwise alter the computer system's operation, as well as other processing of signals. The memory locations where data bits are maintained are physical locations that have particular electrical, magnetic, or optical properties corresponding to the data bits.

Server Application Execution Environment

With reference now to FIG. 2, a transaction server executive 80 provides run-time or system services to create a run-time execution environment 80 that supports enabling and disabling transaction committal by server application components (e.g., server application component 86) on a server computer 84. The transaction server executive 80 also provides services for thread and context management to the server application components 86. Included in the services are a set of API functions, including a GetObjectContext and a SafeRef API functions described below. Additionally, the transaction server executive 80 provides system-defined objects (including a component context object 136) that support component integration interfaces.

The illustrated transaction server executive 80 is implemented as a dynamic link library ("DLL"). (A DLL is a well-known executable file format which allows dynamic or run-time linking of executable code into an application program's process.) The transaction server executive 80 is loaded directly into application server processes (e.g., "ASP" 90) that host server application components, and runs transparently in the background of these processes.

The illustrated ASP 90 is a system process that hosts execution of server application components. Each ASP 90 can host multiple server application components that are grouped into a collection called a "package." Also, multiple ASPs 90 can execute on the server computer under a multi-threaded, multi-tasking operating system (e.g., Microsoft Windows NT in the illustrated embodiment). Each ASP 90 provides a separate trust boundary and fault isolation domain for the server application components. In other words, when run in separate ASPs, a fault by one server application component which causes its ASP to terminate generally does not affect the server application components in another ASP. In the illustrated embodiment, server application components are grouped as a package to be run together in one ASP 90 using an administration utility called "the Transaction Server Explorer." This utility provides a graphical user interface for managing attributes associated with server application components, including grouping the components into packages.

In a typical installation shown in FIG. 2, the execution environment 80 is on the server computer 84 (which may be an example of the computer 20 described above) that is connected in a distributed computer network comprising a large number of client computers 92 which access the server application components in the execution environment. Alternatively, the execution environment 80 may reside on a single computer and host server application components accessed by client processes also resident on that computer.

Server Application Components

The server application components 86 that are hosted in the execution environment 80 of the ASP 90 implement the business logic of a server application, such as the code to manage class registrations in a university's registration application or orders in an on-line sales application. Typically, each server application comprises multiple components, each of which contains program code for a portion of the application's work. For example, a banking application may comprise a transfer component, a debit account component, and a credit account component which perform parts of the work of a money transfer operation in the application. The debit account component in this banking application example implements program code to debit a specified account in a banking database by a specified amount. The credit account component implements program code to credit a specified account in the database by a specified amount. The transfer component implements program code that uses the debit account component and credit account component to effect a money transfer between two accounts.

With reference now to FIG. 3, the server application component 86 (FIG. 2) in the illustrated embodiment conforms to the Component Object Model ("COM") of Microsoft Corporation's OLE and ActiveX specifications (i.e., is implemented as a "COM Object"), but alternatively may be implemented according to other object standards including the CORBA (Common Object Request Broker Architecture) specification of the Object Management Group. OLE's COM specification defines binary standards for components and their interfaces which facilitate the integration of software components. For a detailed discussion of OLE, see Kraig Brockschmidt, Inside OLE, Second Edition, Microsoft Press, Redmond, Wash., 1995.

In accordance with COM, the server application component 86 is represented in the computer system 20 (FIG. 1) by an instance data structure 102, a virtual function table 104, and member functions 106-108. The instance data structure 102 contains a pointer 110 to the virtual function table 104 and data 112 (also referred to as data members, or properties of the component). A pointer is a data value that holds the address of an item in memory. The virtual function table 104 contains entries 116-118 for the member functions 106-108. Each of the entries 116-118 contains a reference to the code 106-108 that implements the corresponding member function.

The pointer 110, the virtual function table 104, and the member functions 106-108 implement an interface of the server application component 86. By convention, the interfaces of a COM object are illustrated graphically as a plug-in jack as shown for the server application component 100 in FIG. 3. Also, Interfaces conventionally are given names beginning with a capital "I." In accordance with COM, the server application component 86 can include multiple interfaces which are implemented with one or more virtual function tables. The member function of an interface is denoted as "IInterfaceName::FunctionName."

The virtual function table 104 and member functions 106-108 of the server application component 86 are provided by a server application program 120 (hereafter "server application DLL") which is stored in the server computer 84 (FIG. 2) as a dynamic link library file (denoted with a ".dll" file name extension). In accordance with COM, the server application DLL 120 includes code for the virtual function table 104 (FIG. 3) and member functions 106-108 (FIG. 3) of the classes that it supports, and also includes a class factory 122 that generates the instance data structure 102 (FIG. 3) for a component of the class.

Like any COM object, the sever application component can maintain internal state (i.e., its instance data structure 102 including data members 112) across multiple interactions with a client (i.e., multiple client program calls to member functions of the component). The server application component that has this behavior is said to be "stateful." The server application component can also be "stateless," which means the component does not hold any intermediate state while waiting for the next call from a client.

In the execution environment 80 of FIG. 2, the server application component 86 is executed under control of the transaction server executive 80 in the ASP 90. The transaction server executive 80 is responsible for loading the server application DLL 300 into the ASP 90 and instantiating the server application component 86 using the class factory 122. The transaction server executive 80 further manages calls to the server application component 86 from client programs (whether resident on the same computer or over a network connection).

The illustrated execution environment 80 imposes certain additional requirements on the server application component 86 beyond conforming with COM requirements. First, the server application component is implemented in a DLL file (i.e., the server application DLL 120 of FIG. 3). (COM objects otherwise alternatively can be implemented in an executable (".exe") file.) Second, the component's DLL file 120 has a standard class factory 122 (i.e., the DLL implements and exports the DllGetClassObject function, and supports the IClassFactory interface). Third, the server application component exports only interfaces that can be standard marshaled, meaning the component's interfaces are either described by a type library or have a proxy-stub DLL. The proxy-stub DLL provides a proxy component 130 in a client process 132 on the client computer 92, and a stub component 131 in the ASP 90 on the server computer 84. The proxy component 130 and stub component 131 marshal calls from a client program 134 across to the server computer 84. The proxy-stub DLL in the illustrated system is built using the MIDL version 3.00.44 provided with the Microsoft Win32 SDK for Microsoft Windows NT 4.0 with the Oicf compiler switch, and linked with the transaction server executive 80. These additional requirements conform to well known practices.

The client program 134 of the server application component 86 is a program that uses the server application component. The client program can be program code (e.g., an application program, COM Object, etc.) that runs outside the execution environment 80 (out of the control of the transaction server executive 80). Such client programs are referred to as "base clients." Alternatively, the client program 134 can be another server application component that also runs under control of the transaction server executive (either in the same or a separate ASP 90). The client program 134 can reside on the server computer 84 or on a separate client computer 92 as shown in FIG. 2 (in which case the client computer interacts with the server application component 86 remotely through the proxy object 130 and stub object 131).

Before the server application component 86 can execute in the illustrated execution environment 80, the server application component 86 is first installed on the server computer 84. As with any COM object, the server application component 86 is installed by storing the server application DLL file 120 that provides the server application component 86 in data storage accessible by the server computer (typically the hard drive 27, shown in FIG. 1, of the server computer), and registering COM attributes (e.g., class identifier, path and name of the server application DLL file 120, etc. as described below) of the server application component in the system registry. The system registry is a configuration database. In addition to the server application component's COM attributes, the server application is registered in the system registry with a "transaction server execution" attribute indicating that the server application component is run under control of the transaction server executive in the illustrated execution environment 80. In the illustrated embodiment, this attribute has the form shown in the following example registry entry.

    ______________________________________
    HKBY.sub.-- CLASSES.sub.-- ROOT.backslash.CLSID.backslash.{AB077646-B902-1
    1D0-B5BE-
    00C04FB957D8}.backslash.LocalServer32 = C:.backslash.WINNT.backslash.Syste
    m32.backslash.mtx.exe
    /p:{DA16F24B-2B23-11D1-8116-00C04FC2F9C1}
    ______________________________________

    ______________________________________
    DECLARE.sub.-- INTERFACE.sub.-- (IObjectContext, IUnknown)
    // IUnknown functions
    HRESULT QueryInterface(THIS.sub.-- REFIID riid, LPVOID FAR*
    ppvObj);
    ULONG AddRef(THIS);
    ULONG Release(THIS);
    // IObjectContext functions
    HRESULT CreateInstance(THIS.sub.-- REFCLSID relsid, REFIID
    riid, LPVOID FAR* ppvObj);
    HRESULT SetComplete(THIS);
    HRESULT SetAbort(THIS);
    HRESULT EnableCommit(THIS);
    HRESULT DisableCommit(THIS);
    BOOL IsInTransaction(THIS);
    };
    ______________________________________

                  TABLE 1
    ______________________________________
    EnableCommit return values
    Value           Description
    ______________________________________
    S.sub.-- OK     Transaction enabled for commit.
    E.sub.-- FAIL   A server failure occurred.
    E.sub.-- UNEXPECTED
                    An unexpected error occurred.
    ______________________________________

                  TABLE 2
    ______________________________________
    DisableCommit return values
    Value          Description
    ______________________________________
    S.sub.-- OK    Transaction disabled for commit.
    E.sub.-- FAIL  A server failure occurred.
    E.sub.-- UNEXPECTED
                   An unexpected error occurred.
    E.sub.-- NOCONTEXT
                   Not executing in a server application
                   component under control of the
                   transaction server executive 80.
    ______________________________________

• Inventors
  Helland, Patrick James; Limprecht, Rodney; Al-Ghosein, Mohsen;
• Assignee
  Microsoft Corporation (Redmond, WA)
• Published
  Sep-28-1999
• Current US Classes:
  707/201
  709/203
  709/223
  718/101
• Application #
  959142
• International Classes
  G06F 013/00; G06F 017/30
• Field of Search
  709/100 709/101 709/202 709/201 709/203 709/219 709/223 709/224 709/225 709/227 709/300 709/303 707/10 707/100 707/103 707/104 707/200 707/201
• Examiner
  Vu; Viet D.
• Agent
  Klarquist Sparkman Campbell Leigh & Whinston, LLP