Flavors of Integration Servers (IS, API Gateway, Microservice Container)

This article provides a quick introduction of different flavors of Integration servers that are available in Software AG product suite from 10.x releases.

Integration server is the core component in webMethods suite that provides basic to advanced integration capabilities for many years. It is still the case.

Software AG has released few other variants of Integration server for customers and industry needs.

An introduction of what they are, how they must be used is described below.

Refer Software AG documentation for detailed understanding.

Integration Server

Integration server provides basic to advanced integration capabilities. Many modules run on top of IS to provide one or more capabilities as listed below. Many of these modules can co-exist in Integration server except some.

IS with Adapters to interact with DB, backend applications
IS with eStandards to support all eStandards such as Swift, RN, EDI etc., 
IS with Trading Network to support B2B
IS with Process Engine to support BPM
IS with Task Client to support Workflow management Task Engine
IS with Enterprise Gateway in DMZ to support internet clients
IS with Mediator to provide virtualization, registry lookup etc.,
IS with Mobile to compliment Mobile App integration
IS with Device Integration to complement IoT
IS with Cloud stream connectors… to interact with Cloud based provider using cloud stream…

While this has been the case, the newer IS variants are addressing different capability needs. 

EG and Mediator

  • IS with Enterprise Gateway is unique which cannot co-exist with other modules such as Adapters or BPM engine with it.
  • Until SAG webMethods suite 9.12v, Enterprise Gateway is typically placed in DMZ to provide security to expose APIs beyond firewall.
  • IS with Mediator component is placed in internal Data center of organization.
  • Mediator with DC interacts with EG in DMZ
  • In order to use Mediator, Centrasite is mandatory to configure & deploy API’s (Design time governance)
  • Mediator provides Run time governance such as Mediation and Service Virtualization capabilities

Typical deployment pattern looks as below, and let’s see how this is changed from 10.x releases in next section. 

API Gateway

  • API Gateway released in 10.x combines & provides the capabilities of both Enterprise Gateway and Mediator
  • EG and Mediator cab be used only until 9.12
  • In addition to existing capabilities, it provides advanced capabilities for Service Virtualization, Mediation and API monetization
  • Unlike Mediator, Centrasite dependency is not mandatory to run API Gateway
  • Centrasite is required if you need Design Time Governance for API life cycle
  • Unlike before where EG is placed in DMZ and Mediator with Centrasite is placed within DC network; it’s the same product API Gateway in both DMZ and within DC.
  • Additional modules such as Adapters, Trading Networks, Process/Task engines etc., cannot be installed/co-exist with API Gateway
  • Elastic is used as configuration repository to store API related assets and configurations
  • API Gateway in DMZ can provide Threat protection and Revere invoke
  • API Gateway within DC can provide all other API capabilities like SV, Mediation, Monetization
  • Terracotta Server Array is used for clustering API Gateway to share information like OAuth token, rate limiting events for monetization etc.,
  • API Gateway can communicate with any different versions of Integration servers within DC
  • API Gateway doesn’t need to connect to any RDBMS

Setup with Design Time & Run Time Governance

Setup with Run Time Governance only 


  • API Gateway ships with Elastic to store API related configuration and assets
  • In order to provide High Availability for configuration repository, minimum of 3 Elastic nodes are required as per Elastic recommendation. Thus 3 nodes of API Gateway is required
  • API Gateway can also stores run time events in Elastic on top of other Destination support that are provided. This Elastic can be either the one shipped with API Gateway or external Elastic setup
  • API assets and configuration can only be stored in Elastic that is shipped with API Gateway and not in an independent Elastic setup

API Gateway User Interface is built on top of Kibana

Microservice Container (MSC)

  • MSC is another flavor of Integration server
  • It is recommended to use MSC when you want to run IS as Docker containers
  • MSC foot print is lesser (~900 MB including JVM)
  • MSC foot print size is being reduced in every release. The goal is to make it as much lesser as possible and product teams are working towards it
  • While the Docker image size is around ~900 MB, Docker instance size during runtime is around 150 MB or lesser.
  • Do note that, MSC Docker image available in Docker repository is built on top of CentOS. You can download and play around. Also refer https://github.com/SoftwareAG/
  • Container specific features are prioritized in Micro service container edition

When to use what?

Software AG API Gateway is part of API Management ecosystem. Enterprise level APIs can be registered and exposed via Gateway/Portal to internal and external consumers.

API providers can be

  • Applications or backend systems that exposes business API directly
  • Applications that exposes Micro service(s)
  • SOA services that unique business capability which can be registered to expose existing functionalities (using REST to SOAP conversion capability of API Gateway)

Microservice Containers

  • Expose business capability as Micro services
  • Micro services can talk to other micro services using solution patterns
  • Can be run as Docker containers, and Orchestrated using tools such as Docker Swarm, Kubernetes, Open shift
  • Docker container friendly

Integration server

  • expose SOA services that provides reuse & composition
  • integrate with all internal systems using variety of protocols
  • Traditional EAI/ESB/B2B/BPM etc., 

Flavors of Integration Server.pdf (502 KB)