Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

Version 1 Next »

MediationZone centralizes the control logic and distributes execution, and thus addresses the two main problem areas related to vertical and horizontal scaling architectures:

  • Vertical scaling can lead to CPU contention where the scalability of a centralized architecture is limited to the number of plug-in processors supported by the hardware. MediationZone offers virtually unlimited scalability by its support for any number of collaborating networked servers.

  • Horizontal scaling can lead to inconsistent maintenance of a distributed architecture when code and data potentially reside on a large number of servers. MediationZone supports automatic, on-demand distribution of code and configuration to servers configured to be part of the installation, thus reducing operation and maintenance efforts and ensuring a consistent configuration store.

Scale-out architecture

Logically, the platform is layered into three different zones:

  • Access Zone is the layer where users access the system through a graphical interface or command line interface to perform operations and maintenance tasks. 
  • Control Zone hosts configurations and provides storage and a range of services that are essential to the system.
  • Execution Zone is a scale-out layer that provides processing capacity in the system. This layer contains one or several Execution Contexts and Service Contexts, which are distributed over any number of servers.
    • Execution Contexts are responsible for executing and supervising workflows. 
    • Service Contexts host services that workflows running in Execution Contexts can share.

Functionality in any of the Access Zone, Control Zone, and Execution Zone may be distributed over any number of servers, or be deployed on a single server. Distribution across several servers enables deployment of right-sized and cost-effective mediation solutions for optimal hardware utilization.

The workflow service uses a configurable load-balancing algorithm to determine which Execution Context is most suitable to receive the execution of the workflow. Decisions for deploying a workflow on a specific server may, for example, be either location or hardware dependent. Specific network hardware might be required for the collection subsystem, or improved LAN bandwidth utilization could be achieved by deploying collection and aggregation workflows close to the network elements.

 The system processes in the various zones are referred to as "pico instances" and can be of different types:

  • Platform

  • Execution Context (EC)
  • Execution Context Stand-Alone (ECSA)
  • Service Context (SC)
  • Command Line Tool (mzsh)
  • Desktop

EC and ECSA are similar. However, while ECs always depend on a running Platform, ECSAs can run independently.

The Platform, ECs, ECSAs, and SCs run in "containers", that are installed on one or more hosts. Each installation is assigned a container name to identify it uniquely within a system. One host, physical or virtual, may hold several containers, each one with a unique name and installed in separate home (MZHOME) directories. 

There are two types of containers:

  • The Platform Container runs the Platform and optionally EC, ECSA and SCs. The Platform is always included in a Platform Container installation.
  • Execution Containers run ECs, ECSAs and SCs. These pico instances are typically configured after the installation of the container.


  • No labels