Apparatus, methods, and computer program products for transactional support of network management operations6785722Abstract An application transaction (AT) server collects multiple user specified application operations for processing as a single application transaction and records essential information about each transaction being performed in a database. Such recordation enables the values of objects targeted by the particular application transaction prior to completion of a transaction to be restored in case of failed operation of the application transaction. Claims What is claimed is: Description COPYRIGHTS IN PATENT MATERIALS
// Begin Application Transaction
. . .
// Set Object A, attribute a1
. . .
// Set Object C, attribute c1
. . .
// Commit Application Transaction
Thus, according to the present invention, a plurality of requests are built (i.e., combined) and sent as a single application transaction which is atomic. By atomic, it is meant that when the transaction either commits or fails, all of its operations which have been combined into the single atomic transaction commit or fail in unison. The transaction is bound to all operational objects whether individually specified or indirectly scoped. FIG. 1B is a block diagram of a computer system for implementing an embodiment of the present invention in which each server and application is implemented jointly or separately on one or more computer systems. Computer system 160 particularly includes a random access memory (RAM) 170; a read only memory (ROM) 171; a memory bus 172 connected to RAM 170 and ROM 171; a microprocessor 173 connected to the memory bus 172; a monitor 176; a printer 177; a disk drive 178; a compact disk read only memory (CD ROM) drive 179; a peripheral bus 180 connected to monitor 176, printer 177, disk drive 178, and CD ROM drive 179; a hard drive 181; and a network interface, each connected to peripheral bus 180 as shown in FIG. 1B. Disk drive 178 and CD ROM drive 179 are respectively able to read information including computer program products (not shown) which can be embedded on media such as, respectively, a magnetic or optical disk or floppy 178' and a CD ROM medium 179'. Depending upon the selected drive and medium, writing on the selected medium as well as reading can be accomplished. FIG. 2 is a block diagram of a network management platform (NMP) according to the present invention. In particular, FIG. 2 shows a NMP 102 including a processing entity 103 as defined above for performing one or more application transactions. The processing entity 103 in turn includes an application transaction manager 110 (ATM) according to the present invention. The ATM 110 according to the present invention is linked to an undo log as will be seen which is described below in connection with FIG. 5. The undo log is stored for example in a selected database (DB), e.g., DB 105. The data in the undo log permits the parts of an incomplete or failed application transaction to be undone. For example, a failed AT which has been processed is undone by rolling back to the original values of transaction affected target objects, e.g., 104-114, for example. The ATM 110 controls the loading of the undo log and its disbursement in roll-back operation of data to restore the preceding target object values. NMP 102 is a server or computer tasked with network management tasks and functions according to a predetermined network arrangement. FIG. 3A is a diagram of an application transaction manager (ATM) 110 according to the present invention. In particular, FIG. 3A shows the ATM 110 linking or threading a series of first through third operations, respectively 121 through 123, which have been linked together as a composite application transaction to operate upon one or more target objects represented collectively by target object 104. Target object 104 can be resident or invoked on the same competing platform (i.e. computer system) as the ATM 110 or on a separate platform or system, as configured or selected by the user or a surrogate for example. FIG. 3B is a diagram showing how the ATM 110 provides transactional semantics around the target objects (TOA, TOB, TOI) that live in different agents such as agents X and Y, respectively 150 and 151. The target objects TOA and TOB live in Agent X; TOI lives in Agent Y, irrespective of whether the agents 150, 151 themselves support particular transactions. Network management transaction operations are referred to herein as "Application Transactions" or "AT", as they invoke one or more network management applications such as the application and operations 100 referred to in FIG. 3B. An application transaction performing entity 103 in a service provider or agent 150, 151 handles the processing of AT transactions. This entity 103 includes the "Application Transactions Manager" or "AT Manager" 110 and is implemented as an independent computing process to provide AT transaction services to the management entities which need it. However, the general applicability of this invention is not limited to only the above practice. According to one embodiment of the present invention, the user builds a "begin AT" message to AT performing entity 103 and sends this message to AT performing entity 103 and to the service provider or agents X and Y. Upon receiving this message, the service provider communicates the request to the AT Manager 110 to create a binding to link all subsequent management operations together. This activity happens according to one embodiment of the present invention without any user knowledge. The user then continues to build and send all other management operations to the service provider which then directs them to the AT Manager 110 entity 103. This process continues until the AT Manager 110 receives a "commit AT" message or an "abort AT" message. In the event that a "commit AT" is received, the service provider works in conjunction with the AT Manager 110 to cause a synchronous commit of all operations included in this transaction. If an "abort AT" message is received, the binding AT and the member operations will be aborted or rolled back completely in a way similar to an "Undo" of the operations that have been carried out prior to the abort request. All operations are either committed altogether as a single transaction or aborted altogether if an operation fails or if the above directive is received. FIG. 4 is a flowchart of a method according to the present invention in which a user implements a selected application transaction. In particular, FIG. 4 shows a user building 400 a begin application transaction message. Next, the request to begin an application transaction is sent 401 to a network management platform (NMP). Thereafter, the network management platform receives 402 the message and begins a binding process to link all subsequent operations together until the NMP receives a commit application transaction message or a rollback application transaction message. Then, if a commit application transaction message is received, the NMP locates 406 an application transaction performing entity and passes all operations to it with a commit application transaction message to cause synchronous commit of all threaded operations. Alternatively, if a rollback application transaction message is received, the binding or threading of operations and transactions is aborted. FIG. 5 is a flowchart of a method according to the present invention in which an application transaction manager (ATM) receives request messages from an application. In particular, FIG. 5 shows an application transaction manager receiving 500 request messages from an application through a routing mechanism in an application transaction helper device between an application transaction server and a network management platform with respect to particular operations needing to be performed. The application transaction manager (ATM) according to the present invention creates 501 derived messages from the request messages. The application transaction manager (ATM) further receives 502 responses from the network management platform (NMP) and links the responses for storage in a persistent undo log, as a snapshot of an affected object(s) which is(are) thereupon able to roll back particular transactions which are not committable in terms of resetting target objects to the values held before transaction processing had begun, and sending back the original request to the network management platform (NMP) for execution. The application transaction manager (ATM) 503 next receives OK and non-OK responses from the network management platform as to whether each individual derived operation has been successfully atomically accomplished in its entirety. The ATM then sends OK responses to allow application processing, and aborts non-OK transactions and plays back the associated undo log in reverse order to roll back previous committed operations to reestablish original object values in the target objects. FIGS. 6A-6C are a diagram of how an UNDO log is built for an AT application that manages objects that conform to the behaviours which are specified in X.711 for CMIP protocols. In the part of Message Flow For M-SET, a set request to a target object X is sent to the network management platform (NMP) 102 by the application. This is done at the programming interface via a function, CmipSetReq, which abstracts the CMIP M-SET protocol data unit (PDU). At the NMP 132, the AT performing entity buffers the request, issues a number of M-GET messages to the target object X first in order to build an undo record for the M-SET request in the event the transaction is aborted. The undo record is basically another M-SET request to the same target object, but with original values. It will allow resetting the modified target object to the original values that predate the currently requested modification. After the undo record is built, the NMP forwards the M-SET request to the target object. If the M-SET request is successful, the AT performing entity saves its corresponding undo record in the undo log, and then proceeds to the next request in the transaction. Otherwise, it removes the current undo record, and aborts the particular transaction by executing the undo log in reverse order. FIGS. 6A-6C further show an example of how an M-CREATE request is handled by the NMP 102. This relates to Message Flow for M-CREATE. The particular application entity issues the function CmipCreReq to abstract a CMIP M-CREATE protocol data unit (PDU). In particular, an undo record is built for each M-CREATE request. It is substantially an M-DELETE request to remove or "undo" a prior M-CREATE request in the case of transaction abort. Finally, an example of how an M-DELETE request is handled is shown in the part of Message Flow for M-DELETE. In this case, the application entity issues the function CmipDelReq that abstracts the CMIP M-DELETE protocol data unit (PDU) to the NMP. Next, the AT performing entity in the NMP issues a number of GET requests to the target object, gets the responses, and builds them into an undo record of the M-DELETE request. The undo record is for example an M-CREATE request to re-create the exact same target object, with the same or a similar set of attribute values that it had prior to the delete. FIGS. 7A-7B are a diagram of how the undo log is used to abort a particular transaction. Moreover, the undo log is executed in reverse order, and the responses are all returned as not OK, and an abort response is returned. It should be noted that the steps for processing an "ABORT message" are executed according to one embodiment of the present invention when either (i) an explicit ABORT request is received from the application or (ii) an internal ABORT condition is recognized by the AT server, due to the failure of any preceding M-SET, M-CREATE or M-DELETE requests processed by that server within the same transaction. It should also be noted that according to one embodiment of the present invention there is no rollback for CMIP M-GET, CMIP M-CANCEL-GET, CMIP M-ACTION, or SNMP GET requests. These requests are passed through transparently by the AT server and no entry is created in the undo log for processing these requests according to one embodiment of the present invention. FIGS. 8A-8B are a diagram of how an UNDO log is built for an AT application that manages objects that conform to predetermined behaviours and SNMP protocols. In the Message Flow portion of the SNMP-SET, the application entity issues a programming function SnmpSetSimple request to the NMP 102. This function abstracts the SNMP-SET protocol data unit (PDU). At the NMP 102, the AT performing entity will issue a number of SNMP-GET requests to the target object, get the responses, and build them into an undo record. Subsequently, the AT performing entity builds and forwards the actual SNMP-SET PDU to the target object. If the request is successful, it saves its corresponding undo record in an undo log, and then proceeds to the next request in the transaction. Otherwise, it removes the current undo record, and aborts the transaction by executing the undo log in reverse order. Next, the message flow for SNMP-CREATE-ROW-OBJECT in the application entity issues a function named SnmpSetCreateRow to abstract the SNMP-SET protocol data unit (PDU) which is used to create a whole row object. In this case, an undo record is created for the above request. It is particularly a DelReq that is mappable to an SNMP-SET PDU that can delete the said whole row object, so that the reversion of the create operation can be performed, if the particular transaction is aborted. Finally, in the final portion of the drawing, under the heading Message Flow for SNMP-DELETE-ROW-OBJECT, the application entity issues the programming function SnmpSetDestroyRow. This function is used to delete a whole row object. Accordingly, a number of SNMP-GET requests are issued to the target object to retrieve all column values of the row object. These values are used to build a CreReq that is mappable to an SNMP-SET PDU that can in turn re-create the whole row object, so that the reverse of the delete operation can be performed in case of transaction abort. Appendix A An AT server may have multiple transaction running concurrently at the same time. In order to identify the particular transaction to which a message belongs, particular token information is passed along with user message to uniquely identify the transaction. This information is known as the transaction token information. There are three representations of this token according to particular embodiments of the present invention: One token representation according to the present invention requires full transaction information. In particular, the token contains information to uniquely identify a transaction globally for creating a new transaction or for relating to an existing transaction. Another token representation according to the present invention requires a global transaction identifier. In particular, a derived identifier is provided which is mappable to full transaction information. The global transaction identifier may be used in place of full transaction information for repetitive references of the same transaction in request/response messages. This identifier is globally unique and is globally translatable to/from the full transaction information through well-known entities such as NMP's that either provide access to the global transaction mapping function or supply this function themselves. Another token representation according to the present invention requires a transaction identifier. In particular, a derived identifier is used to identify a transaction that is locally unique within the domain of an AT manager. According to the present invention, the transaction token information is expressed according to the following ASN.1 syntax:
CHOICE {
transInfo [1] TransactionInfo,
globalTransId [2] Integer,
localTransId [3] Integer
}
TransactionInfo ::= SEQUENCE {
userName GraphicString,
applicationId INTEGER (0. . .MAX),
misId AET,
threadId [0] INTEGER OPTIONAL,
enclosingTransaction [1] TransactionInfo OPTIONAL
According to one embodiment of the present invention, the selected transaction information is passed in a BeginAT context message. The AT server chooses to return either a local transaction identifier or a global transaction identifier that the application may use subsequently to communicate with the AT server. Appendix B Specification of Application Transaction API "AppTrans" --AT Helper Object AppTrans is a C++ object class which supports Application Transactions (ATs). A constructor of AppTrans associates a selected AppTrans variable to a particular Platform variable as follows: AppTrans (Platform&<plat>=Platform::def_platform); In order to support a asynchronous-only mode of AT in the EM, the following methods are implemented according to one embodiment of the present invention: Begin AT method (synchronous version) Commit AT method (synchronous version only) Abort AT method (synchronous version only) Get Result method Get Result String method The following methods fall within the scope of the present invention: Begin Application Transaction
Result AppTrans::begin_trans(
CDU <atm_name>): // AT Manager name
This method specifies a beginning bound for a new transaction. All messages following this message are bound in this transaction until a message denoting an end transaction or abort transaction is sent. This method runs in synchronous mode and returns the processing result of the beginning transaction request. If a result is NOT_OK, a caller can invoke according to the present invention get_result( ) or a get_result_string( ) method to receive an even more detailed error according to the present invention. End Application Transaction Result AppTrans::commit_trans( ); This method according to the present invention signifies the ending of the currently active transaction and requests the commit processing of the transaction. This method runs in synchronous mode and returns the final result of the end transaction request processing. If the method is returned as NOT_OK, the Caller can invoke get_result ( ) or get_result_string methods to get a more detailed error. Otherwise, the status of the currently active transaction is changed to AT_SUCCESS. Abort Application Transaction Result AppTrans::abort_trans( ); This method according to the present invention requests the start of abort processing for the currently active transaction. This method runs in a synchronous mode and returns the final result of abort transaction request processing. If the method is returned as NOT_OK, the Caller can invoke get_result ( ) or get_result_string ( ) methods to get a more detailed error. Otherwise, the status of the currently active transaction is changed to AT_ABORTED. Get Application Transaction Result and Error String AT_Result AppTrans::get_result( ) char*AppTrans::get_result_string(void) These functions return the status of the currently active transaction and the status string associated with this transaction. The status types and the strings are shown in the below table.
Result Type Result String
AT_INIT Initialized
AT_SUCCESS Successful
AT_ABORTED Aborted
AT_PENDING Pending for End or Abort
request
AT_BEGIN_REQ_ERROR Failed on Begin request
AT_END_REQ_ERROR Failed on End request;
transaction aborted
AT_ABORT_REQ_ERROR Failed on Abort request;
transaction aborted
AT_COMMIT_ERROR Failed to be committed
A typical sequence of network management operations according to one embodiment of the present invention is as follows: DELETE router1; DELETE router2; DELETE circuit1; SET alarm.status="historical" WHERE alarm.originator=router1; SET alarm.status="historical" WHERE alarm.originator=router2; The constraints on such an embodiment are as follows: 1. If the DELETE of either router1 or router2 succeeds, then the DELETE of circuit1 MUST succeed, otherwise a "dangling circuit" will result. 2. If the DELETE of either router fails, then the DELETE of the other router and of the circuit cannot be allowed to proceed, since otherwise the network will be in an inconsistent state (i.e., misconfigured topology). 3. If the DELETE of any router succeeds, then the SET of its alarm status to "historical" MUST succeed, otherwise there will be inconsistent alarms in the system (i.e., alarms will be active when the device that they came from no longer exists). 4. If the DELETE of any router fails, then the SET of its alarm status to "historical" cannot be allowed to proceed, since it is not desired to archive any alarms whose originating device is still active in the network and needs fixing. When router1 and router2 are controlled by different network management agents, one agent may be up while the other is down. Accordingly, the delete of one router may succeed and the other one may fail. According to the present invention, the following request can accordingly be implemented atomically:
BEGIN TRANSACTION;
DELETE router1;
DELETE router2;
DELETE circuit1;
SET alarm.status = "historical" WHERE alarm.originator = router1;
SET alarm.status = "historical" WHERE alarm.originator = router2;
COMMIT TRANSACTION;
and atomic execution of the transaction is ensured under the present invention. Following is an example of Application Transaction.
#include <pmi/app_trans. hh>
main (int argc,
char **argv)
{
Platform plat (duEM);
// Set up connection to the MIS.//
plat = Platform(duEM);
if (plat.get_error_type( ) != PMI_SUCCESS) {
cout << plat.get_error_string( ) << end1;
}
// Prepare locally all images before transacting on the//
// Boot router1, router2, circuit1 images at application side
Image router1 = Image (router1_dn, router1_class);
if (!router1.boot( )) {
exit (1);
}
Image router2 = Image (router2_dn, router2_class)l;
if (!router2.boot( )) {
exit (1);
}
Image circuit1 = Image(circuit1_dn, circuit1_class);
if (!circuit1.boot( )) {
exit (1);
}
// Boot all alarms WHERE originators are either router1 or router2
Album the_alarms = Album("The_Alarms");
Timeout to;
the_alarms.set.derivation
("/systemId=.backslash."sys.backslash."/
log=.backslash."AlarmLog.backslash."
/LV (1)
/CMISFilter (or: {item:equality: (routerid,
.backslash."router1.backslash."},
{item:equality: {routerId, .backslash."router2\"))
");
if (!the_alarms.all_boott(to)) {//Boot failed?
cout <<"Using all_boot( ) : Boot images failed";
exit (2);
}
// Build and invoke Application Transaction requests//
AppTrans at(plat);
// Sync.begin Application Transaction
if (!at.begin_trans(/systemId
=.backslash."sys.backslash."/subsystemId=.backslash."aux.backslash."")) {
cout << "AT Begin Transaction Failed! Reason ="
<< at.get_error_string( ) <<end1;
exit (7);
}
// Async. destroy router1, router2, circuit1
if(!router1.start_destroy( ) {
cout << "Failed to destroy router1. "
<< router1.get_error_string( ) <<end1;
exit (7);
}
if(!router2.start_destroy( ) {
cout << "Failed to destroy router2. ";
<< router2.get_error_string( ) <<end1;
exit(7);
}
if(!circuit1.start_destroy( ) {
cout << "Failed to destroy circuit1. ";
<< circuit1.get error_string( ) <<end1;
exit (7);
}
// Async. set all alarms to "historical".
if (!the_alarms.all_set("status", "historical") {
cout << "Set Failed! Reason = "
<< the_alarms.get_error_string( ) <<end1;
exit (7);
}
if (!the alarms.all_start_stere( ) {
cout << "Store Failed! Reason = "
<< the_alarms.get_error_string( ) <<end1;
exit (7);
}
// Sync. commit Application Transaction
AT_Result result = at.commit_trans( );
// Check result of transaction//
if (result != AT_SUCCESS) {
cout << "AT End Transaction Failed! Reason = "
<< at.get_result_string( ) <<end1;
exit (7);
}
exit (0);
}
Appendix C According to one embodiment of the present invention, the primitives of OSI Transaction Processing Service for Network Management are used to execute the dialogue between the network management application and the Application server. The use of the OSI Transaction Processing service for TMN Network Management is supported in the following international standard: ITU Recommendation X.702: Information Technology--Open Systems Interconnection--Application Context for Systems Management with Transaction Processing [also ISO/IEC 11587]. The OSI Transaction Processing service itself is supported in the following international standards: ITU Recommendation X.860: Open Systems Interconnection--Distributed Transaction Processing: Model ITU Recommendation X.861: Open Systems Interconnection--Distribution Transaction Processing: Service Definition ITU Recommendation X.862: Open Systems Interconnection--Distributed Transaction Processing: Protocol specification A related international standard dealing with Commitment, Concurrency and Recovery is: ITU Recommendation X.851: Information Technology--Open Systems Interconnection--Service Definition for the Commitment, Concurrency and Recovery Service Element [also ISO/IEC IS 9804]. Note that while all the above standards specify the message set that must be exchanged between an application and a Transaction Processing Service Provider (TPSP, which in this embodiment is the Application Transaction server) in order to execute transactional semantics, none of the above standards suggest or specify any mechanism by which the TPSP can internally guarantee atomicity for the transaction by capturing the bound data of the transaction in a consistent state. It is this mechanism, described in this patent application, that constitutes the one of the claims of this invention. The embodiment being described here merely describes how this mechanism in the Application Transaction server may be exercised by an external application using the network management transaction processing message set, as defined in the mappings specified by the X.702 standard of the X.711 CMIP TMN management protocols to X.860/X.861/X.862 Transaction Processing services. In an X.702-compliant embodiment of this invention, both the network management application and the Application Transaction Server are X.860/X.861/X.862-compliant Transaction Processing Service user Invocations (TPSUIs). This means that all CMISE, SMASE, and ROSE PDUs exchanged between them are wrapped within the TP-DATA primitive as defined by the X.861 TP service. Note that it is possible to have an X.702-compliant TP server that is also capable of servicing non-X.702 transactions, e.g., an X.702 -compliant embodiment of this invention may co-exist in the same physical computer system and same software process as the other (non-X.702-compliant) embodiments of this invention described earlier. This is possible if the non-X.702-based network management transactions are executed over an association which is not in the pool of TP associations managed by the X.860/X.861/X.862-based TPSP. In this embodiment, both the network management application and the Application Transaction server, being TPSUIs, have a TSPU-Title. Since the application does not necessarily need to know whether the network management platform has a separate Application Transaction server process for servicing transactions, the TPSU-Title of the Application Transaction server is considered to be the TPSU-Title of the entire network management platform, i.e., the platform as a whole is considered a TP server. However, messages directed to this TPSU-Title are routed directly to the Application Transaction server. When an application starts a transaction delimited by a Begin-Transaction primitive, the API library (PMI) checks to see if an ACSE application-association has been established with the X.702-compliant Application Transaction server; if not, it establishes such an association. Next, it checks to see whether a TP dialogue has been established with the X.702-compliant Application Transaction server; if not, it issues a TP-BEGIN-DIALOGUE with the Application sever. Finally, it issues a TP-BEGIN-TRANSACTION to delimit the beginning of the transaction. When a TP dialogue is established between the network management application and the X.702-compliant Application Transaction server, the following functional units are selected as part of the TP dialogue. A coordination level of "commitment" is selected for the dialogue, thereby relieving the network management--application from coordinating the commitment of the bound data itself; A Commit Functional Unit and an Unchained Transactions Functional Unit are selected; The Handshake Functional Unit may or may not be selected. In this embodiment, procedure calls invoked by the application to delimit a transaction, as well as the network management operations invoked by the application, are sent to the X.702-compliant Application Transaction server using the following mappings to X.860/X.861/X.862 TP service primitives, as specified by the X.702 standard:
Begin Transaction A-ASSOCIATE (if necessary)
TP-BEGIN-DIALOGUE (if necessary)
TP-BEGIN-TRANSACTION
M-CREATE TP-DATA wrapping CMISE/ROSE
M-CREATE PDU
M-DELETE TP-DATA wrapping CMISE/ROSE
M-DELETE PDU
M-CANCEL-GET TP-DATA wrapping CMISE/ROSE
M-CANCEL-GET PDU
M-GET TP-DATA wrapping CMISE/ROSE M-GET PDU
M-SET TP-DATA wrapping CMISE/ROSE M-SET PDU
Commit Transaction TP-COMMIT
Abort Transaction TP-ROLLBACK
END TRANSACTION TP-COMMIT (if no prior issuance of
TP-COMMIT) TP-END-TRANSACTION
If the Handshake Functional Unit has been selected, the primitive TP-HANDSHAKE issued by the network management application is considered to be the equivalent of the TP-COMMIT primitive. According to one embodiment of the present invention, the X.702-compliant Application Transaction server issues a TP-COMMIT-COMPLETE primitive to the network management application when any TP-COMMIT indication has been successfully and completely serviced. It further issues a TP-ROLLBACK-COMPLETE primitive to the network management application when a TP-ROLLBACK indication has been successfully and completely serviced. According to one embodiment of the present invention, an X.702-compliant Application Transaction server uses these message sets as external communication mechanisms to interact with the outside world (network management applications). It further continues to use the undo log mechanism to ensure that transactions that it is executing capture adequate data about the transaction's initial state so that it is capable of being rolled back if required.
|
Same subclass Same class Consider this |
||||||||||