Thursday, April 28, 2016

Real time use cases of Deployment Synchronizer with a WSO2 ESB Cluster – Part 1

In this blog post I will explain some of the real time use cases of Deployment Synchronizer (DepSync) in a WSO2 ESB Cluster environment. If you want to know more about DepSync follow my previous post.

Before going further into the topic I'm going to list down the use cases so anyone can simply understand the possible scenarios happened here.

1. Create an artifact using Management console
2. Remove an artifact using Management console
3. Create and save an artifact in local repository of the manager node
4. Remove an artifact in local repository of the manager node
5. Create and save an artifact in local repository of a worker node
6. Remove an artifact in local repository of a worker node


Usecase 1 - Create an artifact using Management console

In here, I'm going to create a sample address endpoint and check how the synchronization process happened in manager and worker nodes.

1. Go to management console of the manager node, select Endpoints under Service Bus.

2. Then select 'Add Endpoint' by choosing 'address endpoint' as the type

3. Give a name and address to the Endpoint and press 'Save and Close'





Now observe the terminals of both manager and worker nodes.


Manager Node





Worker node





Once an artifact has been deployed in central repository (We use a SVN repository), manager node will send an hazlecast message to the all worker nodes indicating that the autocommiting of a change has been done. So worker nodes receive the same hazlecast message ( check messageId ) and the process of checking out (autocheckout) the changes from the central repository to its local repository happens.


Usecase 2 - Remove an artifact using Management console


Same process like the Usecase 1 happens here. Once an artifact has been removed from the repository, manager node will commit it in central repository and parallel send a message to worker nodes to checkout the changes. But check the below output of the worker node which shows the undeployment of the removed artifact from its local repository.


Worker Node





Usecase 3 - Create and save an artifact in local repository of the manager node


In this use case I'm going to save an endpoint manually in the local repository (<PRODUCT_HOME>/repository/deployment/server/synapse-configs/default) of the manager node.


Following is the sample configuration of a proxy which includes a send mediator


<proxy name="PassTroughTest" startonload="true" trace="disable" transports="http https" xmlns="http://ws.apache.org/ns/synapse">
<target>
<endpoint>
<address uri="http://10.100.7.11:9768/java_first_jaxws/services/hello_world">
</address>
</endpoint>
<outsequence>
<send>
</send></outsequence>
</target>
</proxy>


Go to proxy-services folder of the local repository and create an Xml file with the name 'SamplePassThrough' and save above configuration.

Now we have created a sample proxy service successfully. Let's check the terminals of both manager and worker nodes to understand what happened here.


Manager Node





Worker Node




As soon as the file created in the local repository of the manager node, it will auto commit the new configured artifact in central SVN repository with the name of the proxy service. Although the message communication happens after that and worker node receives the message, checking out from the Svn repo and deployed the proxy service in local repository of the each worker node.


I will explain other 3 use cases in my next post. If you have questions, don't hesitate to drop a comment.

No comments:

Post a Comment