Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1994-10-11
2001-11-13
Banankhah, Majid (Department: 2151)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C709S241000
Reexamination Certificate
active
06317773
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to transaction processing systems including stand-alone and distributed transaction processing systems. More particularly, the present invention relates to the use of computer implemented objects to implement a transaction processing system that supports object oriented transaction processing, but also integrates procedural transaction coordinators. Still more particularly, the present invention provides a system and method for allowing object oriented transaction processing applications to interoperate with procedural transaction processing applications.
2. Background and Related Art
Computer implemented transaction processing systems are used for critical business tasks in a number of industries. A transaction defines a single unit of work that must either be fully completed or fully purged without action. For example, in the case of a bank automated teller machine (ATM) from which a customer seeks to withdraw money, the actions of issuing the money, reducing the balance of money on hand in the machine and reducing the customer's bank balance must all occur or none of them must occur. Failure of one of the subordinate actions would lead to inconsistency between the records and actual occurrences.
Distributed transaction processing involves a transaction that affects resources at more than one physical or logical location. In the above example, an ATM transaction affects resources managed at the local ATM device as well as bank balances managed by a bank's main computer. A distributed transaction may not be physically distributed but may involve cooperating tasks that must be completed in synchrony for successful transaction completion.
The X/Open Company Limited (X/Open is a trademark of X/Open Company Ltd.) has promulgated a guide that describes one model for implementing distributed transaction processing. The
X/Open Guide, Distributed Transaction Processing Reference Model
, October, 1991, discusses the components of a distributed transaction system and the interrelationships between them. The X/Open Distributed Transaction Processing Model (the DTP Model) describes three main components: an Application Program (AP), a Transaction Manager (TM), and one or more Resource Managers (RMs). The Application Program uses and modifies the resources controlled by one or more of the Resource Managers. The Transaction Manager is responsible for global transactions and coordinates the decision whether to commit or roll-back the actions taken by the Resource Managers. (Commit causes the resources to be updated while roll-back causes all work to be discarded returning the resources to the state they were in upon transaction initiation.) The Resource Managers manage specific resources. Resource managers may include a database management system (DBMS), a file system, or similar resource.
Object oriented programming systems are designed to increase the efficiency of program development by enabling object reuse and simplifying system maintenance through clear separation of function. Each object in an object oriented system encapsulates the data for that object and the procedures or methods for operating on that data. Encapsulation means that the data for an object can be manipulated only by that object using the defined methods. Object oriented systems also implement object inheritance. Inheritance allows a more specific object to be derived from a general object. The more specific object can “inherit” all of the data and methods of the parent object, but can override selected data and methods and add others to implement its unique function.
The application of object oriented techniques to transaction processing systems raises many new issues but offers opportunities to increase system efficiency through the use of object oriented principles. The Object Management Group, Inc. (OMG) has established standards for interoperable object oriented systems. The overall architecture defined by OMG is the Common Object Request Broker Architecture (CORBA). CORBA defines the interactions between objects, and in particular, between distributed objects in different computer systems. OMG has accepted submission of a proposal to standardize transaction processing in object oriented systems. This submission, entitled the
Object Transaction Service
(
OTS
), sets forth the requirements for object services necessary to implement a transaction processing system. The OTS specification uses many of the unique capabilities of object oriented systems. The OTS model, however, is designed to allow interoperability with the X/Open DTP model and with existing procedural transaction processing systems through implementation of a mapping of the two-phase commit functions
The proposed OMG Object Transaction Service describes mapping of the object oriented interfaces to existing X/Open DTP interfaces. This mapping is all that is specified in the OMG submission. The overall problem that exists is to define the methods required to give isolation to the application program interfaces and then to build the actual methods. The first problem within this overall problem is to define the methods necessary to allow object oriented transactional requests to interoperate with procedural, transactional requests. These methods must allow for and support coordination of two-phase commit protocols between the OMG Object Transaction Service model and the X/Open DTP model. The mapping is between OMG functions (such as demarcation, propagation, involvement, and coordination) and procedural transaction manager functions (such as the formal two-phase commit protocols, transaction identifiers, directory/location management, and transaction states). This coordination must occur within the transaction service and be isolated from the user interface level.
A second problem is provision of a mechanism to allow transactional object oriented application program requests to effectively exist with transactional. procedural application program requests in a single atomic transaction. In particular, there is a need to develop an object based approach that provides the object-oriented application interfaces while also providing access to procedural transaction services without requiring changes to the procedural operations within the application program.
An additional problem is provision of an object based structure that is flexible enough to allow different procedural transaction managers to be plugged into the object oriented system without changing the overall object structure. Having this structure would allow the OMG Object Transaction Service interfaces to the client applications, Object Request Brokers, and resources (Resource Managers) to be preserved and also to preserve the classes that implement the function defined in the OMG OTS class specifications.
The technical problem therefore exists to develop a set of object oriented classes to efficiently connect object oriented applications to procedural transaction managers without modifying either the procedural transaction manager or existing procedural applications.
SUMMARY OF THE INVENTION
The present invention is directed to a system and method for implementing an object transaction service that supports all OMG object oriented OTS application interfaces and provides transparent access to existing procedural transaction managers.
The changes required for differing procedural transaction managers are encapsulated within the implementation classes described in this invention. These implementation classes provide the bridge between the object environment and the existing procedural environments.
The present invention is directed to an object oriented computer system for transaction processing comprising: means for receiving a message to perform a transaction service operation; routing means for routing the message to an object method for performing the procedural transaction service; and implementation class means for enabling processing of the transaction service operation in response to the messag
Cobb Edward Ellis
Freund Thomas James
Holdsworth Simon Antony James
Houston Iain Stuart Caldwell
Smith Stanley Alan
Banankhah Majid
International Business Machines - Corporation
Mims Jr. David A.
Walker Mark S.
LandOfFree
System and method for creating an object oriented... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and method for creating an object oriented..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for creating an object oriented... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2593294