Service Virtualization with Parasoft Virtualize 9.9.5

Software testing is an important aspect of the software application development cycle. Service virtualization plays a big role in software testing as it provides the user with the ability to test the application under various possible events which can be expected from the backend service. If the actual backend used by application is not ready to be integrated for testing that is one possible case where a virtualized service will be useful. One other important use of a virtualized service is imitating backend service failures and tests the application’s robustness under those failures. For example if we need to test whether our application will fail when the backend service is not available or not, a virtual asset can mimic a backend time out situation and this can be used to test our software.

1. Creating a Virtual Asset

Once Parasoft Virtualize is installed and license is activated, the first thing we need to do is creating a Virtual Asset (ask Virtual Service).  For that go to Virtual Assets -> Add New -> Virtual Asset .pva File

This will create a new Virtual Asset (referred as VA from here) in the workspace with a Responder Suite. Responder suite is the container where we are going to create one or more virtual responses to be returned to the client application.  In order to add a response we need to create a ‘Responder’.

        2. Adding a Responder to VA with URL Parameter Correlation

There are many type of Responders can be created from Parafost Virtualize. Some of the common examples are XML or JSON responders, Literal responders etc.  It is possible to add more than once responder to VA, and correlate it with an incoming http header, url parameter, request body element etc.  As the first steps let’s add a XML responder.  An XML responder will return an xml message when it is called. For this follow Responder Suite -> New tool -> Plain XML Responder. Then add a XML message to response body.

Now let’s correlate this XML responder to a url parameter which is coming from client application, so when the Virtual Asset is called client needs to pass that specific url parameter in the address if it needs to have XML responder in return. For that go to HTTP URL Parameters and select ‘enable correlation’. Then give a parameter name to correlate.

In order to get this XML response the client will call below address.

http://[virtual_server_host:port]/My_firstVA?response=1

         3. Adding a Responder to VA with HTTP Header based Correlation

If we need to return some response from VA based on the value of an incoming HTTP header, that can be done using header correlation. Let’s add the JSON Responder this time. Add a JSON response.

Then go to ‘Responder Correlation’ and add a header name (e.g. RESPONSE_JSON=true) and value which we need to correlate with. Then select ‘Enable Correlation’

             4. Change default HTTP_SC return status of the Responder

Assume that we need to test when a backend service fails and return HTTP Status as 500. It is not possible to break the real backend service for us to get 500 from it. So we can create a virtual responder which returns 500 and test our application using that. For this create the Response as explained in above, and go to Options -> Return Status. By default responder is configured to return HTTP 200 OK. Unclick that and then we can add whichever HTTP_SC code and message that needs to be returned with the Responder.

             5. Adding a delay to the Message Responder ( Modeling a backend timeout scenario)

A Responder in VA can be configured with a response time delay which can be used to test a backend timeout situation. First point the client application endpoint to the VA’s address. Then we can create a Responder and wait for certain amount of time before sending that response. For e.g if the endpoint timeout is 5 seconds, then give the Responder delay as 10 seconds. So when the VA is called it will wait for 10 seconds before send the response back to client application. By this time client’s endpoint will have timed out after 5 seconds.

           6. Hosting the VA in a Server

Now let’s test this Virtual service. By default the VA is already added to the local server. The ‘Servers’ pane in Parasoft Virtualize displays the existing servers list. You can add any remote servers to this too. 

          7. Testing the Virtual Service

I am using Chrome PostMan extension as the test client.  The URL of the service would be, http://localhost:9080/My_First_Virtual_Asset 

As there are many responders, I am going to test one response with a url parameter. Below is the full request/response in POSTMAN.

http://localhost:9080/My_First_Virtual_Asset?response=1

Mounting WSO2 ESB registry partitions into MySQL

By default WSO2 ESB comes with an embedded H2 database where the config and governance partitions of the registry is embedded there. In most of the production scenarios it is required to externalize these partitions to out of ESB for the convenience of managing registry resources. This post is a step by step guide on how to mount ESB registry partitions into a MySQL database.

1. Download MySQL JDBC connector
1. Installing MySQL
2. Create new registry database
3. Configure ESB to use externalized MySQL database

1. Download MySQL JDBC connector
The jdbc connector for MySQL can be downloaded by the link provided here. 

