Interoperability overview

OpenFin’s Interop API is the next generation of OpenFin’s interoperability capabilities across the financial desktop. It consists of two primary components: the Interop Broker and the Interop Client. These components comprise a hub and spoke model for sharing context.

Interop connects applications — called views — using context groups and intents. Each web view can be thought of as its own microservice, ready to be connected to serve a greater purpose. Interop gathers these views into a cohesive whole.

How it works

The Interop Broker is the key to Interop. The Interop Broker is responsible for keeping track of the Interop state of the platform, and for directing context messages to their proper locations.

The Interop Client participates by using an event handler to listen to context updates (addContextHandler), and speaks up when it has a context update to share (setContext). It also can participate by using an event handler to handle intents (registerIntentHandler), and by firing intents (fireIntent).

So what is a context, and what is an intent?

Context

At its most fundamental level, a context is a description of a thing. An instrument context, for example, is a description of a financial instrument such as a stock (TSLA, MSFT), stock option, or futures contract. Other contexts could be a country context that describes a country (United States, Japan), or a contact context that describes a person's contact information.

Apps receive context updates and perform an action based on that update. A new instrument context would cause a charting app to update a price history chart with the new instrument.

The list of FDC3 standard context types can be found here, though you are free to create your own contexts to use for your purposes.

Context group

A context group is a way to group views to share context information.

Context groups

There are two kinds of context groups, Context groups and Session context groups. The "green color code" context group is an example of a Context group.

In Workspace, grouping views by the green color code puts those views into the "green color code" context group. A new instrument context sent by one view in the "green color code" context group will be received by all members of the context group who request instrument context updates.

At any time, a user can tell the platform to add or remove an app from any Context group. Also, an app can only be in one Context group at a time.

Session context groups

The other context group is a Session context group. A Session context group is a context group created by an application to allow a set of applications to share context on a platform. A suite of apps from a single vendor could share context updates among their apps to give a cohesive presentation of data on, for example, a financial instrument in a country for an organization. Session context groups are quite similar to FDC3 App Channels.

An app joins a Session context group by calling the joinSessionContextGroup method with the name of the Session context group as a parameter.

Context update

A context update is an update in the form of a JSON string sent as a parameter to the callback registered by the addContextHandler function. The context update informs apps of a new context object being published in the context group. If the user changes the instrument from TSLA to MSFT, a context update will be sent to all apps that registered an interest in instrument context updates.

When an app joins a context group, the Interop Broker sends a series of context updates to the app’s context handler to give the new app all the current contexts the app requests from that context group, and all future context updates will be sent to the app’s context handler function. For example, an app that wants instrument and country contexts would receive two context updates to the app’s context handler function, one with the current instrument and one with the current country. Then any further instrument and country context updates will be sent to the app’s context handler function.

Context and FDC3

The context paradigm is based on the FDC3 schema. FDC3 provides a collection of standard types that have been identified in industry-wide working groups, and that collection of FDC3 contexts is expected to grow over time.

Contexts based on FDC3 standard contexts are compatible with OpenFin Interop. You are free to use FDC3 contexts that follow this simple schema in your own applications.

The list of FDC3 standard context types can be found here.

Intent

The "intent" concept is borrowed from the mobile phone development world. If you tap an address, a "get-directions" intent is fired which launches the map program to give the user directions to that address. Tap a phone number; call that number. Tap an email address; compose an email to that address.

In OpenFin, a similar process is used to fire and resolve intents. First, applications that resolve intents -- for instance, a "show-chart" intent -- register with the Interop Broker by using the addIntentListener function:

// register an intent
fin.me.interop.registerIntentHandler('show-chart', showChart);

When an app wants to show a chart, all the app needs to do is to fire the intent with the data payload of the stock ticker symbol to chart.

// dispatch an intent
fin.me.interop.fireIntent('show-chart', payload);

Views and platforms

Views are applications used by your users. A stock quote application is an example of a view.

Platforms coordinate and contain groups of application views into platform windows, and give a UI to the user to group together their views into context groups. OpenFin Workspace is an example of a platform.

Interop reduces the complexity of connecting views together by reducing what views and platforms need to care about.

To put it simply:

• Views only care about their context. They care about contexts sent to them and sent from them. They don’t care about what context group they’re in.

