Supporting transactional semantics for RPC definitions in Yang

Yang is a standard based schema for NETCONF to define data model, remote procedure calls and notifications. Though Yang is intended for device management, it is a good fit to define data model, remote procedure calls and notifications for any type of service oriented applications.

Many software involve interaction with multiple services to complete an end to end workflow. All these service collectively change the state of the whole application. Failure at any stage in the workflow puts the application in an inconsistent state unless otherwise the whole process is done as an atomic operation. To achieve this atomicity, distributed transactions are used. Yang currently does define any way to achieve transactional semantics for RPC call.

In order to overcome this transaction semantics for RPC call in Yang it would be good to have the following enhancement to Yang standard. This enhancement defines semantics which will help the transaction co-ordinator and transactional resources to achieve distributed transactional workflow. The solution supports transaction across multiple RPC in a single service or multiple services (across multiple Yangs).

• A new construct “transaction” is added to define and associate transaction related configuration and RPCs.

• A new RPC parameter is added to pass global transaction identifier to the RPC.

The solution involves a Transaction Manager (co-ordinator) and one or more Transaction resources. Resources define Yang with the above mentioned Transaction constructs. Every RPC implementation needs to provide abort & commit RPC’s as a part of the Transaction construct.

The transaction manager uses the transaction constructs defined in the individual resource Yang to co-ordinate the transaction lifecycle. Resources implementing these RPC are unaware of the global transaction. Resources should manage the local transaction and associate local transaction with the global transaction ID.

With the proposed solution the transaction manager controls the transaction workflow. It has the flexibility to add any number of RPC to a transaction. The transaction manager uses standard two phase commit protocol to maintain data consistency and integrity.

1.   New transaction construct:


·     rpc: The entry in transaction construct is used to map the RPC to which this Transaction construct needs to be associated to. This can be any Yang RPC name.

·     notification: A Yang notification that can be sent to the Transaction Manager about the individual resource’s transactional decision whether it is ready to commit or have to abort.

·     abort-rpc: API to be called by the Transaction Manager to abort transaction.

·     commit-rpc: API to be called by the Transaction Manager to commit the transaction. Resource should not fail to commit at this stage. Once commit is complete, any temporary resources held by the application can be released.

·     timeout: The timeout period for which the implementation should wait for abort or commit commands by Transaction Manager before doing self-initiated abort. A notification will be sent to Transaction Manager before initiating the abort.

2.   New parameter in RPC:


The transaction parameter in the RPC is used to provide the transaction-id by the Transaction Manager. This ID will be assumed to be unique across the system. Resources should use this transaction id to associate with local transaction.

The framework can be used to provide transaction for multiple RPC’s within a single or multiple transactional services. Each individual RPC provides local transaction contract and either a caller or an external Transaction Manager co-ordinates with RPC resources to carry out the transaction. The RPC resource is unaware of the existence of global transaction in which it is participating. The client controls the transaction workflow & has the liberty to add or remove any no of transactional RPC as required for the workflow.

A new parameter transaction is added as a part of rpc construct to support transaction workflow. This parameter will be used by the the coordinator to pass transaction id to the resource.

For every RPC request that supports transaction, the client has to pass the transaction identified that will be used to associate local transaction with the global transaction. Any subsequent notifications and abort or commit RPC calls have to include the same transaction ID that is passed initially.

The server adds the transaction construct which has the following 5 entries rpc, notification, abort-rpc, commit-rpc, timeout.

·     The rpc parameter will refer to the RPC to which the transaction construct is associated to. The client will require to apply the configs provided in the transaction construct to the RPC defined in this statement.

·     notification entry will be used by implementation to notify the abort or commit decision to the caller. The client will use the notification to keep track of the success/failure of all the RPC it invoked as a part of the transaction workflow. The client will also decide on how to proceed with the transaction depending on the status received from each of the RPC. The client decides whether to Commit or Abort depending on the Notification responses from individual resources.

·     abort-rpc is used whenever an abort needs to be triggered for a running transaction. The server need to define RPC handlers to abort any transaction of a particular RPC implementation.

·     commit-rpc is used by the client once all the RPC’s in a transaction workflow returns with ready Notifications. The commit RPC is used to confirm the transaction. The server needs to add an RPC handler to commit-rpc entry which will clear any transaction specific temporary data it has stored to carry out the local transaction.

·     timeout is used by the resource implementation for which it has to wait for abort or commit calls before deciding to abort the transaction on its own. This is needed in case the Client/Transaction Manager fails abruptly or it just abandons the transaction in the middle. Resource will send a notification to the client before aborting the transaction.

1.    Example:

The Sample workflow has 2 RPC’s create & deploy. The client will first invoke RPC create & latter on invoke deploy. Once the client receives ready notification from both the RPCs the client will initiate commit RPC provided by both the Services in their respective transaction construct. If any one of the notification responds with an abort command the client will invoke the abort rpc provided in the transaction construct of every other resource RPC.

Sample Yang of Service 1: Create configuration

Sequence diagrams.

Below sequence diagrams show how global transaction can be coordinated between two RPC resource calls. Transaction co-ordination can be handled directly by the client or an external Transaction Manager. Fig 1 shows the positive case where all individual resource transactions are committed successfully. Fig 2 shows the scenario of global transaction aborting due to one of the resource transaction failed.