MediationZone can be deployed in two different ways - classical and containerized. The main difference, is the way a cluster is installed, configured, and managed. The classical version uses DigitalRoute installables, the MediationZone System Topology Registry, and a third party to achieve high availability. The containerized version uses Kubernetes, pre-packaded YAML files and Docker containers. For installation in AWS, the infrastructure files are also provided.
The Desktop also comes in two different varieties; a web version for containerized, while for classical, it is typically installed locally.
The architecture in combination with support for deployment on Amazon Web Services infrastructure, and a wide range of OS platforms, enables cost-efficient mediation solutions.
Test system
One server maintains the execution of all zones – this represents a local server on which the mediation processes are configured and validated, for later export to production servers.
Single production server
Multiple access zone clients access a single server (or cluster) that manages the execution of control zone as well as execution zone logic.
Multiple production servers
Multiple access zone clients access a single server (or cluster) that manages the control zone. Workflows are distributed to any number of execution zone servers based on data volumes and specific deployment requirements.
New functionality, customizations and business processes can be dynamically implemented, and there is no downtime on an executing system when the changes are made.
In the case of patches or enhancements to the executable, the changes are introduced to the code server that will automatically propagate the change to all parts of an installation (i.e. clients, Execution Contexts etc.). For classical, there are upgrade scripts; while, for containerized, new Dockers are provided.
In the case of changes to the business processes, the changes can be made on a running workflow and will not lead to any downtime of the processing, it will become active the next time the workflow is started.
To ease the rollout of new configurations, multiple configuration spaces can be used in production to keep the running configurations separated from configurations that are being staged for production. This means that production servers can be updated with new configurations while the running configurations stay unchanged.
When the new configuration is ready to be taken into production, only a minimal downtime will be needed even for extensive changes.
Configuration spaces can also be used for handling backups, to enable rollback of old configurations.
Workflow Mapping to Execution Contexts
Workflows can be mapped to Execution Contexts in several ways. The distribution can be up to the Platform to decide, in which case it can be configured to base it on load or number of workflows already running. A workflow - or a configured group of workflows - can be pre set to execute on particular Execution Contexts. Also, there is the possibility to map one or several Workflow Templates, including how many of each Template's instances that shall be started on a ECs with a particular name pattern. This way, the cluster can be easily scaled up and down. Please see section Execution Elasticity[hide]8.2[/hide] for more information.