Automatic transaction processing of component-based server applications

A component-based framework includes system services and component integration interfaces that provide a run-time environment which automatically provides transactions to encompass work of component-based server applications according to the transactional expectations of individual server application components. A transaction attribute is associated with each server application component that represents whether the component requires execution in a transaction. When a client requests creation of a server application component without having first initiated a transaction and the component's transaction attribute indicates a transaction is required, the framework automatically initiates a transaction in which to run the server application component. The framework also completes the automatically initiated transaction upon receiving an indication from the server application component that its transactional work is complete.

FIELD OF THE INVENTION 
The present invention relates to a server application-programming model 
using software components, and more particularly relates to transaction 
processing with the server application components. 
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 that may be geographically remote. 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 the prior transaction processing systems discussed above, transactions 
are initiated and completed by explicit programming in the client program, 
such as by calls to the begin.sub.-- transaction, commit.sub.-- 
transaction and abort.sub.-- transaction APIs of the transaction monitor. 
This adds to complexity and increases the burden of programming the server 
application and client program. Specifically, the client program must be 
programmed to properly initiate and complete a transaction whenever it 
uses a server application to perform work that requires a transaction 
(e.g., work which involves multiple database updates that must be 
completed together as an atomic unit of work). The server application, on 
the other hand, relies on its clients to properly manage transactions, and 
cannot guarantee that all client programs properly initiate and complete 
transactions when using the server application. The server application 
therefore must be programmed to handle the special case where the client 
fails to initiate a needed transaction when using the server application. 
The requirement of a client program to explicitly initiate and complete 
transactions can pose further difficulties in programming models in which 
the server application is implemented as separate software components, 
such as in object-oriented programming ("OOP" ). 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 models 
can increase the complexity and thus programming difficulty of the server 
application where transaction processing requires explicit initiation and 
completion by client programs. In particular, by encouraging integration 
of software components from different vendors, an object-oriented 
programming model makes it more difficult for programmers to ensure that 
the client program properly initiates and completes transactions involving 
the server application's work. Components that are integrated to form the 
server application and client programs may be supplied by programmers and 
vendors who do not directly collaborate, such that it is no longer 
possible to enforce proper behavior of other components by knocking on a 
colleague's door down the hall. In the absence of direct collaboration, 
the programmers often must carefully program the components to handle 
cases where transactions are not properly initiated and completed by the 
components' clients. 
The present invention frees component-based server applications from 
reliance on explicit programming of their clients to properly manage 
transaction processing by automatically providing a transaction to 
encompass a server application component's work according to a server 
application component's transactional expectations. This simplifies 
programming of server applications, since the server application 
components need not be programmed to handle special cases where a client 
program that uses the component fails to initiate a transaction. The task 
of programming client also is simplified since the client program need not 
explicitly initiate and complete transactions even for server application 
components that require transactions. 
According to one aspect of the invention, server application components are 
run in an execution environment under control of a system-provided 
service. In this execution environment, a transactional attribute is 
associated with the server application component to indicate its 
transactional expectations. For example, the transactional attribute of a 
server application component that performs multiple database updates can 
be set to indicate a transaction is required. Then, if a client program 
fails to provide a transaction when using the component, the system 
service automatically initiates a transaction to encompass the component's 
work. The system service also automatically ends the transaction after the 
work in the transaction is complete. 
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.

DETAILED DESCRIPTION OF THE ILLUSTRATED EMBODIMENTS 
The present invention is directed toward a method and system for automatic 
transactions with object-oriented component-based server applications. 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 
on a server computer 84 that automatically provides transactions to 
encompass work of a server application component (e.g., server application 
component 86) according to its transactional expectations. The transaction 
server executive 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 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. 
______________________________________ 
HKEY.sub.--