Note: This section discusses transactions as they relate to Web Services, so it assumes that you are quite familiar with transactions - how and why they are used.
Transactions in .NET are one aspect of a larger set of services collectively called COM+ Services. These services include the following:
These services ensure higher level of consistency, stability, security, and scalability. These services also provide a great deal of plumbing that would otherwise be rather difficult and time-consuming to develop.
Note: To understand how to use COM+ Services in general, refer to MSDN for help on System.EnterpriseServices class as well as sn.exe, al.exe and RegSvc.exe utilities.
The DTC is a Windows Service that coordinates transactions across components, and is used with programmatic interfaces and other services supplied by COM+ to facilitate the use of transactions with little effort by the developer. By implementing certain interfaces, components can be enlisted to work within the context of a calling application's existing transaction. The component may alternatively decide to start a new transaction of may not even require a transaction at all. Transaction requirements by a component can be set by the Component Services Administrator tool. If a component supports a transaction it allows the DTC to query its state and to issue commands. In a sense the component allows the DTC to tell it what to do and when to do.
The DTC uses the two-phase-commit protocol to coordinate the separate actions of each component. In short, the DTC gets a vote from each participating component on whether that component can carry out its actions or not. The collection of votes must all be yes in order for the transaction to commit (all or none). If only one component votes not to commit then the entire transaction is aborted. If all components vote to carry out the transaction, then the DTC issues another round or messages asking the components to complete the transaction.
COM+ Services are COM-based and are therefore unmanaged code. Therefore, due to the differences between COM+ and .NET and the interop layer provided by .NET, some effort is required to make use of COM+ Services in .NET assemblies. This effort includes adding several attributes to your classes, running a couple of utilities that will load and register the .NET assembly, creating a type library for the assembly, importing the type library into a COM+ Services application, and configuring the application's properties.
When using ASP.NET, the complexity of adding transaction support to the Web Service is hidden through the use of a single property for the [WebMethod] attribute.
There is limit to what you can do with transactions in Web Services. The limitation is that Web Services can participate in a transaction only as the root of a new transaction. Web Services cannot be just one operation among others. In other words, Web Services must invoke the operation that creates a new context containing other operations which all must operate as unit. The Web Service is simple the application that kicks start the transaction because it uses HTTP which is stateless by nature.
As mentioned previously, a single property of the [WebMethod] attribute is required to add transaction support. This property is called TransactionOption. There is also another useful property called AutoComplete. Both are discussed below.
To indicate that the Web Service should be the root of a transaction, set the TransactionOption property of the [WebMethod] attribute of any web method that will trigger a new transaction. For example:
[WebMethod(TransactionOption=TransactionOption.Required)]
public int foo() { ... }
There are five possible transaction options, but for the purposes of Web Services that can only be the root of a transaction, these options break down into two options:
| TransactionOption | Meaning |
| Disabled NotSupported Supported |
Indicates that the Web Service method does not
run within the context of a transaction. These options turn off the Web
Service's ability to participate in a transaction.
Because using any of these three options will disable transactions, keep your code self-documenting by always using Disabled. |
| Required RequiresNew |
Indicates that the Web Service method requires
a transaction.
Because Web Services can only be at the root of a transaction, and because using either of these options will create a new transaction, keep your code self-documenting by always using RequiresNew. |
When managing a unit of work that comprises a transaction, you need to work with the ContextUtil object provided by System.EnterpriseServices class to programmatically tell the DTC when to send the RollBack or Commit statement.
Instead of working with the ContextUtil object, you can automatically rollback or commit a transaction as soon as you determine the appropriate outcome, by applying the AutoComplete property to the Web method as follows:
[AutoComplete]
[WebMethod(TransactionOption=TransactionOption.Required)]
public int foo() { ... }
To use transactions in any Web Service you must create a reference to the System.EnterpriseServices class. Example Transaction is used to illustrate these concepts. IE was used a client.
It is really the sequence of statement-execution and events inside these transactional Web methods that is much more important than the seeing the final results. Therefore, I recommend that breakpoints be set at the top of each of the given two methods in order to better understand the sequence of events.
Note: Currently there is no mechanism for managing transactions in multiple ASP.NET Web Services residing across the Internet. However, the Transaction Authority Markup Language specification at www.xaml.org contains a specification for this purpose, although this is apparently sponsored by Microsoft competitors.