WSO2ESB Front-end Back-end Seperation Scenario

The idea behind front-end back end seperation is, having esb server in back-end esb and management console in front-end esb. Simply it is a replacement of back-end esb management console with front-end esb management console.

1. Take 2 ESBs'(one for front-end and the other one for back-end)

2. The special thing we have to do is with conf/carbon.xml of both front-end and back-end. Change,


with putting relevant values. = management console listener port of back-end(specified as conf/transport.xml in back-end)

Note1: If a carbon.context is not using, no need to change carbon.xml of back-end esb.

3. Do following changes to front-end or back-end. Change management console listener port of conf/transport.xml

<transport name=”https”>
<parameter name=”port”>9443</parameter>

And http and https listener ports of esb server in conf/axis2.xml to some other port values.

<transportReceiver name=”http”>
<parameter name=”port” locked=”false”>8280</parameter>
<parameter name=”non-blocking” locked=”false”>true</parameter>
<!–parameter name=”bind-address” locked=”false”>hostname or IP address</parameter–>
<!–parameter name=”WSDLEPRPrefix” locked=”false”>https://apachehost:port/somepath</parameter–&gt;

<!– the non blocking https transport based on HttpCore + SSL-NIO extensions –>
<transportReceiver name=”https”>
<parameter name=”port” locked=”false”>8243</parameter>
<parameter name=”non-blocking” locked=”false”>true</parameter>
<!–parameter name=”bind-address” locked=”false”>hostname or IP address</parameter–>
<!–parameter name=”WSDLEPRPrefix” locked=”false”>https://apachehost:port/somepath</parameter–&gt;
<parameter name=”keystore” locked=”false”>
<parameter name=”truststore” locked=”false”>
<!–<parameter name=”SSLVerifyClient”>require</parameter>
supports optional|require or defaults to none –>

This step is done to avoid port conflicts of two esb instances.

4. Delete server folder of front-end esb and console folder of back-end esb which are in webapps/ROOT/WEB-INF/plugins

Note2: Better to do the changes in step 3 in front-end. Then according to Note1, no need to do changes of back-end except deleting of console folder. Therefore can easily have a fresh esb server whenever required.

WSO2 ESB Directories and Configuration Files

The WSO2 ESB is an Open Source Enterprise Service Bus (ESB) available based on the lightweight Apache Synapse ESB. Refer installation guide for complete detailed instructions for installing WSO2 ESB. When WSO2 ESB binary distribution is extracted, the top level directory structure is as follows,

1. bin : Consists of the required set of shell scripts and batch files for Unix/Linux users and Windows users respectively. These scripts can be used to start WSO2 ESB, start available samples, change administrator password, etc.

2. conf : All the global configuration files are stored here.

– axis2.xml:

Because WSO2 ESB is based on Apache Synapse ESB which uses the Apache Axis2 SOAP engine, it can be used for WSO2 ESB also as a SOAP engine. The global configuration or the underlying transport and Web services support of the Axis2 engine is specified in axis2.xml. The settings configured in the axis2.xml file are directly applied to the server at startup time. In axis2.xml file, there are clearly mentioned how the configurations can be done.

The HTTP and HTTPS ports used by the ESB HTTP-NIO transport can be configured by following line under ‘transportReceiver’ sections in both HTTP and HTTPS.

<parameter name="port" locked="false">8280</parameter>

The bind address values can also be configured if necessary. To configure the bind address for the server, define the following parameter under the HTTP and HTTPS transport receiver configuration,

<parameter name="bind-address" locked="false">hostname or IP address</parameter>

Bind address is used to restrict the server to listening to a single address, and can be used to permit multiple servers on the same machine listening to different IP addresses.

– synaps.xml:

The synapse.xml configures the mediation rules and configuration for the ESB. Mediation sequences can be defined within the synapse.xml configuration or within the Registry.

Therefore synaps.xml should include the following registry definition.

<syn:registry provider="org.wso2.carbon.mediation.registry.WSO2Registry">
        <syn:parameter name="cachableDuration">15000</syn:parameter>

The synaps.xml holds two special sequences named as “main” and “fault”. These may be defined within the synapse.xml, or externally via the Registry. If both are not found, those will be created automatically.

