Addressing Transaction Issues
At the time of this writing, SOAP doesn’t provide a form of native transaction support. Many developers feel this is a major concern because they’re used to using transactions for every desktop application. The first question that you should ask yourself is whether your application actually requires the use of transactions. Consider the importance of the data and the worst-case scenario if the data is either lost or damaged. In at least some cases, you’ll find that transactions aren’t required. For example, transactions aren’t necessary for applications that only allow the user to view the data in question without modification. Likewise, applications in which the user can only add or modify non-critical data can probably exist without benefit of transactions.
No matter what you do, many applications are still going to require transactions. The data isn’t critical enough that you have to keep it off the Internet, but it’s also critical enough that you need to protect it in some way. The big thing to remember is that you’ll incur data loss when using SOAP because the Internet is inherently unsafe.
Caution
The Internet is unsafe. If you have any doubts about this statement, spend some time reading about the security breaches that occur every day. If your data is so critical that you can’t afford loss or damage, your best bet is to keep it off the Internet. This book provides you with some ideas of how to circumvent problems with data transfer on the Internet. However, none of these methods guarantees specific results, and you might find that you still lose data. Always provide some means of recovering the data and keep in mind that you’re going to lose some data along the way.
Some developers have come up with interesting ways to provide at least a modicum of transaction support for their applications. One technique that seems popular is to add three elements to every SOAP message: user ID, session ID, and package ID. Using these three elements allows you to track the progress of every piece of data that your application transfers. However, using this technique requires that you maintain state information outside of the application. This means that there’s a chance the transaction information could get out of sync with the actual data transfer and you’ll lose data anyway.
Another popular technique is to use cookies to track the progress of a data transfer. However, this means that you must set up both systems to use the cookies and agree on a methodology for using them. Some developers also complain that using the cookie method is overly complicated.
Note
 | Transactions are a hot issue for developers right now. You can find a wealth of information on the topic online. TNL.NET (http://www.tnl.net/newsletter/2001/soapsecurity.asp) includes a newsletter that addresses the issue of SOAP security during transactions. You can find a preliminary demonstration of SOAP transactions at http://www.xbrlsolutions.com/public/demos/crossreference/Soap/PostTransaction.asp. You’ll find at least one white paper on the topic of transactions on the SOAP Web Resource Center (http://www.soap-wrc.com/webservices/default.asp). Perl users will want to read the Quick Start with SOAP (http://www.perl.com/pub/2001/01/soap.html) white paper that also includes information about transaction support. A number of other sites offer small tidbits of information about transactions for specific languages. Of course, you can always read about SOAP transactions in the specification (http://www.w3.org/TR/SOAP/#_Toc478383497). |
Obviously, these two techniques are inadequate for today’s data transfer needs. The vendors involved with SOAP are working on a new set of specifications that will allow developers to use transactions in a consistent fashion. After vendors standardize the method for using transactions, you’ll be able to use SOAP for data that is more critical than your average task list. At the time of this writing, transactions are more a gleam in the eye of some vendors than something written down on paper. It will take some time for vendors to devise a good solution to the problem of transactions—one that will honestly work for at least the majority of SOAP users.