We use proprietary and third party's cookies to improve your experience and our services, identifying your Internet Browsing preferences on our website; develop analytic activities and display advertising based on your preferences. If you keep browsing, you accept its use. You can get more information on our Cookie Policy
Cookies Policy
FIWARE.ArchitectureDescription.Apps.Registry - FIWARE Forge Wiki


From FIWARE Forge Wiki

Jump to: navigation, search



  • Copyright © 2014 by SAP

Legal Notice

Please check the following FI-WARE Open Specification Legal Notice (essential patents license) to understand the rights to use this open specification. As all other FI-WARE members, SAP has chosen one of the two FI-WARE license schemes for open specifications.

To illustrate this open specification license from our SAP perspective:

  • SAP provides the specifications of this Generic Enabler available under IPR rules that allow for a exploitation and sustainable usage both in Open Source as well as proprietary, closed source products to maximize adoption.
  • This Open Specification is exploitable for proprietary 3rd party products and is exploitable for open source 3rd party products, including open source licenses that require patent pledges.
  • If the owner (SAP) of this GE spec holds a patent that is essential to create a conforming implementation of the GE spec (i.e. it is impossible to write a conforming implementation without violating the patent) then a license to that patent is deemed granted to the implementation.

Note: SAP provides the software associated to the Registry - RI as open source under the BSD License. Please check the specific terms and conditions linked to this BSD open source license at https://github.com/service-business-framework/Registry-RI/blob/master/license.txt. You can also obtain the Registry GE software using the FI-WARE Catalogue at http://catalogue.fi-ware.org/enablers/registry-sap-ri


While the Repository Enabler is used to store complete service descriptions, which are more or less static and change only rarely, the Registry Enabler is used to store information on service instances necessary for run-time execution. Discovering entities and their description in an open distributed system often is achieved via registries, which have a well-known address. The registry serves as a kind of directory and for example can store detailed settings for concrete infrastructure components as well as information about human or computing agents. The information can range from stable to extremely volatile and is needed to make specific settings for and adjustments to other components in the platform. For example, the Registry can be used by the Marketplace in order to register stores, providers, persons, infrastructure components and more. The functionality and purpose of the Registry GE is comparable to the Microsoft Windows Registry [ REG3 ] or the Light-weight Directory Access Protocol LDAP [ REG1 ] or the UDDI Business Registry [ REG4 ]. The main difference is that the Registry GE is fully relying on standard Web protocols and has a simpler data model.

Target usage

The Registry acts as a universal directory of information used for the maintenance, administration, deployment and retrieval of services. Existing (running) service endpoints as well as information to create an actual service instance and endpoint are registered. This GE will be used by potentially all GE in the Apps Chapter in order to build a common database of run-time configuration options and properties. It can also be used by GE of other chapters, such as the Cloud, Security, Data or IoT to announce their instance specific information to the rest of the platform components. In a FI-WARE instance there could be multiple instances of the Registry for different purposes and usage domains, which are accessed uniformly according the Repository RESTful interface specification.


The Registry has specific requirements according to scalability and performance. Highly volatile information about runtime aspects are to be handled with quick response times. On the other hand, the number of clients and the amount of data is usually small.


Registries are quite a common pattern in software architectures. With in the internet protocol stack defined by the IETF RFC, LDAP (Light-weight Directory Access Protocol) [ REG1 ] is a common technical realization of the registry functionality. Other examples of registry implementations are UDDI [ REG4 ]and the Windows Registry database [ REG3 ].

Basic Concepts

Register and Deregister Entries

This function is used by resource providers to register and deregister their resources as entries in the Registry. This information can be used by other components in the FI-WARE instance. E.g. the Application Mashup component can use the Registry to find out Marketplaces and their respective endpoint information.

Retrieving Registry Entries

The Retrieving Registry Entries component is responsible for read access of entries. A client service can ask for specific settings and options of the operating environment. The retrieval is either controlled by giving the entry key, which identifies the entry in a unique way. Or the retrieval is based on a filter expression, which is referring to concrete entry values. In this case a list of matching entries is returned. Using a selector expression, the user can limit the number of property values to be returned.

Data Model

The basic data elements of the registry are the Registry Entry containing the actual information and the Registry Key to access the data entries in the Registry. A registry entry can be a single atomic piece of data or a structured data such as a record of named properties (name/value pairs). The exact data model and its encoding will be defined in the interface specification. The schema (the exact names of properties and their value encoding) is the matter of the application developer or the community of developers in a respective application domain.

The Registry Key is used for accessing individual entries or a collection of entries is often organized as path into an underlying registry internal organization such as a tree.

Registry Architecture

The Registry is a searchable index of the Repository GE. The following picture shows the schematic architecture of the Repository GE. A protocol handler is responsible for the realization of the RESTful HTTP protocol. Content negotiation is used to deliver the results of the operations in different formats convenient for various client environments. An access control adapter is responsible to check access rights according to the FI-WARE Identity Management & Access Control Enabler. The dispatcher calls different handlers for the registry functions. The registry entries and index is stored in a registry database. The registry handlers can call remote registries if the registry is distributed over multiple servers.


File:registry-architecture.png|thumb|600px|center|Registry architecture (schematic)]]

Main Interactions

The following diagram shows an example sequence how a user or other GEs can register, retrieve, and deregister a registry entry.

Example sequence of Registry operations

Register and Deregister Entries

The Register Entry operation is used to write or update a register information entry into the Registry. Two parameters are essentially needed:

  • key - The Registry Key of the entry to be registered. A key can exhibit an organizational structure such as a tree. The Registry Key is usually given by the client and is chosen according to a published naming scheme.
  • entry - The Register Entry to be registered. The entry is usually a list of name/value pairs.

A registry key is returned.

For the Deregister Entry operation only the Registry Key of the Registry Entry is needed:

  • key - Registry Key of the entry to be de-registered

Retrieving Registry Entries

It must be possible to directly retrieve a Registry Entry using a unique Key using the Get Registry Entry operation. In this case one parameter is sufficient:

  • key - Registry Key of the entry to be retrieved

The Query Registry Entries operation allows the retrieval of Registry Entries matching a filter expression:

  • filter - A filter expression to select entries to be retrieved.

Basic Design Principles

An implementation for the Registry might take different design decisions and technological approaches, depending on the non-functional requirements of the repository. A registry implementation might be highly distributed and scalable if it is used by many parties on a global scale. Also the database schema might be of different complexity depending on the data requirements of the use case. Prominent example technologies which have a distributed nature are LDAP, UDDI, or distributed key/value stores for large amounts of records such as MongoDB, CouchDB, or Cassandra. The Registry specification follows the separation of concerns principle. So it is possible to supplement it with an authentication and authorization system such as OAuth [ REG2 ].

Detailed Open Specifications

Open API Specifications


REG1 LDAP protocol specifications(RFCs 4510,4512,4514,4516,4517)
REG2 OAuth2 protocol (http://tools.ietf.org/html/draft-ietf-oauth-v2-30)
REG3 Microsoft Windows Registry (http://msdn.microsoft.com/msdnmag/issues/1100/Registry/)
REG4 UDDI Business Registry (http://en.wikipedia.org/wiki/Universal_Description_Discovery_and_Integration)
Personal tools
Create a book