Logical architecture

To learn more about how the the IBM Connected Trade Gateway architecture and how it integrates with other solution components.

• IBM Application Integration offers a single solution which ISVs and banks can use to create multi-style integrations, create APIs and act on events. It lets you quickly build and test integration flows with authoring tools for both integration experts and business technologists. The platform lets you secrely connect with hundreds of applications on cloud and on-premise with pre-built smart connectors and templates. The platform offers the fastest performing engine that virtually supports any-to-any data format and it offers AI-infused, smart tooling for non-specialists to quickly create integrations by using natural language. The platform also gives you the ability to deploy integrations with visibility into flow health and performance across hybrid environments.

• Persona centric tooling IBM App Connect Enterprise Toolkit and Designer are complementary integration authoring tools that allow those who are newer to integrations the ability to collaborate with experts to build organization-wide integrations. Designer provides no-code development and AI-powered tooling for business users, while Toolkit provides feature rich message modeling with built-in nodes encapsulating transports, technologies and applications for integration experts. The two tools offer fully blended capabilities with the ability to reuse connectors, call shared assets and intermingle functions.

• API Management is provided by the following three sub components:

  • API Manager: Enables providers of APIs to create or upload a definition of an API that they would like to make available to others by allowing them to determine who should be able to discover it, define the policies that will protect it, and outline the process for approving its use.

  • API Developer Portal: Enables potential consumers of the APIs to search the portal catalog for APIs that might be related to the data that they need and only view APIs that the provider has made accessible to their role. They can then request immediate access to the APIs and are given a set of credentials to use that are unique to their application so that their usage can be tracked. This portal can be used by all potential consumers of the API, whether within or beyond the enterprise boundary.

  • API Gateway: API consumers call the APIs via the API Gateway. It enforces the policies that are defined by the providers. These include confirming the identity of the consuming application, and a selection of policies such as rate limiting, which outlines the number of requests per second. These policies may be general across all APIs or specific to a particular consumer. For example, there might be different "plans" available that a consumer is able to subscribe to, each offering differing policies.

• Management console: Centralizes the control and management plane with its own platform UI. All of the integration components mentioned above are available as standalone containerized software that can be installed and managed via the platform UI.

Reference architecture

IBM Cloud accounts can be used for isolation of all cloud resources, administration, and billing, which allows for a flexible deployment model that is flexible and can be tailored to the customer's needs. For example, if you wanted to consume this trade gateway purely as SaaS then the underlying deployment complexity can be abstracted out and managed by IBM. On the other hand, if you want more visibility and control over the deployment and corresponding billing and administration then IBM can provision the necessary resources within the customer's cloud account. The second option gives the customer the ability to pick and choose which components of the gateway solution they want to deploy. These containerized components are depicted by the OpenShift CTG workers in following high-level reference deployment architecture.

The following figure represents a more detailed deployment architecture for the Connected Trade Gateway and surrounding solution components. The diagram represents a single region with multiple availability zones view. The platform can be easily scaled to multiple regions.

This is a reference architecture that follows industry best practices and is pre-validated for regulated industries such as financial services. The architecture can be tailored to fit the customer's requirements.

A VPC gives an enterprise the ability to define and control a virtual network that is logically isolated from all other public cloud tenants, creating a private, secure place on the public cloud.

• Management VPC: Provides compute, storage, and network services to enable application provider administrators to monitor, operate, and maintain the environment. The intent is to completely isolate management operations from the VPC that is running is consumer workloads. It is distributed across three zones in one multizone region (MZR). Each zone contains two subnets that are protected by different ACLs.

• Subnets for management tools: The top subnet in each zone is part of the default security group for the VPC. And, each of those subnets contain an arbitrary number of virtual server instances and or RedHat OpenShift workers that use Block Storage for VPC. These instances are where your management tools run. The lower subnets in the image relate to inbound connectivity, which is covered in subsequent sections.

