Why redundant storage of bidirectional links is unavoidable in loosely coupled applications

Bidirectional linking of artifacts across applications can be done in two ways:

• Symmetrical: each application stores a link to the artifact. Since links are stored redundantly, link integrity is not automatically ensured.
• Asymmetrical: the link is only stored in one application and the other direction of the link is implemented via a query. Since links are not stored redundantly integrity problems are avoided.

In the following I've collected some arguments why redundant storing is the more practical approach for loosely coupled applications.

Transactional Integrity

In loosely coupled distributed applications we have different expectations with regard to transactional integrity or robustness: within one application we expect full transactional integrity, across different applications we are willing to relax our integrity expectations.

An example for "integrity within the application" is how we treat "duplication resolution" in RTC. If a bug is a duplicate of another bug, a link "Duplicate Of" will be established between the bugs and the first bug will be assigned the state "Resolved as Duplicate". This establishes a constraint on the link: whenever there is a "Duplicate Of" link, the state must reflect this with a value of "Resolved as Duplicate" and vice versa. Maintaining this constraint is simple if modification of the link and the resolution state can be done in a transaction and if this transcation stays within the bounds of a single application.

For links across applications, we expect that a link to an artifact in another application can be broken, which would happen if the other application is down or temporarily unavailable. However, we still expect to "see" the broken link in the meantime, so it should not "disappear" silently.

If we now consider the asymmetric model and store the link and the state in different applications, things become more complex. One consequence is that applications become more tightly coupled: If the application which stores the link goes down or becomes temporarily unavailable, the application that keeps the state cannot allow the state to be modified because that would violate the constraint. This will prevent the end user to continue his work and is unacceptable.

For links spanning different applications the asymmetric models means that the "calculated" link direction cannot be displayed because the corresponding query would fail. Again an unacceptable situation for the end user.

The only solution to these problems is to introduce a local proxy that remains available even if the other applications are not.

Efficient Queries

If the link is only stored on the "other side" (and calculated on "this side"), it is difficult to have efficient queries because "joining" across system boundaries will be required. As a consequence, applications most likely will store linking information locally in order to enable efficient queries.

-- AndreWeinand - 16 Feb 2009