Method for deployment modification of transactional behavior in corba OTS6944643Abstract The present invention extends the programming model of OTS by providing a unique model that offers both flexibility and ease of use. This model separates the transactional behavior of CORBA method from the IDL interface. The transactional behavior of the CORBA method is specified in a deployment descriptor file. Each method is associated with a transactional policy. The server reads the policies of the methods during deployment time and makes decisions of making the method transactional based on the policy. Changing the transactional policy of a method is as easy as modifying the deployment descriptor and redeploying the server. If either of the two usage models that OTS offers is used, making a method transactional means that the IDL interface has to change, causing all the software components in the system to re-compile. With the present invention, such a change can be accomplished without need for such recompilation. Claims 1. A method for setting transactional behavior for a CORBA method, the method comprising: Description CROSS-REFERENCE TO RELATED APPLICATIONS
Users can design their system without even considering transactions initially. By comparison, if using straight OTS, the IDL is one of the following two:
The advantage of using ENCORE's programming model is that the transaction characteristics are completely separated from the IDL interface. The first IDL interface can then be implemented in either Java or C++. When deploying the server, a deployment descriptor needs to be supplied. The following is the deployment descriptor file for the above example: TxPolicy=Account:{update=TxRequired} Another advantage of ENCORE is that its programming model is not restricted by any programming language or environment. This model is maintained consistently in C++ and Java language implementations of ENCORE. Not only can a client written in Java or C++ talk to servers written in C++ or Java in a transactional manner, EJB session beans running ENCORE client side library can act as a client to a C++ server with ENCORE server side library outside the EJB environment. FIG. 1 provides a diagram of the principal components of a distributed transaction accomplished in a CORBA-compliant manner. In the context of this disclosure, CORBA-compliant means compliant and compatible with the relevant specifications for CORBA in general and for CORBA OTS specifically. While the most preferred embodiment is compliant with CORBA 2.1 and OTS97, an embodiment compliant with CORBA 2.1 and CORBA OTS97 is defined as being CORBA-compliant with later embodiments of CORBA and CORBA OTS. In FIG. 1, the client object 10 (also referred to as client application or more simply as client) acts as the transaction originator. To originate the transaction, client 10 sends a command to the Object Transaction Service 20 (also, referred to as OTS) to begin the transaction. At the same time, client 10 sends a CORBA call in the form of an IIOP message to both server object 30 and server object 40 (also referred to as server applications or more simply as servers). Server objects 30 & 40 are both transaction participants. The illustration provides two transaction participants to demonstrate the advantage of using a transaction service, where a request may require changes in multiple databases and where if one database is not able to make a change, any other changes may be rolled back to their original state. The server objects 30 & 40 each communicate with supporting databases 50 & 60 respectively, most preferably Oracle databases, but also potentially other relational databases. Each server object communicates CRUD commands (create, read, update, & delete) using SQL language. At the same time, the OTS 20 communicates with each database 50 & 60 to begin a transaction using XA commands compliant with the X/Open standard for two-phase commit protocols. There are potentially, but not necessarily, machine boundaries between any or all of the objects 10, 30, 40, 50, & 60 and OTS 20. After all of the CORBA calls return successfully, client 10 informs OTS 20 to commit the transaction and OTS 20 similarly informs the databases 50 & 60 to commit the transaction. At this point the transaction is complete and OTS 20 steps out of the picture. However, if one of the calls to server objects fail, for example because the database was unavailable, client 10 informs OTS 20 to rollback the transaction and OTS 20 informs any of databases 50 & 60 which have made a change to implement the transaction to rollback the change and return to their original state before the transaction began. In FIG. 2, a more detailed diagram illustrating the connections between client, server, database and OTS is provided. Client 10 provides commands to begin, commit, or rollback to OTS 20. Server Object 30 registers with OTS 20. Client 10 sends its CORBA call by IIOP message including the transaction context to server object 30. OTS 20 sends a start command and later a prepare and commit command or a rollback command to database 50 preferably using the X/Open standard. Server object 30 sends an SQL command to database 50 including a transaction id (or XID). Database 50 will respond to the server object 30's SQL request which is returned to client 10 which informs OTS 20 to commit or rollback the request depending on the response. OTS 20 informs database 50 to commit or rollback and the transaction is completed. In the present invention, this model is accomplished by the use of CORBA interceptors. Whenever the client invokes a CORBA method on the server side, the client side interceptor intercepts the call and puts the "control" object (defined by OTS to represent the transaction context) encapsulated within a "session" object on the service context of the IIOP message. When the server receives the invocation, the interceptor first intercepts it, extracts the "session" object from the service context of the IIOP message, checks the policy, and make the appropriate calls to the OTS. Note that the session object encapsulates the control object and is sometimes referred to in this disclosure as the control object where the control object is the focus of the discussion. Since this programming model is accomplished by using interceptors to propagate the transaction context information without the user's intervention, therefore, the propagation is implicit. Because the transaction context is completely managed by ENCORE's server side library, from the user's perspective the context management is indirect. While implicit and indirect context management are recognized and defined by the OTS specification, the indirect propagation of transaction context through the use of interceptors placing transaction context in a session object on the service context of the IIOP message is not known to the inventors outside of their present invention. FIG. 3 diagrams a preferred embodiment of the events on client side when "initialize" is called. Client 110 calls initialize which is passed to its ENCORE framework 120. ENCORE framework 120 propogates the initialize to both ORB 130 and OTS 140. Interceptor 210 also registers with ORB 130 at initialization. FIG. 4 diagrams a preferred embodiment of the events on client side when "beginTx" is called. Client 110 calls beginTx to ENCORE framework 120 which constructs a session object 220 incorporating a control object 230. Encore framework 120 also initiates a begin command with OTS 140. FIG. 5 diagrams the events which occur when a client call is made from the client side. When the client object 110 invokes a CORBA method on the server side (in this instance Account->Balance), the invocation is passed through ENCORE framework 120 to ORB 150. After the call is initially delivered to ORB 150, the client side interceptor 210 intercepts the call and puts the session object 220 (the object representing the transaction context and incorporating the control object) on the service context of the IIOP message heading to the server and then returns the IIOP message to ORB 150 for delivery. FIG. 6 diagrams the server side events. When the server side receives the invocation through the ORB 150, the server side interceptor 240 first intercepts the invocation, extracts the session object 220 and checks the transaction policy for the server. The transaction policy is read from the deployment descriptor when the server 160 is deployed. If the policy is not transactional, the interceptor 240 bypasses the OTS calls and invokes the user's implementation directly on the server object 160. But if the policy requires transaction, the interceptor code completes the control object interpositioning process, an OTS defined process between the session object 220 and the OTS 140 and then invokes the called method on the server object 160. Both the client object 110 and the server object 160 work in cooperation with separate ENCORE Frameworks 120 and 170 respectively to accomplish the defined process. While the discussion here refers to client side and server side, one skilled in the art will recognize that a given system may function as both a client and a server at various times. When the specification refers to the client side, it is referring to the system or environment on which the client object is resident. Where the specification refers to a system remote from the client object it does not require a separate network or even a separate computer (as objects functioning in a client/server relationship may share a computer) but instead refers to a separate environment where communications between the client side and the server side (i.e., the local and remote system) are exchanged through the CORBA ORB rather than though another local channel. The client object is the object making the request which may or may not require transactional support. The CORBA method being called or invoked is contained within an object. For shorthand, the term CORBA method is defined to include the object which contains the CORBA method. Hence where the statement is made that the CORBA method resides on a system, it is understood that the object containing the CORBA method resides on the system. In the above described example, the server object contains the invoked CORBA method. The User's View ENCORE's Programming interface provides the following interfaces to the client side and the server side:
This interface is very simple, the transaction propagation and management is completely hidden to the user. The deployment descriptor file preferably specifies the policies of all the methods resident on the server, but could specify transaction policies for a set of methods or even for an individual method. It is preferably read when the server process first starts up. The file format is preferably basically name and value pairs separated by "=" sign, but other separators or approaches to provide the information could also be used. The file format typically takes the form of a text file, but other formats understood by those of skill in the art could also be employed. At its heart, the deployment descriptor file is a stored file which lists transaction policies for specific methods. When the deployment descriptor file is "read", the act of creation of the transaction policy actually transforms the data in the text file into a different form, typically but not necessarily tabular, which is preferably stored in a cache on the server. The act of checking the provided method name against the transaction policy comprises comparing the name to the names in the transaction policy and determining the specific policy associated with the name. In its most preferred form, this involves comparing the name against the transaction policy in the cache. However, in an alternative form, checking may involve reading the deployment descriptor file after receiving the method invocation to compare the invoked method name with the contents of the deployment descriptor file more contemporaneously (run-time instead of deployment time). Even this act involves pulling the stored information from the deployment descriptor file into memory (either as a whole or in pieces) and comparing, and such an act is included within the definition of creating a transaction policy. It is just an alternative, more ephemeral, transaction policy created in response to each request, rather than only at the time of deployment. The user must supply the deployment descriptor file in order to deploy the server. While the deployment descriptor file is preferably stored on the system where the server object is resident, (i.e. on the server side), it may alternatively be stored elsewhere so long as the server has access to the file either during deployment or during run-time or both. By having the deployment descriptor file remote from the server, the same deployment descriptor file could be used to define the transaction policies for more than one server. In this manner, a group of servers typically deployed together and similarly situated may have their transaction policies modified by changing a single deployment descriptor file rather than having to change a deployment descriptor file for each server separately. The Session Object (Incorporating and Sometimes Referred to as the CONTROL OBJECT) In the preferred embodiment, the client side ENCORE container creates a session when a transaction is initiated on the client side. The session is identified by a unique id. The resulting session object comprises a string composed of the machine's IP address, the process id, the thread id, and the current time in mili-second. A session represents a transaction. All the information pertaining to a session is propagated to the server side on every method invocation, so that the server knows which transaction that particular call belongs to The session has a time-out parameter, which specifies how long it is allowed to exist before it gets cleaned up by the garbage collection mechanism of the ENCORE container. The session id gets logged in the server side log file on every call. Computer Systems The method as described above may generally be implemented on a variety of different computer systems. FIG. 7 illustrates a typical, general-purpose computer system suitable for implementing the present invention. The computer system 330 includes a processor 332 (also referred to as a central processing units, or CPU) that is coupled to memory devices including primary storage devices 336 (typically a read only memory, or ROM) and primary storage devices 334 (typically a random access memory, or RAM). As is well known in the art, ROM acts to transfer data and instructions uni-directionally to CPU 332, while RAM is used typically to transfer data and instructions in a bi-directional manner. Both storage devices 334 & 336 may include any suitable computer-readable media. A secondary storage medium 338, which is typically a mass memory device, is also coupled bi-directionally to CPU 332 and provides additional data storage capacity. The mass memory device 338 is a computer-readable medium that may be used to store programs including computer code, data, and the like. Typically, mass memory device 338 is a storage medium such as a non-volatile memory such as a hard disk or a tape which are generally slower than primary storage devices 334, 336. Mass memory storage device 338 may take the form of a magnetic or paper tape reader or some other well-known device. It will be appreciated that the information retained within the mass memory device 338, may, in appropriate cases, be incorporated in standard fashion as part of RAM 334 as virtual memory. A specific primary storage device 334 such as a CD-ROM may also pass data uni-directionally to the CPU 332. CPU 332 are also coupled to one or more input/output devices 340 that may include, but are not limited to, devices such as video monitors, track balls, mice, keyboards, microphones, touch-sensitive displays, transducer card readers, magnetic or paper tape readers, tablets, styluses, voice or handwriting recognizers, or other well-known input devices such as, of course, other computers. Finally, CPU 332 optionally may be coupled to a computer or telecommunications network, e.g., an internet network, or an intranet network, using a network connection as shown generally at 312. With such a network connection, it is contemplated that CPU 332 might receive information from the network, or might output information to the network in the course of performing the above-described method steps. Such information, which is often represented as a sequence of instructions to be executed using CPU 332, may be received from and outputted to the network, for example, in the form of a computer data signal embodied in a carrier wave. The above-described devices and materials will be familiar to those of skill in the computer hardware and software arts. In one embodiment, sequences of instructions may be executed substantially simultaneously on multiple CPUs, as for example a CPU in communication across network connections. Specifically, the above-described method steps may be performed across a computer network. Although only a few embodiments of the present invention have been described, it should be understood that the present invention may be embodied in many other specific forms without departing from the spirit or the scope of the present invention. By way of example, while databases which communicate using SQL and X/Open commands are described, databases which communicate and support transactions using alternative defined protocols could equally be used without departing from the spirit of the present invention. Therefore, the present examples are to be considered as illustrative and not restrictive, and the invention is not to be limited to the details given herein, but may be modified within the scope of the appended claims along with their full scope of equivalents.
|
Same subclass Same class Consider this |
||||||||||||||||||||||||||