he ACME Toothpick Company has a problem: their applications do not communicate. The toothpick making process is causing big headaches for the purchasing and sales departments. The problem stems from the way toothpicks are manufactured. First, a log is selected from inventory and fed into the toothpick maker. Approximately three minutes later, a brand new toothpick emerges. The left over wood is sent offsite for a separate project.
There are two applications involved in the log making process: the Log Inventory Manager (LIM) and the Toothpick Manufacturing Manager (TMM). Unfortunately for ACME, LIM and TMM do not communicate.
First, an employee goes into LIM and removes a log from the inventory. Then the employee logs into TMM to start the manufacturing process. Problems occur when the toothpick machine is ordered to build a new toothpick, but finds that there are no logs left in inventory. Other times, the employee finds that the toothpick machine is broken but the log was removed from inventory. Together, these issues caused an inaccurate log inventory. The purchasing department has no idea how many logs they need to order or how many logs they actually have in inventory. In addition, the sales department has no idea how many toothpicks they have available to sell to customers (see Figure 1).
Figure 1. ACME's Current Process: An ACME employee has to manually update both systems
and hope everything works out.|
The ACME IT Department decides to use web services to solve their business problem. A new application is constructed to control toothpick production and coordinate efforts between the toothpick building machine and the log inventory manager. The key challenge is ensuring the toothpick manufacturing and the log inventory stay synchronized. Web services alone are not an adequate solution to this problem because ACME needs to use transactions. The good news for ACME is that both LIM and TMM were built using the Microsoft .NET platform. The Windows Communication Foundation (WCF), with its built-in support for transactions, is the best choice.
Before discussing the details of how transactions are implemented in WCF, it makes sense to say a few words about transactions. A transaction is defined as a unit of work that is atomic, consistent, isolated, and durable. Together, these four qualities form the acronym ACID (see Figure 2).
- Atomic means that after a transaction completes, either all the changes are successful or they are all undone. The data is not left in a state where only a portion of the changes is complete.
- In addition, the database is always in a consistent state. Whether a transaction completes or fails, the data must be in a proper state.
- Isolated refers to the fact that transactions cannot see changes happening in another transaction while they are in process. In other words, transactions only see the before and the after, not during.
- Finally, durable means that after a transaction successfully completes, the changes remain.
Together, these four ACID qualities ensure the log inventory and toothpick manufacturing process work together and guarantee ACME accurate data.
Figure 2. ACME's Proposed System: An ACME Employee interacts with a single system and a WCF transaction ensured
the accuracy of the data.|
The first task for ACME developers is to expose the functionality in the LIM and TMM applications as WCF based services. The starting point for any WCF service is the contract. Below is the listing for the LIM service contract:
public interface ILogManager
void SubtractInventory(int amount);
void AddInventory(int amount);
The key attribute is TransactionFlow
. The TransactionFlow
informs the WCF runtime how it should behave with respect to transactions flowed from the caller. The available options are:
- Mandatory: The caller must flow a transaction.
- Allowed: The caller may flow a transaction.
- NotAllowed: The caller cannot flow a transaction.
interface uses both the Mandatory
options on the
operations, respectively. What this means from
an implementation perspective is that a caller to the SubtractInventory
operation must flow a
transaction while a transaction is optional for callers to the AddInventory
that the TransactionFlow
attribute does not control how the service operations will actually
use the flowed transaction; it simply defines what the service caller may or may not do. As you will see, you control participation in a transaction at the service implementation level.
After you define the contract, you can create the actual service implementation (see