[https://dev.mysql.com/downloads/connector/j/5.0.html]
Extract the zip file and obtain the mysql-connector-java-5.0.8-bin.jar file.

2. Installing MySQL

There are two ways to install MySQL server in Windows 7. One is by downloading the MSI installer and the other option is downloading the mysql zip file.
I have used the option two below as it was quick. You can download the mysql ""Windows (x86, 64-bit), ZIP Archive"" using this link. 

[https://dev.mysql.com/downloads/mysql/5.5.html#downloads]

Once downloaded, extract it and go to \mysql-5.5.43-winx64\bin. Run the below command to start mysql server. This will start the MySQL service.

> mysqld.exe

After that execute below command to log in to mysql as root user. The default password is empty, so once prompted for password you can just press enter and login. If you need set a new root password later for increased security.

> mysql.exe -u root -p
Enter password: [Press Enter here as there is no password to type]
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 2
Server version: 5.5.43 MySQL Community Server (GPL)

That is all, you can use any mysql commands now to work with databases here.

3. Create a new database in MySQL server, which will be used as the external database for WSO2 ESB. I have given the name reg_db for this.

mysql> create database reg_db;
Query OK, 1 row affected (0.00 sec)

4. Configure ESB to use externalized MySQL database

The last step to do is pointing ESB to use this newly created MySQL database. Here we are going to link ESB with new sql database, so the entries written to config and governance spaces will be stored in reg_db mysql database from here onwards.

4.1  Copy the previously download jdbc connector jar into ESB_HOME/repository/components/lib folder.
4.2  Goto ESB_HOME/repository/conf/datasources and open the master-datasources.xml file. Add the below entry for a new datasource. Do not remove any existing entries too.
     We have to give username and password for the database. Since my MySQL password is empty i have kept <password></password>  without any value here.

        <datasource> 
            <name>WSO2_CARBON_DB_Reg</name> 
            <description>External DB used for registry and config spaces</description> 
            <jndiConfig> 
                <name>jdbc/WSO2CarbonDB_Reg</name> 
            </jndiConfig> 
            <definition type="RDBMS"> 
                <configuration> 
                    <url>jdbc:mysql://localhost:3306/reg_db</url> 
                    <username>root</username> 
                    <password></password> 
                    <driverClassName>com.mysql.jdbc.Driver</driverClassName> 
                    <maxActive>50</maxActive> 
                    <maxWait>60000</maxWait> 
                    <testOnBorrow>true</testOnBorrow> 
                    <validationQuery>SELECT 1</validationQuery> 
                    <validationInterval>30000</validationInterval> 
                </configuration> 
            </definition> 
        </datasource>

4.3 Goto ESB_HOME/repository/conf/registry.xml file and add a new dbConfig for remote MySQL database.

    <dbConfig name="mounted_registry"> 
        <dataSource>jdbc/WSO2CarbonDB_Reg</dataSource> 
    </dbConfig>
   
4.4 Add a new remoteInstance entry to the same registry.xml.

    <remoteInstance url="https://localhost:9443/registry"> 
        <id>instanceid</id> 
        <dbConfig>mounted_registry</dbConfig> 
        <readOnly>false</readOnly> 
        <enableCache>true</enableCache> 
        <registryRoot>/</registryRoot> 
        <cacheId>root@jdbc:mysql://localhost:3306/reg_db</cacheId> 
    </remoteInstance>   

4.5 Add the mount configurations to registry.xml as below.

    <mount path="/_system/config" overwrite="true"> 
        <instanceId>instanceid</instanceId> 
        <targetPath>/_system/nodes</targetPath> 
    </mount> 
    <mount path="/_system/governance" overwrite="true"> 
        <instanceId>instanceid</instanceId> 
        <targetPath>/_system/governance</targetPath> 
    </mount>
   
That is all. Now when you restart the ESB server, go to the Registry menu from the admin console. When you 'Browse' the registry the icons for config and governance spaces would look like below.

 

The blue arrow in the icons mean those partitions are now pointed into an external database.

Now if you goto the mysql console and try to see the tables that in the 'reg_db' database, it is now loaded with list of new tables as below.

mysql> use reg_db;
Database changed
mysql>
mysql> show tables;
+-----------------------+
| Tables_in_reg_db     |
+-----------------------+
| reg_association       |
| reg_cluster_lock      |
| reg_comment           |
| reg_content           |
| reg_content_history   |
+-----------------------+
39 rows in set (0.00 sec)

[WSO2 ESB] Comparing two XMLs and find matching elements using WSO2 ESB 4.8.0

Imagine we are getting a list of xml data from an external service and it is required to match this response against another xml payload and find the matching xml elements inside ESB 4.8.0. For e.g. a user send the below request into ESB.
<Accounts>
    <acctNum>123452</acctNum>
    <acctNum>678912</acctNum>
</Accounts>

Inside ESB we are calling an Account DB service which retrieves all the Account elements inside the database and return us. Assume the BE response with Account details is as follows.

<a123: Accounts xmlns:a123="http://test123.com>

    <a123:Account>
        <a123:AcctNum>123451</a123:AcctNum>
        <a123:Date>2014-03-26</a123:Date>
    </a123:Account>
    <a123:Account>
        <a123:AcctNum>123452</a123:AcctNum>
        <a123:Date>2014-04-20</a123:Date>
    </a123:Account>
</a123:Accounts>   
   
Once this response comes into ESB it is required to compare the two xmls and retrieve Account elements that matches with account numbers which are in incoming request. We can do this through an iterate mediator inside ESB too, however the way that is explained here is rather simple to be used, specially for a scenario when it is not possible to use Iterate mediator.

1. When the incoming request comes, we can use xpath to get a comma separated String with all account numbers in the request. Then assign it to a Property mediator.

<property name="accountsList" expression="string-join(//Accounts/acctNum, ',')" scope="default" type="STRING"/>
This XPath expression uses string-join() function from Xpath 2.0. Therefore it is required to enable the below property in ESB/repository/conf/synapse.properties file in order to support Xpath 2.0

# Uncomment following to support fallback XPATH 2.0 support with DOM and Saxon
synapse.xpath.dom.failover.enabled=true   
   
2. Once this property is set we can call the BE and get the Account details response. Then the response payload will be passed to the given XSLT stylesheet using XSLT mediator in ESB.
Also as there is comparison needs to be done here, i am passing the previous 'accountsList' property as a parameter into XSLT stylesheet as well.

<xslt key="MatchingAccounts">
    <property name="AccountsList" expression="$ctx:accountsList"/>
</xslt>
   
3. The stylesheet is added as a local-entry in the ESB with the name 'MatchingAccounts'. If needed you can add this as a Registry resource too.

<localEntry xmlns="http://ws.apache.org/ns/synapse" key="MatchingAccounts">
<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:a123="http://test123.com xmlns:fn="http://www.w3.org/2005/xpath-functions" version="2.0">
        <xsl:param name="AccountsList"/>
        <xsl:output method="xml" indent="yes"/>
        <xsl:template match="/">
            <Result xmlns="">
                <xsl:for-each select="//a123:Account">
                    <xsl:if test="matches($AccountsList,a123:AcctNum)">
                        <xsl:copy-of select="."/>
                    </xsl:if>
                </xsl:for-each>
            </Result>
        </xsl:template>
</xsl:stylesheet>   
</localEntry>
   
4. Inside the style sheet if process through each a123:Account/a123:AcctNum element and checks whether the 'accountsList' String contains that account number. If there is a match that <Account> node is taken as results.

5. For the above two XMLs the final payload that comes outside XSLT mediator will be like this, with one matching Account node.
<Result xmlns="">
    <a123:Account>
        <a123:AcctNum>123452</a123:AcctNum>
        <a123:Date>2014-04-20</a123:Date>
    </a123:Account>
</Result>

[WSO2 ESB] Sending Form Data through WSO2 ESB with x-www-form-urlencoded content type

This post is about how to post form data into a REST service from WSO2 ESB 4.8.1.
Imagine that we have the following key values pairs to be passed into a REST service  which accepts x-www-form-urlencoded type data.

name=ishara&company=wso2&country=srilanka

Now when we going to send these data into ESB, it is needed to set them as key values pairs through adding a PayloadFactory mediator in the following format.  

<property name="name" value="ishara" scope="default" type="STRING"/>
<property name="company" value="wso2" scope="default" type="STRING"/>/>
<property name="country" value="srilanka" scope="default" type="STRING"/>/>
            
<payloadFactory media-type="xml">
                <format>
                    <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">
                        <soapenv:Body>
                            <root>
                                <name>$1</name>
                                <company>$2</company>
                                <country>$3</country>                               
                            </root>
                        </soapenv:Body>
                    </soapenv:Envelope>
                </format>
                <args>
                    <arg evaluator="xml" expression="$ctx:name"/>
                    <arg evaluator="xml" expression="$ctx:company"/>
                    <arg evaluator="xml" expression="$ctx:country"/>
               </args> 
</payloadFactory>           

Then set the messageType property as 'application/x-www-form-urlencoded'. This is how ESB can identify these key-value pairs as form data and it will do the transformations. Then it is also required to disable chunking too.
            
<property name="messageType" value="application/x-www-form-urlencoded" scope="axis2" type="STRING"/>
<property name="DISABLE_CHUNKING" value="true" scope="axis2" type="STRING"/>
                       
Now we are all set to call the REST endpoint with this message data as below. You can use either send or a call mediator.

<call>
   <endpoint key="conf:endpoints/EmployeeDataServiceEndpoint.xml"/>
</call>
                       

[WSO2 ESB] Enrich Mediator Patterns

WSO2 ESB Enrich Mediator can process a message based on a given source configuration and then perform the specified action on the message by using the target configuration. The following post specifies some of the source/target patterns that can be used with Enrich mediator. The flow is explained in 'description' element of each mediator entry to make it easily understandable.

1. Adding a property value into message body as a sibling

<property name="failureResultProperty" scope="default" description="FailureResultProperty">
        <result xmlns="">failure</result> 
</property>
<enrich>
        <source xpath="$ctx:failureResultProperty"/>
        <target type="body" action="sibling"/> 
</enrich>   
   
2. Append new elements into a property using two enrichs

<property name="testMessages" scope="default" description="Test Messages Property">
        <testMessages/> 
</property>
          
<property name="testMsg" expression="//testMessage" scope="default" type="OM"/>

<enrich description="Get testMessages into current msg body">
            <source type="property" property="testMessages"/>
            <target type="body"/> 
</enrich>
<enrich description="Append testMsg into testMessages property">
            <source xpath="$ctx:testMsg"/>
            <target type="body" action="child"/> 
</enrich>

<property name="testMessages" description="Set testMessages property back"  expression="//testMessages" scope="default" type="OM"/>
       
       
The final output for 'testMessages' property after enriching will be like this.

 

 
3 . Append direct to a property using single Enrich.
   
<property name="testMessages" scope="default" description="Test Messages Property">
        <testMessages/> 
</property>
<enrich>
            <source xpath="//testMessage"/>
            <target action="child" xpath="$ctx:testMessages"/>
 </enrich>
    

[WSO2 ESB] How to Read Local Entries and Registry Entries

This post is rather a quick note to my self. In WSO2 ESB we can have external reference to a file using either a local entry or a registry entry. 

Local-entry :

An entry stored in the local registry. The local registry acts as a memory registry where you can store text strings, XML strings, and URLs. These entries can be retrieved from a mediator.

Registry-entry :
WSO2 ESB makes use of a registry to store various configurations and artifacts such as sequences and endpoints. A registry is a content store and a metadata repository. Various SOA artifacts such as services, WSDLs, and configuration files can be stored in a registry and referred to by a key, which is a path similar to a UNIX file path.

1. This is how we can read some value stores in a local-entry. Let's say i have a value stored in local-entry file 'testEntry'.

<localEntry xmlns="http://ws.apache.org/ns/synapse" key="testEntry">12345</localEntry>

 This is how we can read this value into a mediator.

<property name="testProp" expression="get-property('testEntry')" scope="default" type="STRING"/>

2. If this 'testEntry' file is stored in the registry we have to use 'registry' scope with get-property() XPath extension function and read entry as below.

<property name="testProp" expression="get-property('registry', 'conf://custom/testEntry')" scope="default" type="STRING"/>

[WSO2 ESB] Property mediator : Performing XPath Expressions with and without Namespaces

Assume that we have an XML payload where there are several namespaces defined and we need to retrieve values of some elements from the payload into Properties using XPath. There are several ways to do this. We can either define the namespace in the property mediator and then refer to XML element via XPath with adding the namespace itself into the Xpath operation. let's get started with this.

Below is our payload.

<abc  xmlns="http://abc.xyz.com" >
         <A>YES</A>
         <B>{"abc":"Y","d":"N","e":"N"}</B>
</abc>

For e.g i need to read the value 'A' into a property.  Following are the two ways for this However the 2nd option is more cleaner approach since we can get rid of adding namespace references every where. In addition to Property mediator, this can be used with other mediators in WSO2 ESB whether XPath operations are supported.

1. Use name space entries with property mediator

<property  xmlns:ns="http://abc.xyz.com" name="aValue" expression="//ns:abc/ns:A" scope="default" type="STRING"/>

2. Use local-name() option in XPath in order to avoid name spaces and get the same element value with property mediator.

<property name="aValueWithoutNS" expression="//*[local-name()='A']" scope="default" type="STRING"/>


 

[WSO2 ESB] XSLT mediator : Writing a simple style sheet

The XSLT Mediator of WSO2 ESB applies a specified XSLT transformation to a selected element of the current message payload. In this post i am going to write a simple XSLT style sheet which will read values from the current XML payload inside ESB using XPath and populate them into style sheet to create a new or different payload.

Below is our original XML payload.

We will be passing this payload into XSLT mediator with specifying a certain drink name as a parameter to the style sheet. For e.g i am passing drink name as 'Coffee'. At the style sheet it will traverse through incoming payload and find the <lunch> elements which contains 'Coffee' as drink name. If matches found we add the prices of those elements under a new <Payment> element. So when we come out of XSLT mediator the payload will be now changed to the <Payment> entry where it contains drinkPrices of matching elements.

The style sheet 'discountPayment.xsl' is like this.

<xsl:stylesheet xmlns:xsl="http://www.w3.org/1999/XSL/Transform" xmlns:fn="http://www.w3.org/2005/02/xpath-functions" xmlns:m0="http://services.samples" version="2.0" exclude-result-prefixes="m0 fn">
        <xsl:output method="xml" omit-xml-declaration="yes" indent="yes"/>
        <xsl:param name="drink_name"/>
        <xsl:template match="/">
            <Payment>
                <xsl:for-each select="//Order/lunch[contains(drinkName, $drink_name)]">
                    <discount>
                        <xsl:value-of select="drinkPrice"/>
                    </discount>
                </xsl:for-each>
            </Payment>
        </xsl:template>
</xsl:stylesheet>

Add this style sheet into local-entries of ESB and it can be referred from XSLT mediator as this.

After coming out from XSLT mediator now our current message payload is changed to below.

[WSO2 ESB] Using [resource] attribute for [xsd:import] elements in a scheme file with Validate Mediator

The Validate Mediator in WSO2 ESB is used for schema validation of messages. Then this message is validated against the schema specified.

When we use validate mediator against a schema that schema file itself can contain some other schema references under <xsd:import> elements like below.

If our schema file is like this, in this scenario validate mediator tries to map and find the internal schemas which are defined in <xsd:import> elements. If these cannot be found, ESB will log an error saying that "The resource "{resource_file_name} can not be located"

Therefore in order to use these schema files with validate mediator follow the steps given below.

1. First add all the xsd files as local entries to ESB. These is no relative paths or nested folders supported so the xsd files has to be in local-entries folder itself. However if you put the schemas into registry nested folders are supported.

2. In the validate mediator there is an attribute called <resource>. Use this option to tell the validate mediator on where to find the files to import as below. Make sure ‘location’ and ‘schemaLocation’ entries has the same file name in order to map those correctly. Then the 'key' attribute is used to specify the current location of this schema file as shown in the given exmaple.

If you have added the schema files as registry entries, and when there are relative paths mentioned in parent schema, validate mediator can be used in  the following manner.

WSO2 Message Broker 2.2.0 - An Overview of Newest WSO2 MB Release

After months of hard work we, WSO2 Message Broker team finally completed and released the version 2.2.0 of WSO2 MB, with several community demanded new features and improvements.

The release was initially planned to be go out with two main features namely Dead Letter Channel and Publisher Flow Control. However as the time goes we were able to introduce several more features listed as Cassandra and Zookeeper Profiles support with MB, Message Selectors and Dynamic Queue Support as well as improved SSL and Failover support and a lot more. Below is a quick overview of the newly released WSO2 MB 2.2.0 version. 

The complete information can be found in MB 2.2.0 official documentation which describes each of below feature in detail.

WS02 MB 2.2.0 New Admin Console

What comes new ???

First let's download WSO2 MB 2.2.0 version to experience the new features. Now we are ready go through the list  :)

๏ Dead Letter Channel implementation

The Dead Letter Channel (DLC) is specifically designed to persist messages that are faulty or rejected by the message receivers, providing you with a choice on whether to delete, retrieve or reroute the messages from the DLC. If the subscriber rejected the message, did not ack the sever within a configured time or could not receive message due to connection fail first MB erver will try to resend the message.After doing this for a maximum number of configured times  the message will be routed to DLC.

A user can perform following actions on DLC messages

• Delete (discard mal-formatted message)
• Restore message to the original queue 
• Re-route the message to any other existing queue in MB cluster

๏ Publisher Flow control implementation

Flow control ensures that the rate at which messages are transmitted from the publisher to the receiver is controlled. Back-pressure is exerted when the defined global memory threshold or message count threshold per connection is exceeded. At this point, message acceptance is blocked until the sender is notified of memory recovery.  If the memory is not recovered within a specified time interval 'qpid.flow_control_wait_failure' which is by default 120s (2 mins), all currently publishing clients will be disconnected. But the subscriber clients will be able to continue.

The users are able to increase/decrease this wait time as needed by setting system property 'qpid.flow_control_wait_failure' at client-side. This value is 'long' type.

WSO2 MB 2.2.0 comes with following flow control mechanisms.
1. Throttling based on global memory threshold
2. Throttling based on message count per connection

๏ MB profile support for Cassandra and Zookeeper

With the previous MB releases it was required to download Cassandra and Zookeeper from external sites and point MB to be run with those. From 2.2.0 onwards this is no longer needed and you can start WSO2 MB purely as a Apache Cassandra server. All configurations files of Cassandra are there plus the port is configurable with an offset. The logs related to Cassandra are written to wso2carbon.log file as well as we have introduced a new log file specially for Cassandra system logs, as <MB_HOME>/repository/logs/cassandra_system.log file. Cassandra tools such as nodetool,cassandra-cli scripts are also packed inside MB. Also now you can start WSO2 MB purely as a Apache Zookeeper server. Hence in order to create a complete message broker cluster the users only need a WSO2 MB distribution.

๏ JMS message selectors support

Message selectors allow you to filter specific messages using a selector string. The message consumer will then receive only messages whose headers and properties match the selector. There are different patterns that can be used in selector strings, and the broker (JMS provider) filters messages according to that query. It is not possible for a message selector to filter messages on the basis of the content of the message body.

๏ Queue/Topic Permission model 

The role permission list is modified now the admin can explicitly set the each permissions like create queue/browse queue etc. inside a role. Therefore now when you create a queue/topic it can be selected whether this user can publish/subscribe to the created queue or topic.

WSO2 MB 2.2.0 Permission Model

๏ Dynamic queue support

In previous Message Broker releases users needed to create a subscriber or create the queue from admin console before start publishing messages to that queue and if not messages will be lost. Now this is  improved with dynamic queue support that when the publisher client initiates the queue is created in the broker, even if there are no consumers. The create queue segmant of message publisher would be as follows.

        QueueConnectionFactory connFactory = (QueueConnectionFactory) ctx.lookup(CF_NAME);
        QueueConnection queueConnection = connFactory.createQueueConnection();
        queueConnection.start();
        QueueSession queueSession =
                queueConnection.createQueueSession(false, QueueSession.AUTO_ACKNOWLEDGE);
        // create queue
        Queue queue =  queueSession.createQueue("Queue-MB");
        // create the message producer for queue
        javax.jms.QueueSender queueSender = queueSession.createSender(queue);

๏ Improved SSL support

The wire level connection between client-server of broker can be encrypted using SSL to provide maximum protection where this is supported in both standalone and clustered mode with failover as well. The SSL properies are easily configurable at the client side using AMQP connection url.

๏ Improved logging 

Trace level logs are now separated for easy debugging. In addition there are two more log files have been introduced for Cassandra and Zookeeper profiles named, cassandra_system.log and zookeeper.log file.

๏ Queue/Topics Subscription UI

A new segmant is introdued to WSO2 MB 2.2.0 admin console as shown in above image to view active/inactive queue and topic subscriptions for whole MB cluster. The following details are displayed in the new UI.

• View active topic subscriptions in whole MB cluster 
• View inactive durable topic subscriptions specifically.
• Ability to unsubscribe inactive durable topic subscriptions with UI.

Queue/Topic Subscriptions UI

Apart from these major changes there are a lot of bug fixes and improvements in the new release. It was a great and hard team work for the last few months for all of us ( there are a lot in the team including our QA crew) to finally get the 2.2.0 release out. It is really proud to be a part of my team and we are now gearing up for WSO2 MB 3.0.0 which will be coming out as a complete revamped architecture. Looking forward for 3.0.0 :) :)

