diff --git a/docs/api/DesktopAgent.md b/docs/api/DesktopAgent.md index e5824cb9f..ed0e091fc 100644 --- a/docs/api/DesktopAgent.md +++ b/docs/api/DesktopAgent.md @@ -15,7 +15,7 @@ A Desktop Agent can be connected to one or more App Directories and will use dir ### `open` ```typescript - open(name: string, context?: Context): Promise; +open(name: string, context?: Context): Promise; ``` Launches/links to an app by name. @@ -26,11 +26,11 @@ If opening errors, it returns an `Error` with a string from the [`OpenError`](Op #### Example ```javascript - //no context - await agent.open('myApp'); - - //with context - await agent.open('myApp', context); +//no context +await agent.open('myApp'); + +//with context +await agent.open('myApp', context); ``` #### See also @@ -54,24 +54,25 @@ This can be used to raise the intent against a specific app. #### Examples ```javascript - // I know 'StartChat' exists as a concept, and want to know more about it ... - const appIntent = await agent.findIntent("StartChat"); - // returns a single AppIntent: - // { - // intent: { name: "StartChat", displayName: "Chat" }, - // apps: [{ name: "Skype" }, { name: "Symphony" }, { name: "Slack" }] - // } - - // raise the intent against a particular app - await agent.raiseIntent(appIntent.intent.name, context, appIntent.apps[0].name); - ``` +// I know 'StartChat' exists as a concept, and want to know more about it ... +const appIntent = await agent.findIntent("StartChat"); +// returns a single AppIntent: +// { +// intent: { name: "StartChat", displayName: "Chat" }, +// apps: [{ name: "Skype" }, { name: "Symphony" }, { name: "Slack" }] +// } + +// raise the intent against a particular app +await agent.raiseIntent(appIntent.intent.name, context, appIntent.apps[0].name); +``` + #### See also * [`ResolveError`](Errors#ResolveError) ### `findIntentsByContext` ```typescript - findIntentsByContext(context: Context): Promise>; +findIntentsByContext(context: Context): Promise>; ``` Find all the avalable intents for a particular context. @@ -117,7 +118,7 @@ Publishes context to other apps on the desktop. #### Examples ```javascript - agent.broadcast(context); +agent.broadcast(context); ``` #### See also * [addContextListener](#addcontextlistener) @@ -125,7 +126,7 @@ Publishes context to other apps on the desktop. ### `raiseIntent` ```typescript - raiseIntent(intent: string, context: Context, target?: string): Promise; +raiseIntent(intent: string, context: Context, target?: string): Promise; ``` Raises an intent to the desktop agent to resolve. #### Examples @@ -140,7 +141,7 @@ agent.raiseIntent("StartChat", newContext, intentR.source); ### `addIntentListener` ```typescript - addIntentListener(intent: string, handler: (context: Context) => void): Listener; +addIntentListener(intent: string, handler: (context: Context) => void): Listener; ``` Adds a listener for incoming Intents from the Agent. #### See also @@ -149,7 +150,7 @@ agent.raiseIntent("StartChat", newContext, intentR.source); ### `addContextListener` ```typescript - addContextListener(handler: (context: Context) => void): Listener; +addContextListener(handler: (context: Context) => void): Listener; ``` Adds a listener for incoming context broadcast from the Desktop Agent. @@ -207,13 +208,13 @@ interface IntentResolution { IntentResolution provides a standard format for data returned upon resolving an intent. #### Example - ```javascript - //resolve a "Chain" type intent - var intentR = await agent.raiseIntent("intentName", context); - //resolve a "Client-Service" type intent with data response - var intentR = await agent.raiseIntent("intentName", context); - var dataR = intentR.data; - ``` +```javascript +//resolve a "Chain" type intent +var intentR = await agent.raiseIntent("intentName", context); +//resolve a "Client-Service" type intent with data response +var intentR = await agent.raiseIntent("intentName", context); +var dataR = intentR.data; +``` #### See also * [`DesktopAgent.raiseIntent`](#raiseintent) diff --git a/docs/api/api-intro.md b/docs/api/api-intro.md index eb194c5e0..461d48297 100644 --- a/docs/api/api-intro.md +++ b/docs/api/api-intro.md @@ -7,10 +7,10 @@ hide_title: true # API Overview FDC3 API standards support the following goals: -- Create consistent developer interface for working with FDC3 +- Create a consistent developer interface for working with FDC3 - Standardize interfaces for reference implementations - Standardize interfaces between Desktop Agents -The role of FDC3 API standards is to establish a baseline interface for interoperability between applications. Because FDC3 is largely an agreement between existing platforms and applications - standards should be optimized for ease of adoption rather than functional completeness. Functionality absent from a FDC3 specification is in no way commentary its importance. +The role of FDC3 API standards is to establish a baseline interface for interoperability between applications. Because FDC3 is largely an agreement between existing platforms and applications - standards should be optimized for ease of adoption rather than functional completeness. Functionality absent from a FDC3 specification is in no way a commentary its importance. -The focus on the API working group has been to create a small but consistent API, the following docs go through the components and API's in detail +The focus on the API working group has been to create a small but consistent API, the following docs go through the components and API's in detail. diff --git a/docs/appd-discovery.md b/docs/appd-discovery.md index d9ab567b1..023b7ae40 100644 --- a/docs/appd-discovery.md +++ b/docs/appd-discovery.md @@ -9,26 +9,26 @@ hide_title: true ## Simple Definition -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. +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. ## Topology -AppD services shall support 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. +AppD services shall support 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. ## Service Discovery Approach -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. +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. ### Application Identifier -- Application data discovery through nested namespace approach and email address construction (**name@fqdn**) defining the application identifier as the name part and AppD location as the fully qualified domain name part. The entire address should be considered the fully qualified application ID. +- Application data discovery through nested namespace approach and email address construction (**name@fqdn**) defining the application identifier as the name part and AppD location as the fully qualified domain name part. The entire address should be considered the fully qualified application ID. ### Resolving host system - AppD service host discovery implementations should support the following requirements; 1. Discovery of the AppD location using the fully qualified application ID domain name. This would be the fqdn part of the email structure. 2. Discovery of the AppD location using the fully qualified application ID domain name to lookup DNS SRV records identifying the host server location and access TCP port. ([RFC2782](https://tools.ietf.org/html/rfc2782) ) - 3. Statically defined URI records for use within client applications directly. This is similar to #1 above, but provides explicit protocol, port and url definitions as part of the defintion. + 3. Statically defined URI records for use within client applications directly. This is similar to #1 above, but provides explicit protocol, port and url definitions as part of the defintion. **Examples:** @@ -42,12 +42,11 @@ AppD Service distribution visual: ## Application data discovery -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 and email address construction (**name@fqdn**) defining the application identifier as the name part and AppD location as the fully qualified domain name part. The entire address should be considered the fully qualified application ID. +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 and email address construction (**name@fqdn**) defining the application identifier as the name part and AppD location as the fully qualified domain name part. The entire address should be considered the fully qualified application ID. **Example:** ``` - getAppData("app@sub.root") Application { @@ -89,50 +88,48 @@ getAppData("app@sub.root") } ] } - - ``` ## Service Discovery (Expanded) -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/app1@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. +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/app1@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. ### Application ID namespace syntax host resolution -An application directory URI can be constructed using a fully qualified application ID (email address syntax) by using fqdn part of the ID as the host location and the name part as the application name. Given an application name "app1" with a fully qualified identifier of "app1@appd.foo.com" an application directory host location can be derived by simply extracting the fqdn "appd.foo.com" from the email syntax. The extracted fqdn "app.foo.com" may resolve to the actual host location where the application directory is running. +An application directory URI can be constructed using a fully qualified application ID (email address syntax) by using fqdn part of the ID as the host location and the name part as the application name. Given an application name "app1" with a fully qualified identifier of "app1@appd.foo.com" an application directory host location can be derived by simply extracting the fqdn "appd.foo.com" from the email syntax. The extracted fqdn "app.foo.com" may resolve to the actual host location where the application directory is running. A launcher can then easily construct a URI by; 1. URI protocol is defaulted to https, but can be overridden by the launcher. 2. URI hostname is the fully qualified domain of the application ID. 3. URI port is default https/443, but can be overridden by the launcher -4. URI url is by default "/api/**(service)/(version)" .** It is recommended that we identify service label as "**appd**" with version being optional. Calls that are made without version automatically default to latest "/api/appd/app1" vs "/api/appd/v1/app1" +4. URI url is by default "/api/**(service)/(version)" .** It is recommended that we identify service label as "**appd**" with version being optional. Calls that are made without version automatically default to latest "/api/appd/app1" vs "/api/appd/v1/app1" The resulting URI to retrieve application data for "app1" would be "[https://appd.foo.com/api/appd/v1/app1@appd.foo.com](https://appd.foo.com/api/appd/v1/app1.appd.foo.com)" ### Application identifiers, Shrinking the URI and AppdD defaults -Although the concept of fully qualified application IDs are useful in resolving the actual host of the application directory, there is no requirement for an application directory to use this fully qualified application ID as the resolver for a record. An application ID is unique to given application directory, but there is no requirement to use the fully qualified representation when querying an interface. Taking the prior example, the fully qualified application ID "app1@appd.foo.com" is represented as "app1" within the application directory. As a result a launcher can use a shortened URI construct "" to resolve the application data vs "https://appd.foo.com/api/appd/app1@appd.foo.com". +Although the concept of fully qualified application IDs are useful in resolving the actual host of the application directory, there is no requirement for an application directory to use this fully qualified application ID as the resolver for a record. An application ID is unique to given application directory, but there is no requirement to use the fully qualified representation when querying an interface. Taking the prior example, the fully qualified application ID "app1@appd.foo.com" is represented as "app1" within the application directory. As a result a launcher can use a shortened URI construct "" to resolve the application data vs "https://appd.foo.com/api/appd/app1@appd.foo.com". ### DNS/SRV Records -Another approach to support AppD service discovery (resolution) is through use of existing domain name service (DNS) implementations that are broadly used on the Internet today (see: [RFCs](https://www.isc.org/community/rfcs/dns/)). Name service implementations can be considered critical infrastructure and are proven stable with over twenty years of use. Name services can be used both through public Internet or locally deployed intranet, which provides optionality to deployment schemes. +Another approach to support AppD service discovery (resolution) is through use of existing domain name service (DNS) implementations that are broadly used on the Internet today (see: [RFCs](https://www.isc.org/community/rfcs/dns/)). Name service implementations can be considered critical infrastructure and are proven stable with over twenty years of use. Name services can be used both through public Internet or locally deployed intranet, which provides optionality to deployment schemes. -More specifically, resolution of an AppD service instance (host location) can be implemented using DNS "service records" (SRV) providing the host instance, protocol and associated port. The following is a well known description of a SRV record ([RFC2782](https://tools.ietf.org/html/rfc2782)): +More specifically, resolution of an AppD service instance (host location) can be implemented using DNS "service records" (SRV) providing the host instance, protocol and associated port. The following is a well known description of a SRV record ([RFC2782](https://tools.ietf.org/html/rfc2782)): ``` - zone name { _service._proto.name. TTL class SRV priority weight port target.} +zone name { _service._proto.name. TTL class SRV priority weight port target.} ``` -- *service*: the symbolic name of the desired service. For AppD service, this mus be identified as "**_appd**" -- *proto*: the transport protocol of the desired service; this is usually either [TCP](https://en.wikipedia.org/wiki/Transmission_Control_Protocol) or [UDP](https://en.wikipedia.org/wiki/User_Datagram_Protocol). For AppD service **_tcp** must be used. -- *name*: the domain name for which this record is valid, ending in a dot. For AppD service, the name should directly map to the application identifier domain. +- *service*: the symbolic name of the desired service. For AppD service, this mus be identified as "**_appd**" +- *proto*: the transport protocol of the desired service; this is usually either [TCP](https://en.wikipedia.org/wiki/Transmission_Control_Protocol) or [UDP](https://en.wikipedia.org/wiki/User_Datagram_Protocol). For AppD service **_tcp** must be used. +- *name*: the domain name for which this record is valid, ending in a dot. For AppD service, the name should directly map to the application identifier domain. - *TTL*: standard DNS [time to live](https://en.wikipedia.org/wiki/Time_to_live) field. - *class*: standard DNS class field (this is always *IN*). - *priority*: the priority of the target host, lower value means more preferred. - *weight*: A relative weight for records with the same priority, higher value means more preferred. - *port*: the TCP or UDP port on which the service is to be found. For AppD service, TCP should always be used. -- *target*: the canonical hostname of the machine providing the service, ending in a dot. This would be the host where the AppD service is running. +- *target*: the canonical hostname of the machine providing the service, ending in a dot. This would be the host where the AppD service is running. For AppD Service the SRV record **must use** the following definitions: @@ -142,10 +139,10 @@ For AppD Service the SRV record **must use** the following definitions: **Known domains:** -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. +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. ### Static configuration -As the name implies, a static configuration for the AppD service location is predefined within the launcher following the same domain:URI model mentioned in previous sections. +As the name implies, a static configuration for the AppD service location is predefined within the launcher following the same domain:URI model mentioned in previous sections. ![img](https://finosfoundation.atlassian.net/wiki/download/thumbnails/129597550/StaticConfig.png?version=1&modificationDate=1526330937517&cacheVersion=1&api=v2&width=800&height=376) \ No newline at end of file diff --git a/docs/appd-intro.md b/docs/appd-intro.md index b25c4be0f..b4ab2d417 100644 --- a/docs/appd-intro.md +++ b/docs/appd-intro.md @@ -21,4 +21,4 @@ The FDC3 App Directory provides trusted identity for financial desktop apps. Thi - [Application Directory Use](appd-use.md) provides a simple view on how application directories can be used. This also includes links to a reference implementation. - [API specification](appd-spec.md) is the interface definition required to support a compatible application directory. -The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC 2119](https://tools.ietf.org/id/draft-faltstrom-uri-11.html#RFC2119) [RFC2119]. \ No newline at end of file +The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14, [RFC 2119](https://tools.ietf.org/id/draft-faltstrom-uri-11.html#RFC2119) [RFC2119]. \ No newline at end of file diff --git a/docs/appd-use.md b/docs/appd-use.md index 79380bb14..f2d57799d 100644 --- a/docs/appd-use.md +++ b/docs/appd-use.md @@ -7,92 +7,91 @@ hide_title: true # App Directory Use -An application directory (AppD) provides information about an applications +An application directory (AppD) provides information about an application's identifiers, intents that provide contexts, and location of metadata providing information specific to the launching and integration of the application. - In the real world the AppD would support many use cases as defined in the [FDC3 Use Cases](use-cases/use-cases-intro) The following provides some common use cases and benefits. -## Embedded Launcher ### +## Embedded Launcher A desktop application has the ability to launch (or initialize) an application by retrieving all necessary data via a REST call(s) to an AppD service and metadata location. As described in the [AppD Discovery](/AppD_Discovery) section, this call requires an application identifier (app1@host.appd.com), which can be used to both locate the AppD service and key to retrieve the -specific application data. The resulting application data will contain -data describing the application and the metadata URI or the actual -metadata in json format. If the metadata is a URI, the launcher would +specific application data. The resulting application data will describe the +application and the metadata URI or the actual +metadata in JSON format. If the metadata is a URI, the launcher would retrieve the metadata file from the URI. ![img](assets/appd_launcher_embedded.png) -## Standalone Launcher ### +## Standalone Launcher In more advanced cases, there could be a need to execute different types of desktop applications, such as web browser or general native application -(exe, binary). A common approach to support this pattern would be to - create a standalone launcher application that has the ability to query - application data from the AppD and executes the desktop application that - can run the required application. This is also convenient if you wanted - to display all possible applications to launch in a single view. +(exe, binary). A common approach to support this pattern would be to +create a standalone launcher application that has the ability to query +application data from the AppD and executes the desktop application that +can run the required application. This is also convenient if you wanted +to display all possible applications to launch in a single view. ![img](assets/appd_launcher_standalone.png) -## Aggregated View ### +## Aggregated View There could be many different AppD service instances in the world providing -application data zoned to the provider or enterprise deployment. The +application data zoned to the provider or enterprise deployment. The AppD specification allows for unique instances of the service with no -requirement to aggregate data or define a structured hierarchy. With this +requirement to aggregate data or define a structured hierarchy. With this said, a launcher might want to construct an aggregated view of applications -from one or more AppD instances. In this case, the launcher would be +from one or more AppD instances. In this case, the launcher would be required to retrieve multiple application definitions from one or more AppD instances providing a consolidated view of all applications required. - Today there is no intention to create a single registry of known AppD - instances, so there is an assumption that the launcher will have prior - knowledge of the AppD instance location (FQDN). +Today there is no intention to create a single registry of known AppD +instances, so there is an assumption that the launcher will have prior +knowledge of the AppD instance location (FQDN). ![img](assets/appd_launcher_aggregated.png) -## Enhancing controls ### +## Enhancing controls The AppD API specification defines the optional use of an access token to identify the requesting user/launcher and implement authorizations around -AppD actions can be performed. Actions are considered standard CRUD operations. +AppD actions can be performed. Actions are considered standard CRUD operations. Again the specification does not define or make mandatory any authorizations or roles that a provider or enterprise can define. With this said, it is highly recommended that the implementation take advantage - and utilize an access token to support these controls. In most cases simple - use of roles like "admin" and "user" would be adequate to create separation - between producer and consumer. +and utilize an access token to support these controls. In most cases simple +use of roles like "admin" and "user" would be adequate to create separation +between producer and consumer. - Alternatively a more open approach can be defined, where producers of a new - definition are automatically set to "owner" of the the definition. +Alternatively a more open approach can be defined, where producers of a new +definition are automatically set to "owner" of the the definition. - In more advanced use cases, actual entitlements can be applied to limit - access to specific applications and associated actions based on the source - user/launcher identity. +In more advanced use cases, actual entitlements can be applied to limit +access to specific applications and associated actions based on the source +user/launcher identity. - In all examples, it is up to the implementation to define and engineer the solution - based on individual requirements. There are too many variations in approach - and technology to define a single specification. +In all examples, it is up to the implementation to define and engineer the solution +based on individual requirements. There are too many variations in approach +and technology to define a single specification. -## Reference Implementation ### +## Reference Implementation -### AppD POC #### +### AppD POC Please view readme on the [AppD POC GitHub](https://github.com/FDC3/appd-poc) . -### Launcher #### +### Launcher TBD \ No newline at end of file diff --git a/docs/context-intro.md b/docs/context-intro.md index 20145cf6d..f6c18571c 100644 --- a/docs/context-intro.md +++ b/docs/context-intro.md @@ -6,16 +6,16 @@ hide_title: true --- # Context Data Overview -Extending APIs from one application to another is powerful. However, it requires bi-lateral agreements where implementors build to proprietary APIs. A standard language for interaction between applications allows us to create workflows on the fly, so that applications can discover and link to another without any prior knowledge. +Extending APIs from one application to another is powerful. However, it requires bi-lateral agreements where implementors build to proprietary APIs. A standard language for interaction between applications allows us to create workflows on the fly, so that applications can discover and link to one another without any prior knowledge. -FDC3 Context Data defines a standard way to pass common identifiers and data between apps to create a seamless workflow. FDC3 Context Data is not a symbology solution and is not specifically focused on modeling financial objects. The focus is on providing a standard payload structure that can be used to establish a lowest common denominator for interoperability. +FDC3 Context Data defines a standard for passing common identifiers and data between apps to create a seamless workflow. FDC3 Context Data is not a symbology solution and is not specifically focused on modeling financial objects. The focus is on providing a standard payload structure that can be used to establish a lowest common denominator for interoperability. Context objects are used when raising [Intents](intents-intro) and when broadcasting context to other applications. ## Context Object Context can be summarised as: -* Having a unique _type_ identifier, used for routing. +* Having a unique 6. **Guidance in the use of these Imperatives** > @@ -20,13 +20,12 @@ In general, the ratified FDC3 specs represent a lowest common denominator interf > on implementors where the method is not required for > interoperability. -These rules would apply only to standards work within FDC3. Today, this covers API, App Directory, Context Data, and Intents working groups, it does not apply to the Use Cases working group. +These rules would apply only to standards work within FDC3. Today, this covers API, App Directory, Context Data, and Intents working groups, it does not apply to the Use Cases working group. ## Personas: -FDC3 implementors generally fall into 2 categories: platform providers, and application providers. -A platform provider provides an implementation of the FDC3 API for applications to use. Implicitly, it connects to one or more App Directories. +FDC3 implementors generally fall into 2 categories: platform providers, and application providers. A platform provider supplies an implementation of the FDC3 API for applications to use. Implicitly, it connects to one or more App Directories. -An application provider is largely a downstream consumer of FDC3 standards. It MAY use the API, it MAY use Context Data, it MAY use Intents. Application providers are only required to comply with the standards they make use of. +An application provider is largely a downstream consumer of FDC3 standards. It MAY use the API, it MAY use Context Data, it MAY use Intents. Application providers are only required to comply with the standards they make use of. Depending on persona, implementation compliance with FDC3 will mean different things. @@ -34,8 +33,8 @@ Depending on persona, implementation compliance with FDC3 will mean different th To meet the requirements of FDC3, a platform provider would need to support the following: * Connection to 1 or more App Directories meeting the FDC3 App Directory standards -* Providing an API to all applications running in the context of the platform that meets the FDC3 API standards, including: - * Support of FDC3 Context Data and Intents standards +* Provide an API to all applications running in the context of the platform that meets the FDC3 API standards, including: + * Support for FDC3 Context Data and Intents standards * Support for Intent and Context resolution using a resolver UI * At least one workflow of one of the use cases marked as Accepted by the Use Cases working group SHOULD be satisfied by the implementation. diff --git a/docs/fdc3-intro.md b/docs/fdc3-intro.md index 2be247317..c5f4b3b03 100644 --- a/docs/fdc3-intro.md +++ b/docs/fdc3-intro.md @@ -5,8 +5,8 @@ sidebar_label: Introduction --- ![FDC3](assets/fdc3-logo.png) -The mission of FDC3 is to develop specific protocols and taxonomies to advance the ability of desktop applications in financial workflows to interoperate in a plug-and-play fashion and without prior, bi-lateral agreements. [Read the Charter](fdc3-charter.md). +The mission of FDC3 is to develop specific protocols and taxonomies to advance the ability of desktop applications in financial workflows to interoperate in a plug-and-play fashion, without prior bi-lateral agreements. [Read the Charter](fdc3-charter.md). -The FDC3 was launched in October 2017 by OpenFin in collaboration with major industry participants. FDC3 includes representatives from over 40 major banks, buy-side firms and financial services platforms. The FDC3 uses the Apache 2.0 open source license for all deliverables. +FDC3 was launched in October 2017 by OpenFin in collaboration with major industry participants. It includes representatives from over 40 major banks, buy-side firms, consultancies and financial services platforms. FDC3 uses the Apache 2.0 open source license for all deliverables. FDC3 is hosted within, and governed by the policies of, the [Fintech Open Source Foundation](http://finos.org/) (FINOS). FINOS is an independent nonprofit organization focused on promoting open innovation within financial services. \ No newline at end of file diff --git a/docs/why-fdc3.md b/docs/why-fdc3.md index e7c27e005..55203e7b6 100644 --- a/docs/why-fdc3.md +++ b/docs/why-fdc3.md @@ -6,21 +6,18 @@ title: Why FDC3 ## Why look for FDC3 enabled applications? -You want to for your business to move fast and use best of breed applications. -Application integration has traditionally been a timely and costly exercise, meaning that once a set of applications supporting a workflow was established, changing parts of the workflow without very good reason was a no-go. -The man goal of FDC3 is standardise how applications can communicate, without having defined inter-application workflows prior to being deployed. -Applications that are FDC3 enabled can take part in a workflow on the desktop without any coding or manual integration, allowing you to replace one application with another application serving the same functions to the desktop (in FDC3 terms - supporting the same Intents and Context) +You want your business to move fast and use best of breed applications. Application integration has traditionally been a time consuming and costly exercise, meaning that once a set of applications supporting a workflow was established, changing parts of the workflow without very good reason was a no-go. The main goal of FDC3 is to standardize how applications communicate, without having defined inter-application workflows prior to being deployed. Applications that are FDC3 enabled can take part in a workflow on the desktop without any coding or manual integration, allowing you to replace one application with another application serving the same functions to the desktop (in FDC3 terms - supporting the same Intents and Context) [Link to list of FDC3 enabled apps/platforms](apps-and-platforms) ## Why should I FDC3-enable my applications? -The trend is towards breaking up monolithic desktop applications and building effective adaptible wokflows using best-of-breed applications. Still much of the integration on the desktop is done by the actual end-user; copy/paste between applications, exporting/importing csv files etc. Every application that have manual user input is a candidate for being FDC3 enabled, being able to demonstrate that your application can effectively take part in a worklow (without manual dual-entry or other tedious operations)is a quick way to gain more happy customers. Allowing your application to reach out to other applications is another way of extending the power of your application offering; your app might not offer charting, but can let the end-user effectively chart in an FDC3 enabled companion application based on context passed from your application. +There is a trend towards breaking up monolithic desktop applications, replacing them with adaptible wokflows which involve teh collaboration of multiple best-of-breed applications. Still much of the integration on the desktop is done by the actual end-user; copy/paste between applications, exporting/importing CSV files etc. Every application that has manual user input is a candidate for being FDC3-enabled, being able to demonstrate that your application can effectively take part in a worklow (without manual dual-entry or other tedious operations) is a easy route to happier users. Allowing your application to reach out to others is another way of extending the power of your offering; your app might not offer charting, but can let the end-user chart in an FDC3 enabled companion application based on context passed from your own app. [Link to list of FDC3 enabled apps/platforms](apps-and-platforms) -## Why should my development team look at adapting FDC3? +## Why should my development team look at adopting FDC3? -Deploying effective end-user workflows with as little development effort as possible, should be the goal for all internal/platform integration development teams. Implementing or developing an a platform that is FDC3 enabled, will if done right, result in more bang for the buck: FDC3 is all about (re)usability and low-touch integration, with an [App directory](appd-intro) in place and a platform to develop on, each new enabled app broadens the value of the workflow offering. +Deploying effective end-user workflows with as little development effort as possible, should be the goal for all internal/platform integration development teams. Implementing or developing on a platform that is FDC3 enabled, if done right, results in more bang for the buck. FDC3 is all about (re)usability and low-touch integration, with an [App directory](appd-intro) in place and a platform to develop on, each new enabled app broadens the value of the workflow offering. [Link to list of FDC3 (real) use cases](real-world-use-cases) \ No newline at end of file