• Platform Windows only care about grouping views into context groups. They don’t care about what contexts those views are listening to.

So how straightforward is it to make a view or platform work with Interop?

The core Interop APIs for views

There are two core API functions that views use to participate in System context groups and Session context groups, and two core API functions for intents. Session context groups also add one additional API to create or join a Session context group.

That's it for views. Those functions are all you need. For context, the addContextHandler function specifies the function that will receive context messages from the context group, and the setContext function sends context messages to the context group. For Intents, registerIntentHandler announces the function to call to handle a fired intent, and fireIntent fires an intent and passes the relevant data to the intent handler.

The core APIs for platform contexts

Just like application developers, platform developers need to know only two primary APIs to handle contexts.

OpenFin Workspace is a platform that takes care of managing context groups and giving users a UI to group apps as they wish. If, however, you would prefer to create your own platform, you can use the Interop API to create your platform by using these core functions:

That's pretty much it. Yes, there are other APIs to manage other nuances of a platform, but these are the two primary APIs to know to get the job done. Use the getContextGroups function to get the list of context groups available, then use the joinContextGroup function to join an entity to the context group of choice.

The core APIs for platform intents

Just like contexts, platform developers need to know only two primary APIs to handle intents. There is, however, a bit more work to do behind the scenes to properly handle intents.

Here are the two core APIs for intents in platforms:

As a platform developer you only need to do two things to handle intents:

1. Override the handleFiredIntent function to launch a view and keep track of its identity.

2. Call the setIntentTarget function with that view’s identity to tell Interop Broker to give the intent to this view.

To explain this in a bit more detail:

1. Interop Broker receives the call from the view to fire an intent using the fireIntent function.

2. Interop Broker calls the InteropBroker.handleFiredIntent function.

   As a platform developer, you override the InteropBroker.handleFiredIntent function. In the handleFiredIntent function, you receive the intent from the app, and take action based on that intent.

   For example, if you receive an instrument and a ViewChart intent, your code can collect a list of apps that can respond to ViewChart intents.

3. Your handleFiredIntent` code will then select an app to view the chart. How you choose to do this is your choice. If you have only one chart viewing app, you might select just that app. If you have many apps that can view a chart, you might prompt the user to choose among the available apps which can view charts.

4. Your handleFiredIntent function then creates a view for the selected app, and keeps track of that view.

5. Through an override of the InteropBroker.setIntentTarget function, you will inform Interop Broker which view was launched to view the chart.

6. The new ViewChart view will call the registerIntentHandler function to register a listener function for receiving intents.

7. Interop Broker will then pass the intent to the ViewChart view’s listener function after the view is up and ready to receive intents.

Use case: Share Context between content in the same renderer process

App A shares context between Windows or Views from the same origin.

• Option 1: OpenFin: for ease of development
  → Views in Workspace — Interop API

• Option 2: Web standards: for portability to browsers
  → Broadcast Channel API

Use case: Share Context between content in across renderer processes or native applications (e.g. Java, .NET)

App A shares context with App B or between Windows or Views from a different origin.

• Views in Workspace: Interop API
• Anything else: Channels API

Use case: Send data from one app to another app across renderer processes

App A shares data to App B on a different renderer process.

• Channels API

Expose your own client-side API

App A exposes a bespoke API that other apps on the desktop consume and interact with.

• Channels API, plus Client Library

Use case: Fanning out low-latency data (e.g., real-time pricing) in the same origin

A data cache receives data from a server and multiple UIs update based on a data cache from the same origin.

• Web standards: object reference with Broadcast Channel API

Note: If using the same origin, but different renderers, there is no object reference.

Use case: Fanning out low-latency data (e.g. real-time pricing) from a different origin

A data cache receives data from a server and multiple UIs update based on data cache from different origins.

• Channels API

Note: Conflate data where possible in a webworker and have UIs pull updates on UI refresh frequency via a bespoke API (exposed via Channels API)

Use case: Move large data across process boundaries (e.g., video)

App A shares large data set to App B, Window or View across origins

• Channels API

Note: please consider performance in this case.

When not to use

• Straight-through processing
• When sending data from point A to point B is mission critical (e.g., guaranteed delivery: you should be using a server-based approach)
• Tick-level market data

Runtime version for each feature

Here are the initial runtime version numbers for each feature: