Originally published on LinkedIn: https://www.linkedin.com/pulse/more-waiting-tables-eddie-yip 
My colleges, Ron Lake  and Rob Sterpin , have been discussing the use of modern Registries in the Oil & Gas and Aviation industries. In this blog post, I want to discuss the technical advantages to web service application developers. Experiences in building web service applications for customers using a modern Registry have shown that we saved about 25-30 percent in total development time over using a relational database.
So what is a modern Registry?
A Registry is a server side platform and datastore with high level business object constructs that alleviates the need for application developers to design, code, and configure their business objects to a physical relational database schema. It is based on the CSW 2.0.2 and ebRIM 3.0 open standards from OGC and OASIS respectively.
We create software to help us manage complex tasks in the real world. These complex tasks can be managing the multitude of aviation data services for modern Air Traffic Management (e.g. System Wide Information Management, or SWIM), or managing the components in the hundreds of miles of gas pipeline that cross our nation, or organizing data from natural disaster simulation runs for emergency operations management.
The complexity of these real-world problems is tamed by creating an object model that accurately describes them. For example, a SWIM Registry will have objects that represent aviation data services, and these will be associated with objects that represent the organizations that provide the services. These organization objects can be classified as “Government” (such as the UK Met Office who provides weather data) or “Private” (such as airport authorities who define airspaces and related data).
As software engineers, we know that having a sound object model representing the domain space gets us half way to solving the problem. We already mentioned that objects can be associated (linked) to one another and that they can be classified (tagged). Other standard Registry features are logical collections of objects, internal and external attachments of text, video, audio, or any binary data to objects, object life-cycle-management, application-level audit trail, subscription to auditable events, and notification of these events to people and systems.
Mapping your business objects to Java objects is the easy part. Mapping Java objects to relational database tables can be complex. You still have to design the physical data model yourself because an object-relational-mapper such as Hibernate may not provide an optimal solution. Your object may need to be normalized into one or more tables. For every association between objects, a relational link table has to be defined, and the association’s cardinality will determine the type of link table to create. Your real world business model may require many classification schemes (taxonomies) and each scheme is a tree of classification nodes. Mapping a tree structure to relational database tables is not a trivial matter, but a Registry does this for you. Your application need only worry about assigning a classification node to your application object without concern about managing the forest of classification schemes.
Oftentimes, an application may want to collect a group of objects together from the result of a search. This collection may need to be persisted across a user session. The Registry allows the application to dynamically create and dissolve collections. Moreover, the Registry allows an object to freely exist in more than one collection.
Continuing with the collection example, when a collection is created the Registry can be configured to notify users or external software systems. These notifications can be in the form of email or SMS to users and HTTP messages to systems, and the notification mechanism is completely extensible by the user.
Flexibility for Change
Finally, businesses change over time and the object model that represents the business needs to reflect this change. The Registry can dynamically create new object types, create or remove properties in an existing object type, create or update classification schemes and nodes, and make or break associations between objects, all without the need to worry about data migration. The Registry can do this because it takes on the burden of mapping the application object model to a fixed ebRIM model and mapping that to a physical relational database schema.