– carbon.xml:

The main server configuration file and this represents all the system properties such as carbon.home, WebContextRoot, front end back end separation configuration, axis2 related configuration etc.

– registry.xml:

There is an embedded WSO2 G-Reg which uses the embedded H2 database in ESB. The configurations related to this embedded registry are stored in the registry.xml file.


Here in <ReadOnly> tags ‘false’ is set so that the ESB will be able to store resources or write values to the registry and reading the existing resources. By making this value ‘true’ the ESB can be made only to read the existing resources avoiding storing resources and reading values to the registry.

The embedded registry instance can be pointed to a database other than the default embedded H2 database. To change the database used by the registry or change the location of the database files, highlighted components of the following section need to edited.

<dbconfig name="wso2registry">

WSO2 ESB can work with a remotely hosted WSO2 G-Reg instance also. This is very important and useful in production deployment scenarios. Using this feature, several WSO2 ESB instances can work with the same registry and database with effectively sharing the configurations and other resources among all the ESB instances.

– transport.xml :

This can be used to change the ports used by the ESB management console and other parameters by changing the default configuration. By default the management console would accept HTTPS requests on port 9443.

<parameter name="port">9443</parameter>

3. database

Embedded H2 database used by WSO2ESB and associated files are contained in this directory. The database is setup during the first startup of the ESB. Therefore this directory is required when the ESB is using the embedded H2 database. The embedded registry can be cleaned by passing –cleanRegistry argument to ESB startup script.

<!– @page { margin: 0.79in } P { margin-bottom: 0.08in } –>

4. Dbscripts

There are scripts for creating required database tables on different database management systems like MySql, Oracle, derby, MsSql, etc. These scripts are stored in this directory.

5. lib
Contains all the jar files and OSGi bundles required by the embedded Tomcat instance including the file used by the ESB.

6. logs
All the server logs created during server runtime will be stored here.

7. repository
All the OSGi bundles, service artifacts, modules, sample configurations and related resources used by the WSO2 ESB instance and all the necessary OSGi bundles at server runtime. External dependency jars can be added
to repository/components/lib or repository/components/extensions. These jars will be automatically converted into OSGi bundles on ESB startup. After copying the relevant jars to the relevant locations the server must be restarted.

8. resources
Contains additional resources required by WSO2 ESB.

9. samples
Contains the sample Axis2 server, sample Axis2 client, source code of the sample services and clients and the ANT scripts required to build and run them.

<parameter name="port">9443</parameter>

Test Automation and Selenium

Using a software to execute number of tests without human interaction is known as test automation. This involves comparing of predicted result to the actual result obtained, checking of GUI components and actions, and other testing control and creating test reports to indicate the summery of the tests. Although manual testing can find more defects compared to automation, test automation is a very efficient and cost effective process when doing quality assurance for software products which have a long maintenance life. The most important thing of test automation for products having long maintenance life is, when introducing new patches to upgrade the product, it may cause some other features to fail which were working properly before introducing the patch. Therefore to identify such defects we can say, test automation is the most efficient method.

Test automation is another software developing or coding process. Therefore it may also have bugs which cause properly working software functions may be considered as buggy. Because of that when doing test automation, we should make it a point to develop a bug free test framework for our requirement. And we should know automation is not always advantageous process in software quality assurance. Manual testing may be more appropriate in cases when the application or GUI get changed time to time, there is no time to automate tests, etc. Therefore we should carefully decide whether to automate or not our tests.


Selenium is a web application software testing framework which consists of set of tools for test automation. Selenium provides a rich set of testing functions for testing of a web application. There three major tools which power the selenium framework.

Selenium-IDE :

Selenium-IDE is the Integrated Development Environment use to develop Selenium test cases. It is implemented as a Firefox add-on and can be used to record, edit, and debug tests. For more details of how to install and use selenium IDE refer

Selenium-RC :

Selenium-RC can be used for tests that need more than simple browser actions and linear execution. This can be used to create more complex tests such as database accessing, file accessing, emailing test results, etc. For more details, refer