[Quick Note] Modifying Git Configurations in Ubuntu and Windows

OS : Ubuntu 13.10 or Windows 7

This is a brief post on how to change default configuration entries for Git.

There might be requirements that you need to change the default username where the commits get written to github, specially if you created a new github account, changed email etc.

Git uses global configuration file called .gitconfig in order to store the global credentials. To change the default user you can simply edit this file.

isha@thinkpad:~$ vim .gitconfig

For Windows this file can be found in file: git/etc/.config location.
I have set the following three properties here.

 1. username: github username of author.
 2. user email: github email address of user.
 3. credential helper: turn on the credential helper so that Git will save your password in memory for some time. By default Git will cache your password for 15 minutes. You can change this by changing --timeout property in the command.

[user]
        name = ishadil
        email = ishadil@github.com
[credential]
        helper = cache --timeout=3600  // i have changed timeout for 1 hour

Other option is doing this using the command prompt as below.

git config --global user.name "ishadil"

git config --global user.email "ishadil@github.com"

git config --global credential.helper 'cache --timeout=3600'

After that use git config --global --list command to verify whether the properties are reset correctly.

git config --global --list

In a similar manner there are lot more configuration entries that can be set into this file. For e.g. let's set a proxy url in to git .config file.

[http]
    proxy = proxy-test.abc.com:8080

