DRAFT- InProgress

 Abstract

Commentary:

The  App Directory (AppD) is a service that provides a financial application definition that includes a trusted identifier(s) and associated metadata.  The information registered as part of an application definition supports discovery, launch configuration, intents and context data supporting the use and interoperability of financial applications.  This proposal recommends use of a distributed or detached model to managing application data servicing, where there are (N) AppD services on a network providing information related to a subset of namespace "zones" that align with the financial application identifiers.  This approach encourages independence, scale and responsive provisioning of application definitions. This is modeled from a subset of the public name service "Domain Name System", which has proven reliable and conceptually fit for discovery.

In order to support the discovery of application data stored in a given directory, name space concepts are introduced to both identify the realm of application definitions and AppD service locations that host data.  In simple terms, there has to be a way of discovering the location of the AppD service itself and the associated application definitions that are available from that service.  

This proposal focuses on defining the following key features to support this need:

• Application data discovery through nested namespace approach. (Note: An expanded definition is required outside this proposal)
• AppD service host discovery implementations should support the following requirements;
  1. Discovery through application ID namespace syntax host name resolution 
  2. Discovery through use of DNS SRV record types (RFC2782 ) 
  3. Federated discovery of URI records between AppD services
  4. Statically defined URI records for use within client applications directly

...

For the purposes of this proposal, application data discovery shall be accessible through a unique application identifier (AppId) representing a single application represented by a nested namespace syntax using dot notation (e.g. appapp@sub.sub.root).  It should be noted that a given AppD service may support multiple application namespace "zones" as part of a standard nested naming hierarchy. 

...

The following represents the three ways AppD service instances should be discovered over a given network.  Again, the view is that AppD services are distributed/decoupled based on associated application namespace on a given network.  This takes into account the use of the application identifiers described in previous section.  A launcher is required to use a URI (e.g. "https://appd.foo.com/api/appd/app1app1@appd.appd.foo.com") to query a given directory instance for data.  In order to construct a URI, the host location and port of a given AppD service instance is required.  This proposal focuses on the following approaches to achieve this resolution. 

...

Although SRV records provide the means of resolving the location of an AppD service for a specific domain, there could be a need to know what domains exist in the universe.  This would be a list of domains representing all known directory instances. It is recommended that  the FDC3/FINOS organization publish a list of known domains which support AppD services.  This publication can be handled in multiple ways, such as structured files or API endpoints.  This proposal shall not provide a qualified solution to achieve this, but rather draw attention to a potential requirement.  

Peer-to-Peer Discovery

This type of discovery focuses on the replication of known domain:URI records between AppD services.   A domain:URI records consist of the application identifier or domain and the associated URI (e.g. appd.foo.com : https://appd.foo.com).  This follows the concept of peer-to-peer replication, whereby the following concepts must be supported by a given AppD service must:

1. have one or more peers seeded manually or through centralized source (see above section on Known domains)
2. store AppD service locations as domain:URI record types
3. publish managed (owned) domain:URI records on startup to peers
4. have an accessible endpoint providing list of known domain:URI  
5. on startup, retrieve a list of known domain:URIs from peer(s) 
6. have an accessible endpoint to receive published events from other AppD services. 
7. compare received events/records to known records with any differences triggering record updates to peers.
8. Must verify and refresh discovered domain:URI records

The requirements force almost a complete replication and active refresh of records across a peer-to-peer instances, but increases the development requirements and network traffic. 

Image Removed

Static configuration

...