Events Overview
The information technology industry uses the term API to mean two things.
- The synchronous access from a user agent to services provided to the user agent.
- The asynchronous integration of services with each other.
To distinguish the two, the former is still referred to as an API, whereas the latter is referred to as an event. This is the basis of the Gartner concept of the Packaged Business Capability (PBC), which relies on APIs and events for the composition.
Gartner PBC
The diagram below shows a PBC in the Gartner view. The PBC consists of:
- A specification of its external APIs (the experience APIs).
- Its external events.
- A schema for its data in metadata (shown as a catalog in the diagram).
Note: The user interface is optional as some PBCs are ‘event only’ add-ons. This is typically the case for manufacturing PBCs.
Temenos PBC
The Temenos view of a PBC adds a couple of extra items as shown in the diagram below. Temenos adds in data events to complement events, and system APIs to complement user APIs. These are needed for reporting and analytics for a PBC or across PBCs.
PBC Banking Application
When two PBCs are composed, that is, they are both deployed to provide a more functional application for the bank, they interact as shown in the diagram below. This diagram has two PBCs, though of course an application provided by the bank to its users could have more than two PBCs.
The business user interface is likely to be a mash-up of both user interfaces provided by the two PBCs comprising the application. This is one reason why the UI is optional for a PBC. Similarly, the system users mash-up across the two PBCs (this is always the case for Temenos PBCs). Finally, the two PBCs communicate with each other through messages, which are either events or data events. In the Temenos architecture, PBCs do not use each other’s APIs to communicate as this isn't scalable.
Events in the Temenos Architecture
Let us look at the way events work in the Temenos architecture. They are used for two things. Firstly, for integrating the Temenos-provided capabilities with the all the other capabilities the customer had. These can be other systems owned by the customer or systems in the customer’s ecosystem, such as card processing and management systems. Secondly, events are used in the Temenos event-driven architecture. Temenos is a platform product in which individual services run on the platform to provide an integrated enterprise application.
In Transact, these services integrated implicitly through a single shared database. In the event-driven architecture these services integrate explicitly through the exchange of messages. This provides loose coupling of the services, which means that a service can be more easily upgraded, without needing to redeploy other services. It also enables services to scale better. It effectively enables all Temenos services to be asynchronous and autonomous. Only Temenos developers need to understand the internal event-driven architecture, but any developer integrating with or extending Temenos capabilities needs to understand how to use events to do this.
Temenos Event Patterns for Integration
There are four event patterns Temenos uses for integration.
Services in the Temenos Architecture
The common approach is to have a service in the event-driven architecture, either a data service or a fulfilment service, provided by Temenos. This is a generic proxy for the service provided by the third party. It publishes and subscribes to events in the internal architecture. It makes it look like the third party is part of the Temenos architecture. The data or fulfilment service is there to transform the external messages to and from the internal ones.
To enable integration with a specific third party, an adapter is added. This does syntactic transformation of messages from the outside data format, such as XML, JSON, or Avro say, to the internal format, which is generally JSON, and it also does protocol transformation. The protocol for the third party can be synchronous or asynchronous, but the protocol between the service and the adapter is always asynchronous. For events JMS point to point messaging is preferred to guarantee once and once only delivery. For data events, Kafka, or other publish and subscribe messaging, is preferred to guarantee as least once delivery.
Fulfilment Service
This approach is shown in the diagram below for a fulfilment service.
The third-party service is on the right. It uses an API or event interface to exchange messages with the adapter which, for a B2B service, is deployed in the DMZ. The adapter transforms the protocol to JMS and transforms the messages to JSON. The fulfilment service runs in the event-driven architecture and proxies the third-party service. It transforms the internal events to the third party ones and it publishes and subscribes to the event-driven architecture.
Next Steps
See also:
