Patent Application
20100318394
In some situations, it may be desired to perform a group of operations using one or more computer-implemented resources. For instance, in a distributed transaction, a bundle of operations is performed by a group of network hosts. In a typical distributed transaction, a transaction manager coordinates the performance of the bundles of operations by the network hosts, which provide the resources for performing the operations. Atomicity is desired for a distributed transaction, such that either all of the operations are performed or none of them are. In another case, a group of operations may be desired to be performed by a single network host in a non-distributed fashion.
Similarly to the distributed transaction case, atomicity may be desired for the group of operations performed by the host, such that either all of the operations are performed or none of them are.
For example, a banking transaction may include a debit operation and a credit operation that must both be performed, or neither is performed. In such an example, a resource may be configured to perform the debit operation and the credit operation. The operations may be coordinated in an atomic fashion such that both of the debit and credit operations are successfully performed by the resource, or neither of the debit operation and credit operations are performed.
A line of business (LOB) system is a resource that may be computer-based, and is configured to service one or more particular business needs. For example, a LOB system may perform accounting, supply chain management, resource planning, database management and/or further enterprise-related functions. A system integrator may desire to use a LOB system to perform one or more operations of a transaction. Conventional LOB systems may support distributed transactions to varying degrees. For instance, some LOB systems can perform transactions of a distributed transaction that is coordinated by a distributed transaction coordinator. Some other LOB applications, however, do not support performing transactions of a distributed transaction. Such LOB applications may need to be customized to implement atomicity.
Thus, system integrators are faced with the task of attempting to integrate LOB systems that may or may not support distributed transactions. Even when some of the LOB systems do support such integration, the system integrator may elect not to use distributed transactions for various reasons, including desiring to avoid reduced performance. Instead, the system integrator may desire to use transactions that are atomic at individual resources. However, customization is currently required to implement atomicity at individual resources.
This Summary is provided to introduce a selection of concepts in a simplified form that are further described below in the Detailed Description. This Summary is not intended to identify key features or essential features of the claimed subject matter, nor is it intended to be used to limit the scope of the claimed subject matter.
A client is enabled to atomically perform multiple operations of a local transaction at a resource, such as a line of business (LOB) system. A client-side channel interface, a service-side channel interface, and a local transaction scope are provided to enable the operations to be performed atomically. The local transaction scope enables a local transaction to be configured at the client in a less complex and predictable manner. The client-side channel interface and the service-side channel interface implement a transaction protocol between the client and a web service, to bridge the client with the resource, such that operations of the local transaction may be provided to the resource to be performed atomically.
For example, in one implementation, a client-side method for performing a local transaction is provided. A local transaction scope that includes a plurality of transaction operations and a commit operation is invoked. A local transaction object is generated. The local transaction object includes an initial state and a transaction identifier. A request message is generated that includes a first transaction operation of the local transaction scope. An identification number is generated. The transaction identifier is initialized with the identification number. The transaction identifier is included in the request message. The request message is transmitted over a communication channel to a service-side web service to be provided to a line of business (LOB) system. A response message to the request message is received from the communication channel. The response message includes the transaction identifier. The initial state of the local transaction object is changed to an active state.
One or more additional request messages are transmitted over the communication channel to the web service to be provided to the LOB system, each including a corresponding next transaction operation of the local transaction scope and the transaction identifier. One or more additional response messages are received from over the communication channel corresponding to the additional request message(s).
A completion protocol message is generated that includes the transaction identifier and a commit instruction or an abort instruction. The completion protocol message is transmitted to the web service. A completion type response message to the completion protocol message is received from the service-side.
In another implementation, a service-side method for performing a local transaction is provided. A request message is received from a client over a communication channel. The request message includes a transaction identifier and a first transaction operation of a plurality of transaction operations of a local transaction scope. A service-side local transaction object that includes the transaction identifier is generated. A web service starts the transaction in a LOB system, and the first transaction operation is provided to the LOB system. A response indication to the first transaction operation is received from the LOB system. A state of the local transaction object is changed to an active state. A response message is transmitted to the client over the communication channel that includes the response indication and the transaction identifier.
One or more additional request messages may be received from the client, each including the transaction identifier and a corresponding next transaction operation of the local transaction scope to be provided to the LOB system. Each next transaction operation is provided to the LOB system. An additional response message corresponding to each next transaction operation is/are provided to the client.
A completion protocol message is received from the client that includes the transaction identifier and a commit instruction or an abort instruction. The local transaction object is completed in response to the completion protocol indication. The LOB system is instructed to perform the received commit instruction or abort instruction. A completion type indication is received from the LOB system. A completion type response message is transmitted in response to the completion protocol message to the client.
In another implementation, a client-side local transaction system is provided. The client-side local transaction system includes a local transaction scope and a client-side channel interface. The local transaction scope is configured to be invoked by a client. The local transaction scope includes a plurality of transaction operations and a commit operation. The local transaction scope causes a local transaction object to be generated. The local transaction object includes an initial state and a transaction identifier. The local transaction scope is configured to generate a request message that includes a first transaction operation of the local transaction scope. The client-side channel interface is configured to generate an identification number, to initialize the transaction identifier with the identification number, to include the transaction identifier in the request message, and to transmit the request message over a communication channel to a web service to be provided to a line of business (LOB) system. The client-side channel interface is further configured to receive a response message to the request message from the communication channel. The response message includes the transaction identifier. The client-side channel interface is further configured to change the initial state of the local transaction object to an active state.
The client-side channel interface may transmit one or more additional request messages over the communication channel to the web service to be provided to the LOB system. For each request message, the client-side channel interface may receive a corresponding response message from over the communication channel.
The client-side channel interface is further configured to generate a completion protocol message that includes the transaction identifier and a commit instruction or an abort instruction, and to transmit the completion protocol message to the web service. The client-side channel interface is further configured to receive a completion type response message to the completion protocol message from the service-side.
In still another implementation, a service-side local transaction system is provided. The service-side local transaction system includes a service-side channel interface and a LOB interface. The service-side channel interface is configured to receive a request message from a client. The request message includes a transaction identifier and a first transaction operation of plurality of transaction operations of a local transaction scope. The service-side channel interface is further configured to generate a service-side local transaction object that includes the transaction identifier after the first transaction operation is started in a LOB system. The LOB interface is configured to provide the first transaction operation to the LOB system, and to receive a response indication to the first transaction operation from the LOB system. The service-side channel interface is further configured to change a state of the local transaction object to an active state, and to transmit a response message to the client that includes the response indication and the transaction identifier.
The service-side channel interface is further configured to receive one or more additional request messages from the client. Each additional request message includes the transaction identifier and a corresponding next transaction operation of the local transaction scope to be provided to the LOB system. The LOB interface is configured to provide each next transaction operation to the LOB system. The service-side channel interface is configured to transmit an additional response message corresponding to each next transaction operation to the client.
The service-side channel interface is further configured to receive a completion protocol message from the client that includes the transaction identifier and a commit instruction or an abort instruction, and to complete the local transaction object in response to the completion protocol indication. The LOB interface is further configured to instruct the LOB system to perform the received commit instruction or abort instruction, and to receive a completion type indication from the LOB system. The service-side channel interface is further configured to transmit a completion type response message in response to the completion protocol message to the client.
Computer systems and computer program products (stored on a computer readable medium) are also described herein that are capable of performing and/or enabling the methods described above and elsewhere herein, including enabling local transactions to be performed at the client-side and at the service-side, and for implementing further embodiments as described herein.
Further features and advantages of the invention, as well as the structure and operation of various embodiments of the invention, are described in detail below with reference to the accompanying drawings. It is noted that the invention is not limited to the specific embodiments described herein. Such embodiments are presented herein for illustrative purposes only. Additional embodiments will be apparent to persons skilled in the relevant art(s) based on the teachings contained herein.
The accompanying drawings, which are incorporated herein and form a part of the specification, illustrate the present invention and, together with the description, further serve to explain the principles of the invention and to enable a person skilled in the pertinent art to make and use the invention.
The features and advantages of the present invention will become more apparent from the detailed description set forth below when taken in conjunction with the drawings, in which like reference characters identify corresponding elements throughout. In the drawings, like reference numbers generally indicate identical, functionally similar, and/or structurally similar elements. The drawing in which an element first appears is indicated by the leftmost digit(s) in the corresponding reference number.
The present specification discloses one or more embodiments that incorporate the features of the invention. The disclosed embodiment(s) merely exemplify the invention. The scope of the invention is not limited to the disclosed embodiment(s). The invention is defined by the claims appended hereto.
References in the specification to “one embodiment,” “an embodiment,” “an example embodiment,” etc., indicate that the embodiment described may include a particular feature, structure, or characteristic, but every embodiment may not necessarily include the particular feature, structure, or characteristic. Moreover, such phrases are not necessarily referring to the same embodiment. Further, when a particular feature, structure, or characteristic is described in connection with an embodiment, it is submitted that it is within the knowledge of one skilled in the art to effect such feature, structure, or characteristic in connection with other embodiments whether or not explicitly described.
Embodiments of the present invention relate to techniques for atomically performing transactions. Embodiments may be implemented in various environments, including in a web service environment. For example, in such an embodiment, a client may access a resource, such as a line of business (LOB) system, through a web service to perform operations of a transaction atomically. For instance,
Client 102 may be an application configured to perform one or more functions, including one or more operations that access one or more resources, such as LOB systems. Client 102 may be implemented in hardware, software, firmware, or any combination thereof. For example, client 102 may be implemented as computer program code configured to be executed in one or more processors. Alternatively, client 102 may be implemented as hardware logic/electrical circuitry. For instance, client 102 may be implemented in a computer system, such as a stationary or mobile computing device, including a desktop computer (e.g., a personal computer), a mobile computer (e.g., a personal digital assistant (PDA), a laptop computer, a notebook computer, a smart phone, etc.), or other type of computing device.
Web service 106 and LOB system 108 may be located in a same computer system or separate computer systems. Web service 106 is a web service configured to support interoperable machine-to-machine interaction over network 104, including providing access to LOB system 108 to clients, such as client 102. For example, in an embodiment, web service 106 may be implemented according to the Windows Communication Foundation (WCF) programming framework distributed by Microsoft Corporation of Redmond, Wash., as a WCF service layer. LOB system 108 may be one or more applications configured to perform one or more functions that are accessible by clients. For example, LOB system 108 may be configured to perform one or more of an accounting function, a banking and/or finance-related function, a supply chain management function, a resource planning function, a database management function, and/or any other suitable function. For instance, LOB system 108 may provide enterprise software and/or database functions, including an SQL (structured query language) database, an Oracle® database (distributed by Oracle Corporation of Redwood Shores, Calif.), a Siebel database (distributed by Oracle Corporation), etc.
Computer 102 is shown in
Although a single LOB system 108 is shown in
Client 102 and web service 106 may be configured to communicate with each other through network 104 in various ways. For instance,
Client-side channel interface 202 and service-side channel interface 204 are configured to enable communications between client 102 and web service 106, through a channel that includes network 104. Various types of communications between client 102 and web service 106 may be performed, including communication protocols such as SOAP (simple object access protocol) over HTTP (hypertext transfer protocol), SOAP over TCP (transmission control protocol), SOAP over Message Queues, and/or further communication protocols.
For example, in an embodiment, client-side channel interface 202 and service-side channel interface 204 may be configured according to a binding, such as a WCF service layer binding configured to specify how communications occur through a transaction channel established between client 102 and web service 106 (e.g., through network 104). Furthermore, client-side channel interface 202 is configured to propagate client-side state changes regarding a local transaction to the service-side through service-side channel interface 204.
Client 102 and web service 106 communicate with each other to enable LOB system 108 to perform operations of a transaction for client 102 in an atomic fashion. Because the operations of the transaction are to be performed by LOB system 108, the overall transaction may be referred to as a “local transaction.” The local transaction may include any number of one or more operations to be performed by LOB system 108 for client 102. Furthermore, the operations of the local transaction occur atomically, such that they are all performed, or if one or more of them cannot be performed, none of them are performed. Thus, in an embodiment, the local transaction may include an additional operation, referred to as a commit operation, which enables the other operations to all be performed or to all be aborted (e.g., if any one or more of the other operations cannot be performed). The local transaction may be implemented as a program module at client 102, referred to as a “local transaction scope,” such as in the form of C #, C++, Visual Basic, any programming language supported by the Microsoft® .NET Framework, other programming language, or in other form.
For instance, an example of a local transaction may include three operations to be performed at a database maintained by LOB system 108. The three operations may be an “insert” operation, an “update” operation, and a “delete” operation. An example of the local transaction is show below implemented as a C# class:
As shown above, the local transaction is implemented as a “LocalTransactionScope,” and includes the three operations (insert operation=LOBsystem1.Insert( ); update operation=LOBsystem1.Update( ); and delete operation=LOBsystem1.Delete( )) to be performed at LOB system 108 (“LOBsystem1”) and a commit operation (ts.Commit( )). The insert, update, and delete operations may be provided by client 102 to LOB system 108 through web service 106, and if all three are successfully performed, the commit operation provides a “commit” instruction to LOB system 108. If any of the three are not successfully performed, the LocalTransactionScope defined by “using” block provides an “abort” instruction to LOB system 108 to abort any successfully completed operation.
Embodiments provide many advantages with regard to enabling client 102 to atomically perform operations at LOB system 108. For instance, client-side channel interface 202, service-side channel interface 204, and a local transaction scope integrated in client 102 provide a generic interface and protocol for interfacing with LOB system 108 through web service 106. As such, system integrators can utilize the generic interface and protocol, and thus do not have to expend additional effort on developing a custom interface and communication protocol. The local transaction scope enables an explicit and implicit model for configuring local transactions at client 102. Client-side channel interface 202 and service-side channel interface 204 implement a transaction protocol between client 102 and web service 106, to bridge client 102 with LOB system 108, and enable access to LOB transactions.
A local transaction may be performed in system 200 in various ways. For example,
As shown in
In step 504, a request message is transmitted from a client-side channel interface to a service-side channel interface. For instance, as shown in
In step 506, a web service receives the request message. For example, as shown in
In step 508, a new service-side local transaction object is generated if the request message is a first request message. For instance, referring to
In step 510, the web service provides the operation to a LOB system to be performed. For example, as shown in
In step 512, the LOB system provides to the web service an indication of whether the operation was performed successfully. For example, as shown in
In step 514, the web service generates a response message to the request message that includes the indication. For example, as shown in
In step 516, the response message is transmitted from the service-side channel interface to the client-side channel interface. For example, as shown in
In step 518, the indication received in the response message is provided to the client. For example, as shown in
As such, flowchart 500 describes an example local transaction protocol that bridges client 102 with LOB system 108, enabling client 102 to perform LOB transactions. Note that flowchart 500 may be repeated for each operation of the local transaction, including the commit operation being processed during a final iteration of flowchart 500. In an embodiment, if each of the indications received by client 102 indicates that the respective operation was successfully performed at LOB system 108, client 102 may generate a completion protocol message transmitted to LOB system 108 that includes a commit instruction. The commit instruction instructs LOB system 108 to commit (e.g., finish performing and/or allow to remain completed) each of the previously transmitted operations of the local transaction. If one or more of the indications received by client 102 indicate that an operation was not successfully performed at LOB system 108, client 102 may generate the completion protocol message to include an abort instruction. The abort instruction instructs LOB system 108 to abort (e.g., cancel and/or undo) each of the previously transmitted operations of the local transaction. Accordingly, LOB system 108 generates a completion type response message that is transmitted to client 102. The completion type response message either indicates that the received abort instruction or commit instruction was performed successfully, or may provide an “in doubt” indication if LOB system 108 is unable to ascertain whether the abort instruction or commit instruction was performed successfully.
System 200 and flowchart 500 may be implemented in various ways. Example of such embodiments for system 200 and flowchart 500 are described as follows. For instance,
Client-side channel interface 202 is configured as a channel interface for client computer system 710, and service-side channel interface 204 is configured as a transaction channel interface for server computer system 712. Local transaction scope 702 includes a plurality of transaction operations and a commit operation for a local transaction to be performed by client 102. Operation invoker 706 is configured to provide transaction operations received over the transaction channel to LOB interface 708. LOB interface 708 is an interface (e.g., an “adaptor”) for communicating with LOB system 108. LOB interface 708 may be a generic interface or may be an interface configured specifically for a particular LOB system 108.
System 700 is further described with respect to
Example embodiments are described in this subsection for performing transaction operations of a local transaction. The example embodiments described herein are provided for illustrative purposes, and are not limiting. Furthermore, additional structural and operational embodiments, including modifications/alterations, will become apparent to persons skilled in the relevant art(s) from the teachings herein.
For example,
As shown in
As shown in
In step 904, a request message is generated that includes a first transaction operation of the local transaction scope. Referring to
As shown in
In step 1204, the transaction identifier is initialized with the identification number. In an embodiment, client-side channel interface 202 may be configured to initialize transaction identifier 1104 (
In step 1206, the transaction identifier is included in the request message. Referring to
For example, in an embodiment, client-side channel interface 202 may be configured to include transaction identifier 1104 in a portion of request message 804, such as a header portion. For instance, as shown in
Message header generator 1306 may generate the message header to have any form. Furthermore, the message header may be generated in any format (e.g., any format that is supported by SOAP (simple object access protocol)), including a programming language such as XML (extensible markup language), JSON (JavaScript object notation), etc. For instance, an example message header is shown as follows in XML programming language form:
Message header generator 1306 may be configured to generate this example message header, inserting the value of transaction identifier 1104 at the location of “GUID”, and setting “xmlns” to a constant value (e.g., a URI value in the current example). In an embodiment, each message header that is transmitted to the service-side has an xmlns value assigned, or the service-side will refuse to treat the message as valid local transaction message. This is analogous to the situation where a first person visits an office and asks a receptionist to see a second person, who is an employee at the office. The receptionist will typically perform appropriate actions to direct you to the second person. If there the second person is not an employee, the receptionist may let the first person know, and the first person returns empty handed. Similarly, the request message header includes a value for xmlns that is expected by web service 106. If the xmlns value does not match an expected value, the request message that includes the message header will not be processed by the service-side. “xmlns” is referred to as namespace. Each entity in an XML document is defined under a particular namespace. For more details regarding namespaces, refer to “Namespaces in XML 1.0 (Second Edition), W3C Recommendation 16 Aug. 2006”, XML Core Working Group, Aug. 16, 2006, which may be accessible at http://www.w3.org/TR/REC-xml-names/, and which is incorporated by reference herein in its entity.
In an embodiment, as shown in
In step 1208, the request message is transmitted over a communication channel to a web service to be provided to a line of business (LOB) system. Referring to
Server computer system 712 receives and processes request message 808. For instance,
As shown in
In step 1504, whether a service-side local transaction object corresponding to the first transaction object has been generated is determined. For example, in an embodiment, when request message 808 is a first received request message of a local transaction, service-side channel interface 202 may be configured to determine whether a service-side local transaction object corresponding to the local transaction has been generated. As described below, the service-side local transaction object is generated to enable tracking of the local transaction on the service-side. If a service-side local transaction object corresponding to the local transaction is determined to not have been generated, operation proceeds to step 1506. If a service-side local transaction object corresponding to the local transaction is determined to already have been generated, operation proceeds to step 1508.
In step 1506, a service-side local transaction object is generated that includes the transaction identifier. For example, in an embodiment, when request message 808 is a first received request message of a local transaction, service-side channel interface 202 may be configured to generate a service-side local transaction object that includes transaction identifier 1104 from request message 808. The generated service-side local transaction object is configured to track on the service-side a state of the local transaction associated with transaction identifier 1104.
For example, as shown in
In step 1508, the first transaction operation is provided to a line of business system. For example, as shown in
In step 1510, a response indication to the first transaction operation is received from the LOB system. For example, as shown in
In step 1512, a state of the local transaction object is changed to an active state. For example, in an embodiment, LT object state manager 1608 (
In step 1514, the response message that includes the response indication and the transaction identifier is transmitted to the client over the communication channel. In an embodiment, as shown in
Referring back to flowchart 1200 shown in
In step 1212, the initial state of the local transaction object is changed to an active state. For example, in an embodiment, LT object state manager 1308 may be configured to change state 1102 of client-side local transaction object 704 from the initial state to an active state upon receiving a first response message from service-side channel interface 204 regarding the local transaction associated with client-side local transaction object 704 (e.g., identified by transaction identifier 1104).
As described above, local transaction scope 702 may include one or more additional transaction operations 1002b-1002n in addition to the first transaction operation 1002a. Portions of flowcharts 900, 1200, and 1500 may be performed for each additional transaction operation. For example, in step 904 (flowchart 900 in
For example,
As shown in
In step 1804, an abort instruction is transmitted to the LOB system. In an embodiment, in response to the failure indication received from LOB interface 708, operation invoker 706 may transmit an abort instruction to LOB interface 708 to abort the present local transaction because if one transaction operation fails, the local transaction cannot be performed atomically, and thus all transaction operations of the local transaction are to be aborted. As a result, LOB interface 708 may terminate the current instance of the local transaction, and may transmit one or more instructions to LOB system 108 to abort transaction operations associated with the local transaction.
In step 1806, an abort indication is included in the response message corresponding to the failed transaction operation. For example, referring to
Example embodiments are described in this subsection for completing a local transaction. For purposes of illustration, embodiments in this section are described with respect to
For example,
As shown in
As shown in
Completion message generator 1312 may generate completion protocol message 1906 to have any form. Furthermore, completion protocol message 1906 may be generated in any format, including a programming language such as XML (extensible markup language), JSON (JavaScript object notation), etc. For instance, an example of completion protocol message 1906 is shown as follows in XML programming language form:
Completion message generator 1312 may be configured to generate this example of completion protocol message 1906, inserting the value of transaction identifier 1104 at the location of “GUID”, and setting “xmlns” to a constant value, as described above. Furthermore, either “Commit” (a commit instruction) or “Abort” (an abort instruction) may be selected at the location of “Commit/Abort”, depending on whether completion indication 1902 indicates a success (for all transaction operations) or a failure (for at least one transaction operation).
In step 2004, the completion protocol message is transmitted to the web service. Referring to
As shown in
In step 2104, the local transaction object is completed in response to the completion protocol indication. For example, in an embodiment, service side channel interface 204 (e.g., LT object state manager 1608) may be configured to complete service-side local transaction object 1702 after receiving completion protocol message 1906.
In step 2106, the LOB system is instructed to perform the received commit instruction or abort instruction. For example, as shown in
In step 2108, a completion type indication is received from the LOB system. In an embodiment, LOB system 108 generates a completion type indication 1914 that indicates whether completion instruction 1912 was performed successfully. For example, if completion instruction 1910 was a commit instruction that was performed successfully, completion type indication 1914 may indicate “commit” or other indication of success of the commit instruction. If completion instruction 1910 was an abort instruction that was performed successfully, completion type indication 1914 may indicate “abort” or other indication of success of the abort instruction. If LOB system 108 is unable to determine whether the commit instruction or abort instruction of completion instruction 1910 was performed successfully, completion type indication 1914 may indicate “in doubt” or other indication that success of instruction was not verified.
In step 2110, the completion type response message is transmitted to the client in response to the completion protocol message. For example, as shown in
In an embodiment, messaging module 1602 (
Messaging module 1602 may be configured to generate this example of completion type response message 1920, inserting the value of transaction identifier 1104 at the location of “GUID”, and setting xmlns to a constant value, as described above. Furthermore, either “Commit” (an indication of a successful commit), “Abort” (an indication of a successful abort), or “InDoubt” (an indication that a successful commit or abort was not verified) may be selected at the location of “Commit/Abort/InDoubt”, depending on completion type indication 1918.
Referring to
Referring back to flowchart 2000 in
In an embodiment, systems 100 (
For example, a local transaction scope is shown as follows that references multiple LOB systems (implemented as a C# class):
As shown above, the local transaction scope references two LOB systems, a “LOBsystem1” and a “LOBsystem2.” Three operations (insert, update, and delete) are designated in the local transaction scope to be performed by each of LOBsystem1 and LOBsystem2, for a total of six operations. Furthermore, a commit operation (ts.Commit( )) is present to be executed if the six operations are successfully performed. The insert, update, and delete operations may be provided by client 102 to a pair of LOB systems 108 through web service 106.
As described above, in one embodiment, this local transaction scope, which references multiple LOB systems, may result in a failure if invoked. For example, when the operation LOBsystem2.Insert( ) is executed, this operation would throw an exception, and the local transaction scope would be aborted. Such a scenario will not be allowed because transactions dealing with multiple LOB systems may be better handled in a distributed transaction that is coordinated by a distributed transaction manager.
For instance, in an embodiment, if this local transaction scope is executed, steps 902 and 904 of flowchart 900 (
However, with regard to the LOBsystem2.Insert( ), this operation is included in a request message (in step 904), which is a first message directed to LOBsystem2 over a second transaction channel. Because this operation is directed to a second LOB system, client-side channel interface 202 may attempt to re-perform step 1204 to re-initial transaction identifier 1104 for client-side local transaction object 704. Because transaction identifier 1104 is already initialized, however, this second re-initialize attempt would fail, causing the local transaction scope to be aborted.
Client-side channel interface 202, service-side channel interface 204, client-side local transaction binding element 302, service-side local transaction binding element 402, local transaction scope 702, client-side local transaction object 704, operation invoker 706, LOB interface 708, local transaction object generator 1006, message generator 1008, GUID generator 1302, transaction identifier initialize 1304, message header generator 1306, LT object state manager 1308, messaging module 1310, completion message generator 1312, messaging module 1602, LT object generator 1604, transaction identifier initialize 1606, LT object state manager 1608, and service-side local transaction object 1702 may be implemented in hardware, software, firmware, or any combination thereof.
For example, client-side channel interface 202, service-side channel interface 204, client-side local transaction binding element 302, service-side local transaction binding element 402, local transaction scope 702, client-side local transaction object 704, operation invoker 706, LOB interface 708, local transaction object generator 1006, message generator 1008, GUID generator 1302, transaction identifier initialize 1304, message header generator 1306, LT object state manager 1308, messaging module 1310, completion message generator 1312, messaging module 1602, LT object generator 1604, transaction identifier initialize 1606, LT object state manager 1608, and/or service-side local transaction object 1702 may be implemented as computer program code configured to be executed in one or more processors. Alternatively, client-side channel interface 202, service-side channel interface 204, client-side local transaction binding element 302, service-side local transaction binding element 402, local transaction scope 702, client-side local transaction object 704, operation invoker 706, LOB interface 708, local transaction object generator 1006, message generator 1008, GUID generator 1302, transaction identifier initialize 1304, message header generator 1306, LT object state manager 1308, messaging module 1310, completion message generator 1312, messaging module 1602, LT object generator 1604, transaction identifier initialize 1606, LT object state manager 1608, and/or service-side local transaction object 1702 may be implemented as hardware logic/electrical circuitry.
For instance, in an embodiment, GUID generator 1302, transaction identifier initialize 1304, message header generator 1306, LT object state manager 1308, messaging module 1310, and completion message generator 1312 may be implemented in client-side local transaction binding element 302. Furthermore, in an embodiment, messaging module 1602, LT object generator 1604, transaction identifier initialize 1606, and LT object state manager 1608 may be implemented in service-side local transaction binding element 402.
As shown in
Computer 2200 also has one or more of the following drives: a hard disk drive 2214 for reading from and writing to a hard disk, a magnetic disk drive 2216 for reading from or writing to a removable magnetic disk 2218, and an optical disk drive 2220 for reading from or writing to a removable optical disk 2222 such as a CD ROM, DVD ROM, or other optical media. Hard disk drive 2214, magnetic disk drive 2216, and optical disk drive 2220 are connected to bus 2206 by a hard disk drive interface 2224, a magnetic disk drive interface 2226, and an optical drive interface 2228, respectively. The drives and their associated computer-readable media provide nonvolatile storage of computer-readable instructions, data structures, program modules and other data for the computer. Although a hard disk, a removable magnetic disk and a removable optical disk are described, other types of computer-readable media can be used to store data, such as flash memory cards, digital video disks, random access memories (RAMs), read only memories (ROM), and the like.
A number of program modules may be stored on the hard disk, magnetic disk, optical disk, ROM, or RAM. These programs include an operating system 2230, one or more application programs 2232, other program modules 2234, and program data 2236. Application programs 2232 or program modules 2234 may include, for example, computer program logic for implementing client-side channel interface 202, service-side channel interface 204, client-side local transaction binding element 302, service-side local transaction binding element 402, local transaction scope 702, client-side local transaction object 704, operation invoker 706, LOB interface 708, local transaction object generator 1006, message generator 1008, GUID generator 1302, transaction identifier initialize 1304, message header generator 1306, LT object state manager 1308, messaging module 1310, completion message generator 1312, messaging module 1602, LT object generator 1604, transaction identifier initialize 1606, LT object state manager 1608, service-side local transaction object 1702, flowchart 500, flowchart 900, flowchart 1200, flowchart 1400, flowchart 1500, flowchart 1800, flowchart 2000, and/or flowchart 2100 (including any step of flowcharts 500, 900, 1200, 1400, 1500, 1800, 2000, and/or 2100), and/or any further embodiments as described above.
A user may enter commands and information into the computer 2200 through input devices such as keyboard 2238 and pointing device 2240. 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 2202 through a serial port interface 2242 that is coupled to bus 2206, but may be connected by other interfaces, such as a parallel port, game port, or a universal serial bus (USB).
A monitor 2244 or other type of display device is also connected to bus 2206 via an interface, such as a video adapter 2246. In addition to the monitor, computer 2200 may include other peripheral output devices (not shown) such as speakers and printers.
Computer 2200 is connected to a network 2248 (e.g., the Internet) through a network adaptor or interface 2250, a modem 2252, or other means for establishing communications over the network. Modem 2252, which may be internal or external, is connected to bus 2206 via serial port interface 2242.
As used herein, the terms “computer program medium” and “computer-readable medium” are used to generally refer to media such as the hard disk associated with hard disk drive 2214, removable magnetic disk 2218, removable optical disk 2222, as well as other media such as flash memory cards, digital video disks, random access memories (RAMs), read only memories (ROM), and the like.
As noted above, computer programs and modules (including application programs 2232 and other program modules 2234) may be stored on the hard disk, magnetic disk, optical disk, ROM, or RAM. Such computer programs may also be received via network interface 2250 or serial port interface 2242. Such computer programs, when executed or loaded by an application, enable computer 2200 to implement features of embodiments of the present invention discussed herein. Accordingly, such computer programs represent controllers of the computer 2200.
The invention is also directed to computer program products comprising software stored on any computer useable medium. Such software, when executed in one or more data processing devices, causes a data processing device(s) to operate as described herein. Embodiments of the present invention employ any computer-useable or computer-readable medium, known now or in the future. Examples of computer-readable mediums include, but are not limited to storage devices such as RAM, hard drives, floppy disks, CD ROMs, DVD ROMs, zip disks, tapes, magnetic storage devices, optical storage devices, MEMs, nanotechnology-based storage devices, and the like.
While various embodiments of the present invention have been described above, it should be understood that they have been presented by way of example only, and not limitation. It will be understood by those skilled in the relevant art(s) that various changes in form and details may be made therein without departing from the spirit and scope of the invention as defined in the appended claims. Accordingly, the breadth and scope of the present invention should not be limited by any of the above-described exemplary embodiments, but should be defined only in accordance with the following claims and their equivalents.
