Tuesday, August 18, 2015

F2 Registry - Organizing and Connecting Containers and Apps

Critical to the success of F2 is the creation and adoption of a specification that allows F2 Apps to be catalogued for the purpose of inventory management. This specification, called the “F2 Registry,” would be compatible with both the F2 Container and F2 App specifications, and would provide a means for Registries created and maintained by individual firms to communicate with one another.

The Problem

In building an F2 Container or set of F2 Apps, a developer and a product owner will quickly encounter a need to manage a listing of those Apps. A listing is necessary in order to avoid duplication of Apps, encourage reuse of Apps, and provide a mechanism to discover Apps within a firm or to the public at large.

For a developer, such a listing could be as simple as a JSON list of App manifests inside of a Container or collection of Apps. For a product owner, it would require a user interface built on top of that JSON list, providing a visual catalog of Apps, their descriptions, data sources, and more.

Consider, however, that a Container owner might need Apps from multiple App providers, and that App providers need to supply Apps to many Container owners. In that scenario, each Container owner would need a Registry of their Apps (a "storefront"), and each App provider might need a Registry of all of the Apps they have available (a "warehouse").

At the same time, Container owners and App providers have different needs. App providers want to make new Apps available in their Registry; potentially create both public and private spaces; and provide entitlement controls. Container owners want controls over which Apps are released to their production environments as well as which are made available via internal App registries. Container owners have varying degrees of compliance review and release schedules; App providers have a vested interest in getting their Apps out as quickly as possible, and need to comply with policies of the various Containers to which they supply Apps. Not only do Container owners and App providers have different perspectives on App review, privacy, availability, discovery, and security; individual Container owners have different perspectives from one another on these same issues, as do individual App providers.

A single Registry for a Container or App collection is too constrained to address these solution differences. Therefore, if multiple financial data providers want to provide Apps to a single Container owner (or multiple Container owners), a broader, networked registry of those Apps is needed.

In exploring this problem with the F2 Advisory Board, we determined that the problem as it exists within F2 is different from the problem addressed by Apple’s App Store or Google’s Play Store, each of which provides a centralized repository of Apps with differing standards of quality control and approval. The financial services industry has a need to maintain multiple registries of variant privacy -- some private, some public, and some that communicate with one another.

The Solution

F2 recommends a networked App Registry model wherein each participant in the F2 ecosystem hosts and maintains its own individual App Registry. These various App Registries will be configured to allow for interoperability, communication, and synchronization. This approach has several benefits:

  • Allows any Container owner, App provider, or App Registry provider to maintain their own rules and controls around App privacy, App review cycles, entitlements, pricing, whether they provide Apps via a storefront, etc.
  • F2 provides common denominator items such as App title, App manifest, and App provider to ensure consistency
  • New entrants, whether Container owners, App providers, or App Registry providers can participate in the F2 ecosystem with minimal technical friction, aligning with F2’s goal of “the best App wins”
  • In the below example, F2 Registries are labelled as “App Marketplace” and “App Warehouse” respectively, demonstrating the differing needs of Container owners and App Providers.
Screen Shot 2014-09-16 at 4.25.50 PM.png

To support this model, F2 proposes the following:

  • Creation of an F2 project under which F2 Registry will be created and will solicit contributions from the open source community
  • Creation of an F2 specification for App Registry
    • Definition of inputs and outputs for RESTful JSON APIs
    • APIs would be built & hosted by App Registry Providers adhering to spec
  • F2 Specification additions on how F2 Apps can exist in any App Registry
  • Specification on how an F2 Container can connect to an App Registry
  • Documentation on how an F2 App can be submitted into and managed within an App Registry
  • Documentation and specification on how App Registries synchronize with one another
  • Reference examples of how an F2 App Registry can maintain a list of apps from multiple providers, connect to multiple containers, and connect to other registries

Proposed Future Enhancements

The Advisory Board has further identified a number of additional enhancements to the F2 spec, outside of the immediate scope of the F2 Registry, but necessary for the long-term success of the F2 initiative:

  • Single Sign On (SSO)
  • Identity - symbology, users, and entities
  • Entitlements - first phase with “trusted partners” (i.e., no official entitlements)


The following items are not a part of F2’s Registry specification, roadmap or plans:

  • Hosted services (API spec/definition only)
  • Hosted App store