Master of Record Design Pattern for Broker By Conor Brankin

---

Introduction

Enterprise Server-based integrations are often used to synchronize data across disparate applications.

In November 2002 webMethods Ezine, I described the latching functionality provided by webMethods. The article offered an in-memory solution to latching that provided enhanced throughput and superior performance.

In this article, I will describe an alternative to latching that employs the "Master of Record" design pattern to overcome the Race Condition introduced by the latching mechanism.

---

The problem with latching

A full description of latching is provided in the November 2002 webMethods Ezine. Consider a scenario with two applications, Order and Warehouse, each having their own copy of an order record. The latching mechanism's sequence of documents prevents a never-ending integration loop. It is shown in Figure 1.

Figure 1

The latch will block an update to the Warehouse application if it occurs at the same time as the update to the Order application. Therefore, the Warehouse update is never published and the Order update is published twice. In most cases, this is unacceptable behavior.

It does not mean that latching cannot be used, however. For example, updates to Order may only happen during normal business hours, whereas updates to Warehouse may happen in batch mode during off-business hours. In this scenario, the race condition does not apply and the standard, in-memory latching mechanism is applicable.

---

Master of Record

Master of Record is a design pattern that is an extension of the master/slave design pattern. The steps are as follows:

1. An update is made in the Order Application.
2. A notification in the Order Adapter fires.
3. The Order Adapter publishes a Request Update document.
4. The Master Adapter receives the Request Update document.
5. The Master Adapter queries the Master Store, constructs a UDM document and publishes the UDM. The Warehouse and Order Adapters subscribe to the UDM.
6. The Warehouse and Order Adapters update their respective applications.

Master of Record is shown in Figure 2.

Figure 2

---

The external update does not update the "real" database table

You may be asking why anyone would use the latching mechanism for implementing bi-directional synchronization as the Master of Record design provides similar functionality while eliminating the possibility of race conditions.

The Master of Record design is dependant upon a single entity -- the Master -- controlling updates to all records. Therefore, when the update is made to the Order application in Step 1, the update does not modify the Order table. Instead, a row is inserted into a staging table.

The notification event (Step 2) monitors the staging table and an integration component manages the staging table's content. When the Order application receives the UDM, the "real" Order table is updated.

This is a drawback, as the application making updates to the Order application may require significant modifications from its original design and implementation to make use of the staging table. The latching mechanism, on the other hand, can be introduced into an enterprise integration with little to no changes to the existing infrastructure.

The latching mechanism, therefore, can be rolled out to a production environment without the need for extensive testing of already tested and proven applications.

---

The ATC_XRef table is still required

It is important to realize that the use of the Master of Record design pattern does not remove the need for the ATC_XRef table or the EntUtility Adapter.

The Order or Warehouse application in the figure above can publish a Request Update document. The Request Update document contains the canonical ID from the ATC_XRef table and the Master of Record store contains the canonical data associated with this canonical ID.

When the Master Adapter receives a Request Update document, the Master Store is updated with this data, the UDM is constructed and a complete UDM is published from the Master Adapter. The Order and Warehouse applications use the Canonical ID from the UDM to access the ATC_XRef table to obtain their native identifiers for the Order record. Based on the corresponding native IDs, the Order and Warehouse Adapters are able to update the proper local records.

---

[1]  2  Next>>

Go Deeper on the Subject: The wMUsers Discussion Forums