WSO2 ESB Performance Round 7.5 is now released ......

As the Enterprise Service Bus 4.8.1 version was out in early February this year WSO2 ESB team has carried out a latest ESB Performance round, which results in that the newly released WSO2 ESB clearly outperforms other ESBs in the current market. The ESB Performance round 7.5 testing was conducted on an Amazon c1.xlarge EC2 instance of a 64-bit instance with 8 cores, 20 ECUs, and 7GB of memory.

The following table and graph show the summary results which is drawn against 'Average TPS Values' per 'Proxy Service' of the performance test. In summary it can be stated that,

• As shown in the graphs below, WSO2 ESB 4.8.1 is the fastest in performance compared to all the other ESBs here, except for the security scenario.

1.


2.



The 'ESB Performance Round 7.5' article in the WSO2 Library provides a comprehensive report of the complete test round. 

Securing a Proxy Service in WSO2 ESB using a Username and passwordDigest (Hashpassword)

In this post i am going to explain how to secure a simple proxy service in WSO2 ESB 4.7.0 to be authenticated with UsernameToken method with using the username and hashpassword.

The HashPassword or NoPassword options are defined with WS-Policy 1.2 specification onwards. Therefore in order to have this feature we need to write a policy file using WS-Policy 1.2 spec.

First let's create a simple pass through proxy and make it secured.

