Print This Post

Registries – Beyond Databases Part 1 – A Better Place to Start

Most data-centric applications, from social media to image management, require a persistent data store, and many application developers take a database as the point of departure for building their application. This is the first in a series of blog posts suggesting that there is a better starting point, a registry.

Check out the other posts in this series:

What is a Registry?

The term “registry” is quite commonly used, and we all hear phrases like Land Registry, Gun Registry, Housing or Building Registry, or Registry of Corporations. Virtually all of these registries are applications built on a database (some at great expense). Any Canadian knows the absurd history of the Gun Registry, where costs spiraled to more than a billion dollars.

There are, however, many more specialized registries, such as the CRS Registry maintained by the Organization for Oil and Gas Producers, and the proposed registries for Air Traffic Management being developed by the Federal Aviation Administration and EUROCONTROL.

It is our contention that all of these registries have a considerable degree of commonality and that there is a much better starting point than a database, namely a registry framework. But what is a registry framework?

A Framework for Building Registries

A registry framework is a piece of software that provides persistent storage of registry objects, like a database, but adds many more useful features out of the box that make the deployment of a specific registry faster and cheaper (where were you when we did the gun registry?). Some of the key features of a registry include:

  • It is a web service, meaning you can access the registry contents over the web, and update them too. Insert new registry objects, conduct searches, delete or modify existing registry objects just by sending messages over the Internet.
  • It supports a powerful and intuitive data model. Of course, this is also what database management systems do. Most database management systems these days are relational, and provide relational data models, and so we talk about relational database management systems (RDBMS). Relational data models are very expressive, but not so intuitive. Furthermore, if you want to migrate the information model built on the data model, relational (and object-relational) systems can make this quite difficult.
  • In a registry like OGC’s CSW-ebRIM, associations (relationships) and classifications (taxonomies) are the things you work with directly. In an RDBMS, they are usually achieved using foreign keys in a source table that point to a target table. Adding new relationships is difficult because it means a physical scheme change, and, with lots of such tables and pointers, migrating from one schema to another can be an expensive proposition. With a registry data model all of this is hidden and the developers and the users work directly with these much higher level constructs instead of trying to work at the level of the database tables.

Registries, however, provide more than just a powerful and intuitive data model.

The Benefits of Using Registries

Registries provide mechanisms for data governance. Most registry objects go through multiple states in the course of being recorded and managed in the register. When it is first added, a registry object representing a gun might be in the “submitted” state, signifying that it has not yet been verified. A land parcel might have life cycle states like “submitted”, “subdivided”, “vacant”, or “built”. To support more than one type of object, a registry framework provides the capability to create the set of life cycle states for each type of object. Rather than invent these mechanisms from scratch, the developer simply uses the provided mechanisms.

In addition to life cycle state management, registries provide mechanisms for automated notification when anything in the registry changes. For example, a license approver might be notified when a new license object is placed in the registry for their approval, and a response might be automatically sent to the permit applicant when its state is set to “approved”.

A third component of governance is the provision of an audit trail. Such an audit trail is at the application level, and records changes in application objects rather than database transactions. This means that administrators can quickly see what objects were registered or had their states changed, etc.

In many applications, we want to know “where” things are located. Think again of a registry of guns, land parcels, or citizens. Location may be a point, a collection of points, or an area (such as a land parcel). So a registry should support location, and enable update of geometric properties on any registry object, using its web service interfaces. Also, registries must support the discovery of any registered data, and this must include discovery by location, along with taxonomic classification, and free text.

When data is requested from a registry, it may not be returned in the form desired by the consumer. For this reason, registries provide a transformation framework that invokes a desired data transform plug-in when requested by the user. Data can thus be returned in HTML, JSON, KML, GML, or in another desired data or presentation encoding. Developers can create their own transform plug-ins to output data in any desired format.

Of course, going the other way is also required, and a registry typically provides a harvester framework into which a developer can plug specific harvester components that can read data from a specific source and map it into the currently “active” information model. Most registries provide tools for the fast development of these harvester components. Harvesters for anything from ESRI geospatial features to Microsoft Office documents or GeoTIFF images should be readily available. Developers can also create their own harvester plug-ins to enable the integration of data from more or less any data source.

Some registries provide additional tools like client support libraries for iOS and Android, or graphical tools for the rapid construction and management of information models.

It should be clear that registries offer a significantly more advanced starting point for many data-centric applications than building on a traditional RDBMS, and this can translate to significant savings in time and money. To get to market sooner, and to provide more advanced functionality with lower development costs, start with a Registry.