Popular Posts

Monday, November 21, 2011

This post is about a new feature in WSO2 Carbon product platform. I will use the latest versions of WSO2 Governance Registry(WSO2-G-reg-4.1.0) and WSO2 Enterprise Service Bus (ESB-4.0.2) for the demonstration.

Before going through the configuration steps, lets look at the problem which is going to be addressed using Deployment Synchronizer.

Suppose we have a WSO2 ESB product cluster with a single READ-WRITE node and a several READ-ONLY nodes which shares a common configuration registry. When we deploy a proxy service from READ-WRITE node, in order for other nodes to be synced with that new service deployment, all READ-ONLY nodes have to be restarted. This is a painful concern in a large product cluster.

WSO2 Deployment Synchronizer feature has been implemented to resolve that concern. With that, once you deploy a service (or any deployable artifact such as ESB sequence, scheduled task etc..) from one node in a product cluster, the other nodes automatically get the changes and sync up with the master (or READ-WRITE) node.

The Deployment Synchronizer makes use of two different approaches for deployment artifact synchronization.

Lets proceed through setting up a two node WSO2 Carbon product cluster as shown above.

Step 1:

Extract the downloaded WSO2ESB-4.0.2.zip and make two copies of it as wso2esb-rw and wso2esb-rowso2esb-rw directory is used as the master node of the cluster and wso2esb-ro node will be used as the slave node.

Step 2:

Extract the downloaded WSO2greg-4.1.0.zip into a new directory. This will be used as the central governance and configuration registry in our ESB cluster.

Step 3:The above WSO2 G-reg instance will run on a mysql DB instead of the default H2 database. Therefore, lets create a mysql DB first.Open a mysql prompt in your server. Type the following commands to create a database and assign user privileges.

mysql>create database reg_db;mysql>use reg_db;mysql>grant all on reg_db.* TO regadmin@localhost identified by "regadmin";

Edit the CARBON_HOME/repository/conf/registry.xml of the WSO2 G-reg server as follows.

We are going to run 3 carbon servers in the same machine. Therefore, we need to change the port index in CARBON_HOME/repository/conf/carbon.xml so that each of the WSO2 ESB nodes will run on their own ports without conflicting with each other.In carbon.xml, change the following element in order to run the ESB read-write node in HTTP port 9764 and HTTPS port 9444.

<Offset>1</Offset>

We are going to store the configuration data of ESB nodes in the cluster in /_system/esbnodes space of the above registry. Also, the governance data will be stored in /_system/governance directory. Therefore, lets add the following registry mounts through CARBON_HOME/repository/conf/registry.xml.

We have configured and started the READ-WRITE node of ESB cluster. Now, we can configure the READ-ONLY node. The configuration is almost same as READ-WRITE node except the highlighted elements given below.

First, change the port offset to 2 so that the ports will not be conflicted with the other server ports.

<Offset>2</Offset>

Change the default NIO HTTP and HTTPS ports in CARBON_HOME/repository/conf/axis2.xml as follows.

Now we are done with the clustering setup but we have not done any configurations related to the deployment synchronizer yet.We will look in to the registry based deployment synchronization first.

Step 6 - Registry based deployment synchronizer

In this mode, once you deploy an artifact from the READ-WRITE node, the artifacts will be stored in the relevant collection in the configuration registry. The other nodes of the cluster will use the registry checkin-checkout client and checkout the deployment artifacts to their file system. Then with the hot deployment functionality, the artifacts will get deployed in the cluster nodes.

Lets look at how we can use the registry based deployment synchronizer.

Log in to management console of ESB READ-WRITE node (https://localhost:9444/carbon)

Navigate to Configure --> Deployment Synchronizer UI

Select Auto Commit option and click on Enable

Log in to management console of ESB READ-ONLY node (https://localhost:5/carbon)

Access Configure --> Deployment Synchronizer UI

Select Auto Checkout option and click on Enable

Create a proxy service (eg:-proxy1) in READ-WRITE node

After 60 seconds (the default synchronization period), log in to the management console of the READ-ONLY node of the cluster.

You will notice that the proxy1 is listed in the services list of READ-ONLY node

Step 7 - SVN based deployment synchronizer

Deployment synchronization can be achieved using a SVN repository as well. Lets look at SVN based deployment synchronizer.

In this mode, instead of a registry, we use a subversion repository as the deployment artifact store. As we check-in files to SVN, the synchronizer use a SVN client API and commit and update deployment artifacts periodically by using a SVN location.

Come and meet us at WSO2 booth at ApacheCon. You will find how WSO2 built world's first free and open source PaaS and renowned SOA platform using various Apache project components and how we adhered to the Apache process in project releases.

Web Services Testing with soapUI

About Charitha

Charitha Kankanamge possesses over 14 years of experience in various technological domains including software testing/QA and middleware technical support. Currently, he works as a Software Quality Assurance Manager at Amazon. Previously, he worked for an open source software company, WSO2 as Senior Manager, Technical Support. He is also a committer of the Apache Software Foundation. Charitha's strengths and key experiences include functional testing, SOA testing, test planning and agile/exploratory test mechanisms.