Selenium-Grid coordinates multiple instances of Selenium-RC are running on various operating system and browser configurations. Tests can be run on lot of platforms at the same time saving lot of time and allowing wider testing. For more details, refer

Beginning to the world of Web Services…

As I am a new to the software world, I have to learn from very basic level of software stuff. I got the opportunity to get knowledge on C language, basics of OOP with C++ during my university life and have done self studying on C# and Java.

And with my carrier opportunity at WSO2, I’m stepping in to the path of Web Services. At the beginning I had no idea about web services, but with the time I realized it is very interesting topic and thought to write this simple blog for the beginners to the web services world.

Revolution is the key of keeping computer industry in the highest demanding position. When we looked in to several years back very few people had access or used computers and applications of computers are very few. The introduction of Internet began to a new era of computer industry. Since then, standards such as HTML (the base protocol for viewing content on the Web) and HTTP (the associated software for browsing this content) have exponentially increased people’s use of the Internet and grew Web usage to what we are familiar with today. The Web became a key activity in the daily lives of businesses, employees, and consumers.

As a result of this, the industry wanted to have a standard way of building applications and processes to connect and exchange information over the Web. Because of that, web services was introduced to share data, integrate their processes, and join forces to offer customized , comprehensive solutions to their customers. The information of you or your business need will be available wherever you are, and whatever computing device, platform, or application you are using. Therefore web services enables a standard way of building applications and processes to connect and exchange information over the Web. Because of that, web services can convert our applications into web-applications which can be published, found, and used through the Web.

The heart of the web services solution is XML which is an open industry standard managed by the World Wide Web. It enables developers to describe data exchanged between PCs, smart devices, applications, and Web sites. Since the data is separated from the format of the data, it can be easily organized, programmed, edited, and exchanged between any Web sites, applications, and devices.

These are the basic elements of web services,

-A network

To make the web service to be available in web. Generally, this network is based on Hypertext Transfer Protocol (HTTP), but it can also be based on other protocols.

-XML-based messaging

To enable the communication between the web service and clients. Communication is done by exchanging XML-based messages. These messages are called SOAP messages. SOAP stands for Simple Object Access Protocol. SOAP is a specification that defines the XML format for messages. An XML fragment enclosed in a couple of SOAP elements is a SOAP message. In web services scenario, a SOAP message is sent inside an HTTP message. There’s no standard f or how a SOAP message is carried, and SOAP doesn’t care what the transport is. The SOAP specification defines what an HTTP message containing a SOAP message must look like. This is just like, print a SOAP message, fax it to a remote location, and type it into the remote machine without violating the SOAP standard.

-Web Service Description (WSD)

To describe the web service, where can it be found, what messages are accepted / generated what syntax and how those are encoded. Basically it provides a standard format to describe the web service. It represents an agreement of the mechanics of interacting with the service. WSDL (an XML-based language) is used to write WSD.

-Universal Description, Discovery and Integration (UDDI)

A directory service for storing information about web services described by WSDL where companies can register and search for Web services. UDDI communicates via SOAP messages.

The figure bellow shows a very basic architecture of web service

Service provider:

Provides the interface for the Web service and the implementation of the web application. The service provider is also responsible for creating the definition of the service and publishing that definition to meet the Universal Description, Discovery.

Discovery Agency:

A discovery agency is a way in which Web services are formally published. The discovery agency is based on the UDDI specification and contains information about services provided by the service provider. The discovery agency provides a service requester with a Web Services Description Language (WSDL) service description and a Uniform Resource Locator (URL) that points to the service.

Service requester:

A service requester is the consumer of a Web service and uses the service registry to gain information about, and access to, a Web service.

A service requester and service provider interact based on the service’s description information (WSDL) published by the provider and discovered by the requester through a discovery agency. Service requesters and providers interact by exchanging messages. XML messages with the SOAP specification are exchanged between the requester and provider. The provider publishes a WSDL file that contains a description of the message and endpoint information to allow the requester to generate the SOAP message and send it to the correct destination.

The service requester sends a message in the form of a request for information, or to perform an operation. Then the service provider receives the request, processed the message and sends a response. Then the service requester receives a message from the service provider that contains the result of the request or operation. This is the basic high level picture of web services.