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 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:
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.
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: