Finsemble: Architectural Overview

Architectural Overview

This overview provides details on how a Finsemble application is composed.

As a starting point, consider four Finsemble windows on a monitor: a stock-chart and three chat windows. For this example, these four windows make up a Finsemble application.

A corresponding representation of these windows is shown below: a set of HTML5 windows connected through underlying microservices. By connecting and coordinating with Finsemble microservices, the windows form a Finsemble application.

A microservice in Finsemble is an independently-threaded JavaScript module providing centralized functionality throughout a Finsemble application. Microservices provide capabilities to Finsemble windows. Similar to cloud microservices, these microservices typically don't have a UI. A microservice can be interacted with using a corresponding client API.

Each window is a Chromium container sitting on top of OpenFin's secure operating layer. These windows are called Finsemble components. The window's JavaScript accesses the underlying Finsemble Library. The Finsemble Library (FSBL.js) is a set of client APIs connecting to the microservices.

Below is a complete architectural breakdown of a Finsemble application: a set of cooperating Finsemble components and microservices. All components access the microservices though the client APIs contained in the Finsemble Library. All communication between windows and microservices takes place through the Finsemble Event Router, which is itself a microservice.

The core of Finsemble is packaged as a NPM module to simplify updates. The most common scenario for Finsemble users (i.e., developers) is to build new components on top of the core module. Developers can connect their components, our prebuilt components, and third-party components to the Finsemble core to form a single application. For advanced users, Finsemble also supports adding new microservices and corresponding client APIs. The aim is full extensibility though new components, services, and client APIs.

As mentioned earlier, the Finsemble Library is a set of client APIs connecting to one or more microservices. For example, the Launcher Client connects to the Launcher microservice. Likewise, the Router Client connects to the Router microservice. The Router microservice (via the routerClient) acts as an inter-window event hub, providing communication between all components and microservices.

Also shown in the diagram at the application level are our sample UI components, which are kept in the Finsemble seed project repo. This sample UI is built on the core as well as a separate Finsemble UI control module. Although the sample UI and the controls are production quality, we keep them outside the core because most customers will customize the UI for their own UI needs.

Here's a summary of key ideas about the Finsemble architecture reflected in the above diagram.

  1. Components are "pluggable" in the sense they can be mixed and matched to form an application. ChartIQ has a set of starting FinTech components, which can be further customized by developers building their own application. Developers can also create their own components or use third-party components built for Finsemble.

  2. A special class of components, called UI components, are provided as samples to provide common UI functionality to end users. An example is the toolbar component that end users can use to launch or control other components. The UI components are distinct in their purpose. However, each is built like every other Finsemble component: by using the Finsemble Library's client APIs.

  3. Similar to components, microservices are "pluggable"—one might think of a microservice as a kind of "invisible component" delivering centralized functionality. Microservices are less likely to change (or be interchanged) than components since they provide a basic building block functionality. Nevertheless, developers can create their own microservices with corresponding client APIs, essentially extending the Finsemble Library. Third-party microservices built for Finsemble can also be used as they become available.

  4. A special class of microservices, called connector microservices, communicate externally to public or private servers (e.g., datafeeds, databases, or cloud-based microservices).

  5. Each individual component and microservice is independently threaded in its own Chromium window that sits on top of OpenFin's secure operating layer.

  6. New microservices and components will be added by the Finsemble development team to the core modules. Advanced components and sample components will also be made available as they are created.

Further reading

For more about the lifecycle of the Finsemble Library, see Finsemble Lifecycle Events.

To learn more about the Finsemble Router, check out Using the Finsemble Router.