Electrical computers and digital processing systems: multicomput – Computer-to-computer data routing – Least weight routing
Reexamination Certificate
1994-03-21
2001-12-11
Courtenay, III, St. John (Department: 2151)
Electrical computers and digital processing systems: multicomput
Computer-to-computer data routing
Least weight routing
C709S241000
Reexamination Certificate
active
06330582
ABSTRACT:
BACKGROUND OF THE INVENTION
The invention relates to transaction processing, and more particularly to a transaction processing system of the client/server type in which a client process creates a mechanism in a server process that controls bi-directional transaction message traffic between the client and server processes.
A transaction has been defined as a logical unit of work by C. J. Date in his work,
INTRODUCTION TO DATABASE SYSTEMS,
Volume I (Addison-Wesley, September, 1985). Date particularly taught that a transaction in the database context consists of a sequence of operations by which a database is transformed from one consistent state to another consistent state. A transaction processing system guarantees that a transaction will either complete the transformation of a database into a new consistent state, or return the database to the consistent state at which the transaction began.
A particularly useful architecture for implementing transaction processing in distributed systems is the client/server model that is described in H. M. Deitel's
OPERATING SYSTEMS
(Addison-Wesley, 1990). In this model, clients denote service consumers in the form of client processes, while servers are processes that provide the services. In a typical database system that provides transaction-based access to a plurality of users, users enter database requests through client processes. The client processes engage the server process in the form of a database management system to service the user request according to a predetermined transaction protocol.
From the standpoint of client and server processes, transactions may be considered as “objects”. As objects, transactions encompass the procedures and data necessary to satisfy a user request. As objects, transactions can be directly manipulated by clients and servers. The preferred mode of handling transaction objects is by messages that specify a particular type of manipulation. In this regard, a user request for reading records from a database may manipulate a transaction by specifying that the transaction must read the database and by providing parameters that establish where the reading is to take place, what records are to be read, etc. The transaction reports the outcome of the manipulation by returning a response message including the results of the operation.
Typically, objects are described by data structures that are referred to as “names”. Current techniques of object-oriented programming recognize a “named processing object” as an object having a name and including one or more procedures.
A transaction message implies a source and a destination. A current database management system, such as the IMS product available from INTERNATIONAL BUSINESS MACHINES CORPORATION, distinguishes these end points by the use of logical terminals (LTERMs). An LTERM provides a queue where transaction output from the IMS product resides. Eventually, the IMS product makes the connection between the queue and a physical node that will receive the queued output. In the client/server model, the IMS product is considered the server process. Such database systems do not afford a client process with a mechanism to control transaction message flow by specifying the source and destination of a transaction message.
Viewed from another aspect, the LTERM capability of the IMS product provides a uni-directional (server-to-client) pipeline that can only be manipulated by the server. In this respect, an LTERM suggests the pipe structure used in UNIX® systems (UNIX® is a registered trademark of Novell, Inc.). Pipes may be objectified by names. They provide uni-directional, FIFO data transfer between processes and include the capability of interprocess synchronization. Two pipes oriented in opposite directions between client and server processes can provide bi-directional message flow, but entail two processing objects, only one of which can be manipulated by the client process.
Manifestly, the more time a server must spend in transaction message processing, the less efficient it will be in processing transactions. Accordingly, there is a need in transaction-based systems of the client/server type to provide a mechanism that will allow any client process to objectify a transaction and to manipulate the transaction object by messages in a bi-directional message pipeline.
SUMMARY OF THE INVENTION
The invention provides a mechanism that can be manipulated as an object by a client process to control bi-directional transaction message traffic between the client process and a server process. The invention allows a client process to name the mechanism as an object at a server process. The named object (also referred to as a “Tpipe”) includes the ability to receive transaction request messages and transaction output messages at the server process and to associate transaction output messages with their ultimate destinations. Thus, the association between transaction output and its recipient is not made by a server process but is, rather, left to the client process.
The invention is embodied in both a mechanism and a procedure for bi-directional transport of transaction messages between server and client processes.
The invention affords flexibility to a transaction processing system of the client/server model in that many transaction outputs may simultaneously flow through the same Tpipe.
The invention allows a client process to create more than one Tpipe, thereby allowing distinctions to be made between transactions that occur naturally because of, for example, flow-control and synchronization differences.
The invention relieves the server process of responsibility for coupling a transaction output to an end user.
The invention provides client processes with control over the output of their submitted transactions.
REFERENCES:
patent: 4853843 (1989-08-01), Ecklund
patent: 5051892 (1991-09-01), Ferree et al.
patent: 5095421 (1992-03-01), Freund
patent: 5115392 (1992-05-01), Takamoto et al.
patent: 5195181 (1993-03-01), Bryant et al.
patent: 5249293 (1993-09-01), Schreiber et al.
patent: 5265250 (1993-11-01), Andrade et al.
patent: 5396630 (1995-03-01), Banda et al.
patent: 5428782 (1995-06-01), White
patent: 5440744 (1995-08-01), Jacobson et al.
Jim Gray, Transaction processing: concepts and techniques, 1993, pp. 259-347.
IBM Technical Bulletin “Network Deterministic Method of Routing Application Program Interfaces” vol. 36, No. 9B, 9/93, pp. 369-370.
IBM Technical Bulletin “Method for Forward Transitive Fully Connected Collection Management” 11/89, pp. 341-347.
IBM Technical Bulletin “Methodology for Serializing Asynchronous Network Requests Over Multiple Paths” No. 1, 1/93, pp. 151-156.
Rago, Stephen A., “UNIX® System V Network Programming”, Addison-Wesley Publishing Co, pp. 456-459, 1993.*
“Accessing CICS/ESA Application From A Non-CICS Environment”, IBM Technical Disclosure vol. 37, No. 02B, Feb. 1994.
European Search Report for EP 95 30 1835.
Kuo Steve Tsanchun
Morrison Thomas Clarke
Nguyen Hoang Minh
Radke Harry Otto
Courtenay III St. John
International Business Machines - Corporation
Sawyer Law Group LLP
LandOfFree
Apparatus and method enabling a client to control... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Apparatus and method enabling a client to control..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Apparatus and method enabling a client to control... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2597282