Enforcing data consistency in the Open Transport specification

As part of creating the Open Transport standard, we have considered how the data exchanged via the API will be enforced on an automatic and day-to-day basis (in other words, without human intervention).
Our concern is that without any enforcement the standard wouldn’t be trusted and therefore might not gain the full adaption it needs to.

But luckily there are several ways to govern the data exchanged within an interoperable technology standard, each with their benefits and potential stumbling blocks:

Centralised look-up

This is where at least some of the reference data is managed and accessed in a central hub. This hub is an easy way to ensure consistency of the standard, as every party that implements it has to use the centralised look-up service in some way. Changes to the look-up are protected by restricting update access and only providing read access to the reference data. However it means that the hub needs to be highly available and potentially capable of dealing with many consecutive requests (if the standard is popular or the implementations are too “chatty”). Note: availability can be significantly improved by simply having a duplication of the central hub data just replicated in another location.

Decentralised look-up

This is where every implementation of the standard has a copy of the reference data and they also become a hub. Updates to every decentralised look-up are propagated out to the other participating parties. This allows for a far more fail-resilient solution that is not dependant upon a single central service. However the consistency of the data at each replicated look-up implementation must be maintained, or there is the risk that an error can get into the system and propogated out. Plus any delay in the propagation of the data means a potentially inconsistent service.

No centralised or decentralised look-up

This is where enforcement of the standard is done just by each implementation, but with no look-up. This means that any new implementation can be created quicker, does not have to wait for a central hub to be initially updated & checked and also does not have to bother hosting or maintaining a decentralised look-up service. But for obvious reasons this approach has the greatest likelihood that the standard will not be enforced correctly or fully, as each implementation done this way is dependent upon how closely the developers want to follow and test things.

As already mentioned in a previous blog posting, the Open Transport team have for now chosen to use a centralised look-up service to maintain strict enforcement of the standard.

%d bloggers like this: