Deployment Patterns

WSO2 Open Banking leverages WSO2’s API management, security and integration capabilities to create a pre-configured solution specially designed for PSD2 compliance. It is built on architecture that can scale to deliver compliance for differing deployment sizes.

The main components are:

• API Manager (API-M)
• API Management Analytics (APIMAN)
• Identity and Access Manager (IAM)
• Business Process Server (BPS)
• Enterprise Integrator (EI)
• Enterprise Integrator Analytics (EIAN)
• Transaction Risk Analysis (TRA)

In a standalone setup, these components are deployed in a single server. However, in a typical production setup, it is recommended to deploy the components in separate servers (distributed setup) for better performance. Explore the following topics to learn how to deploy WSO2 Open Banking:

Basic deployment

This is the simplest deployment that is recommended to try out/demo WSO2 Open Banking, but is not suitable for any production grade exertion. In this deployment, we use the downloadable WSO2 Open Banking solution archive, which consists of the WSO2OB API Manager, WSO2OB Key Manager, WSO2OB API Manager Analytics and WSO2OB Enterprise Integrator distributions. The only configuration you need to change is the database instance details within the startup.properties file that resides in the wso2-ob-solution-<version> archive.

# Configure databases related properties
DB_TYPE=mysql
DB_USER=root
DB_PASS=root
DB_HOST=localhost
DB_DRIVER=com.mysql.jdbc.Driver

The basic deployment can be done by pointing to a MySQL or MSSQL database and going through the provided README.md.

Use the provided servers.sh script to start the WSO2 Open banking basic deployment. The script takes care of the basic configuration needs, for example, datasource configuration, database creation, and starting the servers.

Failover deployment patterns

DR/DC deployment (replication)

In this deployment pattern, we consider the deployment of the WSO2 Open Banking solution across two data centers to address the disaster recovery requirement, assuming you already have the infrastructure capabilities to replicate nodes and data in place, and that these capabilities are inline with the RPO (Recovery Point Objective) and RTO (Recovery Time Objective) targets of the business. The deployment can either be active/active or active/passive.

In this pattern, you can utilize the cloud as a disaster recovery option, where you deploy one environment on-premise and the other in the cloud. For more information, see cloud deployment.

HA deployment patterns

Minimum HA deployment

In this deployment pattern, a minimum of two nodes of each server is deployed in order to preserve the HA capability. At the same time, all WSO2 Open Banking API Manager capabilities are served by both nodes. The next two deployment patterns address the separation of these API Manager functionalities.

Gateway-separated deployment

Fully distributed deployment

Extended deployment patterns

Cloud deployment

In this pattern, WSO2 Open Banking deployment is done in the public or private cloud, based on the requirement, while integrating to the services deployed on-premise. These services can vary from authentication services to core banking services.  

Follow one of the deployment patterns mentioned above. The Open Banking cloud deployment is denoted by the hereafter.