1. Add a new pass through proxy  and specify an endpoint of a running service there. I have used SimpleStockQuoteService which can be run in <ESB_Home>/samples/axis2Server/src/SimpleStockQuoteService. Build the service using 'ant' and start the Axis2 server by,

cd ESB_home/samples/axis2Server $ sh axis2Server.sh 

2. After this go to the list of service in the UI. You will see that 'StockQuoteSecure' service is displayed as "Unsecured". Click on this link and it will redirect to a page where you can enable security to this service. Enable security there and select UsernameToken as the basic authentication mechanism as shown in the image below. After that goto next page and select the user groups who can access this service.

3. Once you finish this, WSO2 ESB admin console will display the service as secured, and we can only invoke this service using https:// endpoint now.

4. Next we need to change a default UsernameToken policy of the service and make it able to validate Hashpasswords. Goto the service dashboard of the secured service by clicking on it. Under the 'Quality of Service Configuration' section 'Policies' will be defined.

5. When you click on 'Policies' link it will be redirected to edit the current policy. Find 'StockQuoteSecureSoap11Binding' tab in here and click on 'Edit Policy' button as shown below.

6. Now let's define our new policy here. Copy the Following policy configuration and replace the existing policy definition with this one.

Save the policy back.

    
        
            
                
                    
                        
                    
                
                
                    
                        
                    
                
                
                    
                        
                    
                
                
            
        
        
            
                
                    
                        
                        
                    
                
            
        
        
            useReqSigCert
	    admin
	    org.wso2.carbon.digestpwd.PWCBHandler
        
    

