WSO2 ESB Configuration Model• WSO2 ESB follows a zero-code approach for message mediation / enterprise integration• ESB’s runtime behaviour is decided by its XML configuration• XML configuration could be a single XML file. But to ease development and management, its split in to smaller XML configuration files (configuration artifacts)• As a result, developer could keep separate configuration files for proxy services, sequences, endpoints etc.
WSO2 ESB Configuration Artifacts• Configuration artifacts of WSO2 ESB • Proxy services • Sequences • Endpoints • Local entries • Message stores • etc..• Each artifact stores an XML configuration• Configuration artifacts are stored in a central repository to enable configuration sharing
Storing Configuration• WSO2 ESB ships with an embedded registry. Which is partitioned to three parts • Local registry – stores local resources, not meant to be shared • Configuration registry – stores configuration • Governance registry – stores governance artifacts. WSDLs, Schema etc.• ESB configuration is stored in the configuration registry
Registry Mounting• Each ESB’s registry could be mounted to a remote central repository which is managed by WSO2 Governance Registry• Each ESB’s config registry is mounted to a separate Collection (directory) of the central repository
Deployment Synchronizer• Seamlessly synchronizes configuration among Carbon servers• Key usage is to replicate configuration among nodes of a cluster without restarting nodes• Master node ‘commits’ its configuration to a central repository, slave nodes ‘check-out’ configuration from there.• Deployment synchronizer comes in two flavors • Registry based deployment synchronizer • SVN based deployment synchronizer• Registry based deployment synchronizer uses a central WSO2 Governance Registry instance to store configuration• SVN based deployment synchronizer uses a central SVN repository to store configuration