Browse DevX
Sign up for e-mail newsletters from DevX


Getting Started with Windows Communication Foundation Transactions : Page 3

Transactions aren't just for database applications any more. Using the unified transaction system in the Windows Communication Foundation, you can create transactable services not only for database applications, but for messaging, workflow, and other types of applications as well.




Building the Right Environment to Support AI, Machine Learning and Deep Learning

Building a Client for the Service
With the service in place, you can add a Windows Form client application to the project. Lay out the basic form with labels, options and buttons as shown in Figure 3, or just use the version from the download.

Figure 3. Designing the Client: The figure shows the sample Windows Forms client in the Visual Studio forms designer.
A user enters a value into the text box, selects a conversion method using the radio buttons, and clicks the Convert button to call the service. But before writing code to make that happen, you need to create a proxy to the service. To do this, follow the instructions on the service page (see Figure 2), using the svcutil.exe tool to generate a proxy class file and a client configuration file. I've found it's easier not to use the generated config file (called output.config); instead, simply create your own version that uses the portions required for the application at hand, and call it App.config.

To run svcutil.exe, run the following command from a command prompt.

Scvutil <url of service>?wsdl

The preceding command creates two files, which will likely be named tempuri.org.cs and output.config. The tempura.org.cs file contains the proxies that you need to call your service, so add it to your Windows Client project.

Then, add a new file called App.config to the project. Give it the following contents (these are filtered from output.config for simplicity):

<?xml version="1.0" encoding="utf-8" ?> <configuration xmlns= "http://schemas.microsoft.com/.NetConfiguration/v2.0"> <system.serviceModel> <client> <endpoint configurationName="default"  address= "http://atlas/TransactableService/Service.svc/" binding="wsHttpBinding" bindingConfiguration="Binding1" contract="ITransactableTemperatures"/> </client> <bindings> <wsHttpBinding> <binding configurationName="Binding1" transactionFlow="true" /> </wsHttpBinding> </bindings> </system.serviceModel> </configuration>

Now you can set the btn_Click event handler to call the transactable service using a transaction scope, like this:

private void btnConvert_Click( object sender, EventArgs e) { using(TransactableTemperaturesProxy theProxy = new TransactableTemperaturesProxy("default")) { TransactionOptions transactionOptions = new TransactionOptions(); transactionOptions.IsolationLevel = IsolationLevel.ReadCommitted;   using ( TransactionScope tx = new TransactionScope( TransactionScopeOption.RequiresNew, transactionOptions))   { double d = Convert.ToDouble(txtIn.Text);   double dResult = 0.0D;    if (rbCToF.Checked)      dResult = theProxy.ctof(d);      else     dResult = theProxy.ftoc(d); lblOut.Text = dResult.ToString();      tx.Complete();    } } }

The preceding code first sets up the proxy, using the "default" configuration name. You can see this is the name of the configuration within App.config.

Next the code sets up a new set of transactionOptions, configured for IsolationLevel.ReadCommitted (matching the service IsolationLevel setting, as discussed earlier).

Finally, the code sets up a new TransactionScope called tx within the using{} block, so that everything that occurs within this block is transacted within the tx scope. The last line of code in the block flags tx as Complete, and the transaction finishes successfully.

Transactions are vitally important in any connected system. Until now, developers have typically equated transactions with database methodology, but transactions can apply equally well to other types of operations. In connected systems, messages being passed around or orchestrated within a workflow can benefit greatly from transactability. Offering transactionable services from your code is critical when putting together a robust, enterprise-class infrastructure. Thus, transactability is one of the major pillars of the Windows Communication Foundation. In this article you've seen how to build a simple transactable service, and how to consume it from a Windows Forms client. While this example only scratches the surface of the possibilities, it should let you hit the ground running to build and offer transactable software services to your clients!

Laurence Moroney is a freelance enterprise architect who specializes in designing and implementing service-oriented applications and environments using .NET, J2EE, or (preferably) both. He has authored books on .NET and Web services security, and more than 30 professional articles. A former Wall Street architect, and security analyst, he also dabbles in journalism, reporting for professional sports. You can find his blog at http://www.philotic.com/blog.
Comment and Contribute






(Maximum characters: 1200). You have 1200 characters left.



Thanks for your registration, follow us on our social networks to keep up-to-date