7. The StockQuoteSecure service is secured now and is configured to use Username and Hashpassword for authentication.

8. As defined in the policy configuration, it uses org.wso2.carbon.digestpwd.PWCBHandler class to validate the user. Here i have written PWCBHandler.java class which can validate the default 'admin' user of WSO2 ESB.  Before trying to invoke the proxy service we need to add this PWCBHandler-1.0.jar client library into <ESB_Home>/repository/components/lib directory. You can download the jar from here.

[ The above sample PWCBHandler class is written to validate the 'admin' user only. According to your requirements you can write a customized PasswordCallBackHandler class which validates a set of registered users etc. in similar manner. ]

9. Now we can invoke the secured service using a Client, and i have used SOAP UI as the sample client here. Create a new SoapUI project by using SimpleStockQuoteService.wsdl file attached here. Then use any of the operations defined in the SimpleStockQuoteService and send a request to oure secured proxy service using SoapUI. Before sending the request enter the following values as Request Properties.

Username: admin

Password: admin

WSS-Password Type: PasswordDigest

WSS Time to Live: 2000

10. Once sent the request there will be a response message  returned from SimpleStockQuoteService which implies that the Usename/Hashpassword combination is authenticated successfully.

Using WSO2 Message Broker with RabbitMQ C# .Net Client

