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
Elastic
- 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)