• Connectivity inbound to VPC: Connectivity from your application provider's enterprise environment to the management VPC is accomplished by using Direct Link or Virtual Private Network (VPN) for VPC.

  Direct Link is the most secure way to enable connectivity from the application provider's on-premises environment to the management VPC. The speed and reliability of Direct Link extends to your organization's data center's network and offers more consistent, higher-throughput connectivity, keeping traffic within the IBM Cloud network.

  When using Direct Link, a private Application Load Balancer for VPC (ALB) is used to distribute traffic among multiple server instances within the same region of your VPC. An IBM Cloud account requires a single Direct Link instance. In the image, there are two Direct Link icons only to make the diagram more readable.

  An alternative connectivity pattern requires use of the VPN for VPC service to securely connect from your private network to the management VPC. VPN for VPX can be used as a static, route-based VPN or a policy-based VPN to set up an IPsec site-to-site tunnel between your VPC and your on-premises private network or another VPC. When using VPN for VPC, you must place the gateway in a subnet, which is shown in the diagram.

  • Bastion host: Regardless of whether you are using Direct Link or VPN for VPC to connect to the management VPC, you need to help ensure that all traffic is routed through a bastion host with session recording. The bastion host solution is depicted in the two rightmost lower subnets in the diagram.

• Connectivity between VPCs: The management VPC needs to connect to the workload VPC to deploy, configure, and operate the components and workloads that are found in the workload VPC. Transit Gateway is designed specifically for this purpose, and is the means for connecting your management VPC to your workload VPC.

• Workload VPC: The workload VPC provides compute, storage, and network services to support hosted applications and operations that deliver services to the consumer. Take a closer look at the following components within the VPC.

  • Regions and zones: Just like the management VPC, the workload VPC is spread across three zones. The workload VPC should be created in the same MZR as the management VPC.

  • Connectivity to workload VPC: If the consumer is in the same organization as the application provider, then just like for the management VPC, Direct Link can provide access to the workload VPC. Alternatively, VPN for VPC can be used for site-to-site VPN connectivity.

• Storage and encryption:

  • Block Storage for VPC: Block Storage for VPC is automatically created for the primary book volume when you create a virtual server. You can also create more data volumes by using Block Storage for VPC within any subnet. By default, all boot and data volumes are encrypted at rest with IBM-managed encryption. There is no additional cost for this service. IBM-managed encryption uses the following industry standard protocols:

    • AES-256 encryption
    • Keys are managed in-house with Key Management Interoperability Protocol (KMIP)

    For all sensitive and consumer-owned data, the application provider should use customer-managed encryption. With this encryption method, you can bring your own customer root key (CRK) to the cloud or have a key management service (KMS) generate a key for you. For IBM Cloud for Financial Services, the supported key management service is Hyper Protect Crypto Services (HPCS). Root keys encrypt volume and custom image passphrases with envelope encryption, a process that encrypts a key with another key.

  • Object Storage: Object Storage is an alternative storage option that is useful for certain use cases, including backup and recovery, data archiving, cloud-native application building, and AI and big data analytics. Object Storage stores encrypted and dispersed data across multiple geographic locations.

  By default, all objects that are stored in Object Storage are encrypted by using randomly generated keys and an all-or-nothing-transform (AONT). While this default encryption model provides at-rest security, financial service workloads need full control over the data encryption keys used. Again, Hyper Protect Crypto Services should be used for this purpose.

Using IBM Cloud services outside of a VPC

With IBM Cloud Virtual Private Endpoint (VPE) for VPC, you can connect to supported IBM Cloud services from your VPC network by using the IP addresses of your choosing, which is allocated from a subnet within your VPC. In the reference architecture diagram, VPEs appear in the middle subnets of the workload VPC.

VPE is an evolution of the private connectivity to IBM Cloud services. VPEs are virtual IP interfaces that are bound to an endpoint gateway created on a per service, or service instance, basis (depending on the service operation model). The endpoint gateway is a virtualized function that scales horizontally, is redundant and highly available, and spans all availability zones of your VPC. Endpoint gateways enable communications from virtual server instances within your VPC and IBM Cloud service on the private backbone. VPE for VPC gives you the experience of controlling all the private addressing within your cloud.