As WSO2 Message Broker supports AMQP (Advanced Message Queuing Protocol) v 0.91 standard, this can be used to provide interoperability between different platforms via AMQP clients written on different languages. This blog post is about how to connect with WSO2 MB 2.1.0 using a C# .Net client and perform Queue/Topic based operations on Message Broker. 

In order to connect with MB first we need to find a C# .Net client library which supports AMQP standards. I have used RabbitMQ .Net client library here for this purpose.

1. How to Publish/Subscribe to Queues via .Net client

 

The following tutorial in WSO2 Library provides a complete guide on how to perform Queue operations  in by connecting to WSO2 MB via the .Net client. Therefore i am not going to repeat it here and let's see how to use manipulate Topics with a C# .Net client.

2. How to Publish/Subscribe to Topics via .Net client

 

The main difference between  connecting to a Topic and a Queue is, by default in WSO2 MB they use two different exchanges in order to connect with Queue and Topics. Therefore if you need to connect to a Queue/Topic, first it needs to be bound to the 'Exchange' in the broker by specifying the exchange name. There are two default exchanges used in WSO2 Message Broker.

• 'amq.direct' : The pre-defined direct exchange, used with Queues
• 'amq.topic'  :  The pre-defined topic exchange, used with Topics

You can still define and create new exchanges if needed, however they need to be first added into <MB_Home>/Repository/conf/advanced/qpid-virtualhosts.xml file under the <exchanges> section as the example below. However it is usually recommended to use the default direct/topic exchanges.

       
    
        
           direct
           carbon.direct
           true
       
       
            topic
            carbon.topic
       
  

Now let's get back to writing our sample code.

I. The following is a sample client code to publish into  a Topic in the broker. The code itself includes self-explanatory comments which describe its functions.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using RabbitMQ.Client;
 
 
namespace MB_Topic_Publisher
 
{
 
    class TopicPublisher
 
    {
        static void Main(string[] args)
 
        {
            TopicPublisher topicPublisher = new TopicPublisher();
            topicPublisher.PublishMessage("Test Message");
            Console.WriteLine("Message Sent..");
            Console.ReadLine();
        }
 
        public void PublishMessage(string message)
 
        {
 
//Setup the connection with the message broker
            ConnectionFactory factory = new ConnectionFactory();
            IProtocol protocol = Protocols.AMQP_0_8_QPID;
            factory.VirtualHost = "/carbon";
            factory.UserName = "admin";
            factory.Password = "admin";
            factory.HostName = "localhost";
            factory.Port = 5672;
            factory.Protocol = protocol;
 
            using (IConnection conn = factory.CreateConnection())
 
            {
                using (IModel ch = conn.CreateModel())
                {
 
// Declare a topic exchange to publish messages, here we have used the default topic exchange of WSO2 MB
                 ch.ExchangeDeclare("amq.topic", "topic");
 
// Publish the message to the exchange, it will send it to the routing key which is our name 'myTopic'.
// The syntax is ch.BasicPublish(exchange_name, topic_name, message_properties,message_body)
                 ch.BasicPublish("amq.topic", "test-topic", null, Encoding.UTF8.GetBytes(message));
 
                }
            }
        }
    }
}



II. Then let's write the sample client code to consume messages from  a Topic in the broker.

using System;
using System.Collections.Generic;
using System.Linq;
using System.Text;
using RabbitMQ.Client;
 
namespace MB_TopicClient
 
{
    class TopicConsumer
    {
        static void Main(string[] args)
       {
            TopicConsumer topicConsumer = new TopicConsumer();
            topicConsumer.getMessages();
        }
 
        public void getMessages()
        {
 
//Setup the connection with the message broker
            ConnectionFactory factory = new ConnectionFactory(); 
            IProtocol protocol = Protocols.AMQP_0_8_QPID;
            factory.VirtualHost = "/carbon";
            factory.UserName = "admin";
            factory.Password = "admin";
            factory.HostName = "localhost";
            factory.Port = 5672;
            factory.Protocol = protocol;
 
            using (IConnection conn = factory.CreateConnection())
            {
                using (IModel ch = conn.CreateModel())
 
                {
// Declare a topic exchange to be bound to retrieve messages, here we have used the default topic exchange of WSO2 MB
                    ch.ExchangeDeclare("amq.topic", "topic");
             
// Declare a topic name, here we use a non-durable topic. To make it durable use the 2nd parameter as 'true' 
                    ch.QueueDeclare("test-topic", false, false, false, null);
  
// Bind the Topic in to the exchange
                    ch.QueueBind("test-topic", "amq.topic", "test-topic");
                     
// Declare a consumer which listens on the messages published to 'test-topic' topic, we need to declare an exclusive subscriber, in order to get this work.
// The syntax is BasicConsume(queuename, noAck,consumerTag, noLocal, exclusive, arguments, Consumer)                      
                     
                    QueueingBasicConsumer consumer = new QueueingBasicConsumer(ch);
 
                    ch.BasicConsume("test-topic", false, "1", false, true, null, consumer);
                    while (true)
                    {
                        try
                        {
                            RabbitMQ.Client.Events.BasicDeliverEventArgs e =(RabbitMQ.Client.Events.BasicDeliverEventArgs)consumer.Queue.Dequeue();
                            byte[] body = e.Body;
                            string message = Encoding.UTF8.GetString(body);
                            Console.WriteLine(message);
                            ch.BasicAck(e.DeliveryTag, false);
 
                        }
                        catch (OperationCanceledException e)
                        {
                            Console.WriteLine(e);
                            break;
                        }
                     }
                }
            }
        }
    }
}



3. Download and Running the sample

To run the clients first run the sample Topic Consumer where it will create a new topic subscription for the 'myTopic'. After the when you run the sample Topic Publisher client, the consumer will receive the message published and will display it in the console as "Test Message".

The complete source code along with the RabbitMQ.Client.dll library can be downloaded from here too.

4. A guide to RabbitMQ .Net library API

If you need to learn on how to use the API to customize the sample Publisher and Consumer before using it with WSO2 Message Broker, refer the guides given below. 

• RabbitMQ .Net client v2.8.4 API Guide : find here 
• RabbitMQ .Net client v2.8.4 User Guide : find here

Writing a Node.js Client to Send/Receive messages with WSO2 Messge Broker

WSO2 Message Broker supports AMQP protocol 0-9-1. If you need to use Node.js client to publish/subscribe to Message Broker this can be done with using any compatible Node.js AMQP 0-9-1 Client Library. Some of the examples i found are,

1. amqp.node : https://github.com/squaremo/amqp.node
2. node-amqp : https://github.com/postwait/node-amqp

First of all we need to install Node.js if we haven't done it yet. The following page explains how to install Node.js in Ubuntu.

$ sudo apt-get install python-software-properties python g++ make 

$ sudo add-apt-repository ppa:chris-lea/node.js 

$ sudo apt-get update $ sudo apt-get install nodejs

Then add 'amqplib' module to get enable the functions in 'node.amqp' library.

$ npm install amqplib

The following sample code, written using amqp.node library can be used now as a NodeJS client to publish or receive messages from WSO2 Message Broker. You have to use the format amqp://{username}:{password}@{hostname}:{port} to establish a connection with Message Broker. All messages will be sent as byte messages but can be received as text.

'amqp.node' library provide a rich API which can be used to other Queue operations MB too.

  

A Sample Node.js Queue Publisher for WSO2 MB

    
    var queuename = 'MyQueue'; 

    var openConn = require('amqplib').connect('amqp://admin:admin@localhost:5672'); 

    // amqp://{username}:{password}@{hostname}:{port} is default AMQP connection URL of WSO2 MB 

    openConn.then(function(conn) { 

    var ok = conn.createChannel(); 

    ok = ok.then(function(channel) 

    { channel.assertQueue(queuename); 

    channel.sendToQueue(queuename, new Buffer('New Message')); }); 

    return ok; 

    }).then(null, console.warn);  

A Sample Node.js Queue Consumer for WSO2 MB

var queuename = 'MyQueue'; 

    var openConn = require('amqplib').connect('amqp://admin:admin@localhost:5672'); 

    // amqp://{username}:{password}@{hostname}:{port} is default AMQP connection URL of WSO2 MB 

    openConn.then(function(conn) { 

    var ok = conn.createChannel(); 

    ok = ok.then(function(channel) { 

           channel.assertQueue(queuename); 

    channel.consume(queuename, function(msg) { 

    console.log(msg.content.toString()); 

    channel.ack(msg); }); 

    }); 

    return ok; 

    }).then(null, console.warn);