Lifecycle Management of SOA Artifacts for

WSO2 Products

Janaka Ranabahu (Software Engineer – WSO2 Governance Registry)

&

Sadeep Jayasumana (Software Engineer – WSO2 Enterprise Service Bus)

Overview

• Problem

• Solution

• Governance Registry

• Lifecycles

• ESB configuration Model

• Registry Mounting

• Deployment Synchronizer

• Demo

Problem

• SOA Governance

• Moving configuration between different

environments (dev, qa & prod)

Solution

WSO2 Governance Registry

• Repository

• Resources

• Collections

• Features

• Versioning

• Lifecycle management

• Tagging

• Rating

• Comments

• Search

Lifecycles

• Represents the nature of a resource

• States

• Transitions

• Ability to define different lifecycles

• XML configuration

• SCXML specification

Lifecycles

• Check items for states

<state id="Testing">

<datamodel>

<data name="checkItems">

<item name="Code Completed" forEvent="Promote">

</item>

….........

</data>

</datamodel>

</state>

Lifecycles

• Permissions for check items

<item name="Code Completed" forEvent="">

<permissions>

<permission roles=""/>

</permissions>

.....

</item>

Lifecycles

• Validations for check items

<item name="Code Completed" forEvent="">

<validations>

<validation forEvent="" class="">

<parameter name="" value=""/>

</validation>

.....

</validations>

</item>

Lifecycles

• Multiple state transitions

<state id="Testing">

<transition event="Promote" target="Production"/>

<transition event="Demote" target="Development"/>

</state>

Lifecycles

• Permissions for state transition

<state id="Testing">

<data name="transitionPermission">

<permission forEvent="" roles=""/>

</data>

</state>

Lifecycles

• Validations for state transitions

<state id="Testing">

<data name="transitionValidation">

<validation forEvent="" class="">

<parameter name="" value=""/>

</validation>

</data>

</state>

Lifecycles

• Transition UIs

<state id="Testing">

<data name="transitionUI">

<ui forEvent="Promote"

href="../lifecycles/invoke_aspect_ajaxprocessor.jsp"/>

</data>

</state>

Lifecycles

• Transition executions

<state id="Testing">

<data name="transitionExecution">

<execution forEvent="" class="">

<parameter name="" value=""/>

...

</execution>

</data>

</state>

ESB Configuration Lifecycle

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

Stored Configuration

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

Mounting Multiple ESBs

Mounting Multiple ESBs

Mounting Configuration (registry.xml)

<wso2registry>

…

<dbConfig name="mountRegistry">

<url>jdbc:mysql://192.168.10.1:3306/registryDB</url>

<userName>root</userName>

<password>root</password>

<driverName>com.mysql.jdbc.Driver</driverName>

<maxActive>50</maxActive>

<maxWait>60000</maxWait>

<minIdle>5</minIdle>

</dbConfig>

<remoteInstance url="https://192.168.10.2:9443/registry">

<id>mount1</id>

<dbConfig>mountRegistry</dbConfig>

<readOnly>false</readOnly>

<registryRoot>/</registryRoot>

</remoteInstance>

<mount path="/_system/config" overwrite="true">

<instanceId>Mount1</instanceId>

<targetPath>/_system/esbConfig/dev</targetPath>

</mount>

….

</wso2registry>

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

https://ail.google.com/mail/u/0/?ui=2&ik=ad9ae58f41&view=att&th=1331a70983344a32&attid=0.1&disp=thd&realattid=f_gtxto6mk0&zw

Selected Customers

WSO2 engagement model

• QuickStart

• Development

Support

• Development

Services

• Production

Support

• Turnkey Solutions • WSO2 Mobile Services Solution

• WSO2 FIX Gateway Solution

• WSO2 SAP Gateway Solution