Fully integrating OpenFin applications with remote services requires a plan for how to best interact with those services. Most financial services firms have hundreds of applications and thousands of microservices, some of which consume events and some of which generate them. Some present web-native APIs, and many do not.
We have previously talked about how REST can be enhanced to handle the many outbound exchange patterns. In this post, we’ll be discussing a better way to organize OpenFin inbound events.
For the purposes of this post, we’re defining inbound events as any asynchronous event received from a remote source. There are two main types of inbound events:
The client side of real-time inbound events is pretty straightforward. You set up a connection and callbacks for the different kinds of events you expect. JavaScript makes it easy to pass control to a function when an event arrives.
The trickier part is choosing what is on the other end of that connection. Your app may be talking to a single remote service or many. It could be inside the datacenter, in a private or public cloud, or a 3rd-party service. The remote service may present a web, messaging or legacy interface. The remote services may also offer different approaches to security.
There are many things to consider to inform the best course of action. Here are three:
If you are interacting with just one remote service, and it implements a WebSocket server, coding direction to its API may be a solid choice. The service will either document how to handle the matching WebSocket client, or it may provide a client-side JavaScript API to handle the connection and event management.
In all other cases your easiest path forward will be to use an event broker to coordinate with the remote services. Let’s take a look at the many ways a Solace PubSub+ broker simplifies your event handling.
Whether your back-end is a cloud service with a web-based API, an internal service connected to an AMQP network, or the stodgy old mainframe holding the legacy crown jewels, your OpenFin app simply connects to the broker. The broker handles all the complexity of the various network topologies and differences in connection protocols. The broker will then stream or queue events for consumption by your application. Security is handled by broker-defined access control lists (ACLs) to verify which remote resources each user or application can use and how.
Let’s take a look at how the broker would pass events from a few different service types.
It’s always easy to post to a cloud or web-based service using REST, but not as clear how best to receive an asynchronous event back. Often cloud architectures will rely on using some kind of intermediary storage like AWS S3, or a database, then ask the calling app to poll to read the stored data. Sometimes the remote service will include a WebSocket server, and will supply a JavaScript API that emits events to feed your callbacks.
Many of our customers write their remote services to POST events to Solace using REST, and Solace can forward that event onto the client through a WebSocket. In OpenFin, the developer uses the Solace JavaScript API, and Solace uses WebSocket to signal anything that arrives for that app.
If the service does not present a web-friendly API, Solace becomes a peer on any popular messaging network and forwards events back to OpenFin. For example, Solace would subscribe JMS or AMQP topics, or identify queue names on behalf of the OpenFin app, to receive and forward inbound events over a WebSocket. Solace can even reach proprietary protocols like MQ or Kafka through a bridge so those events can reach OpenFin applications as well.
In the companion blog post about outbound requests, we showed how Solace allows a REST POST to be mapped into a publish/subscribe network for delivery to many services. The reverse pattern is also true for inbound. An app that receives events from many services can be simplified by having a broker stream or queue the events as an intermediary.
A broker is most useful when you have data going to and from many services. In large OpenFin installations, it is very common for many sources and many apps to need to freely exchange information.
While you may have tight control over your OpenFin environment, the data sources those apps interact with are spread across clouds and datacenters, and have been created with different technologies over a span of decades. Just like a broker can help you do much more with REST, that same architecture can simplify inbound event management as well.
For more on this topic, download our Guide to Connectivity for OpenFin that outlines the three architectural approaches developers and architects may choose to connect OpenFin applications to a variety of data sources: