Chapter 16 - Update Transactions

Abstract

The update service is an alternative to a read-only service. With an update service, the CRUD operations of create, read, update, and delete are implemented. The granularity of the service and number of exposed operations determine whether the operations are exposed by a single coarse-grained service or across several fine-grained services. The most common and effective pattern for updates is a simple read-only, request-reply. This pattern allows consumers to not only request the update of data but also to verify whether the update request was successful or a fault occurred. There are several design complexities for update servicing. The first is to consider that most enterprise servicing scenarios will involve multiple consumers, services, and applications, all of which may request a read or update of the same data from the same underlying data at rest sources. This can result in complex database locking, competing requests for access to the same data, and the potential for timeouts. Another complexity is with the number and type of underlying data at rest sources that are the target of an update request. Federated updates across multiple data sources must be correlated. The entire set of updates must be treated as a single unit of work. Another complexity is the granularity for the unit of work. While a request-reply message exchange pattern (MEP) is the most common and recommended interaction for an update, there may be sufficient rationale to warrant a fire-and-forget update.