Friday, September 5, 2014

Install SVN on RedHat Linux RHEL and configure DepSync on WSO2 worker manager nodes

  • After loggin in change the user into root user 
    • sudo -i 
  • You can install required packages using (This command will install Apache if its not already installed)
    • yum install mod_dav_svn subversion 
  • After this step SVN will be installed in the server and now we can configure it :) 
    • Navigate to /etc/httpd/conf.d/subversion.conf and modify it as below

LoadModule dav_svn_module modules/mod_dav_svn.so
LoadModule authz_svn_module modules/mod_authz_svn.so<Location /svn>
<Location>
   DAV svn
   SVNParentPath /var/www/svn
   AuthType Basic
   AuthName "Subversion repositories"
   AuthUserFile /etc/svn-auth-users
   Require valid-user
</Location>
  • You can create SVN users using following commands 
    • htpasswd -cm /etc/svn-auth-users testuser
  • This will request password for for the user
  • Now finally since we sucessfully installed SVN created SVN user next we can create the repository :) 
    • mkdir /var/www/svn
    • cd /var/www/svn
    • svnadmin create mySvnRepo
    • chown -R apache.apache mySvnRepo
  • Next we need to restart the Apache server 
    • service httpd restart
Goto http://localhost/svn/mySvnRepo address using your browser. Now by giving the SVN user credentials you can login to the repo and view the content.


Once you provided the credentials you will be able to check the your repository and the content if any,


    Now lets configure WSO2 servers as Manager and Workers

Enabling DepSync on the manager node

You can configure DepSync in the /repository/conf/carbon.xml file on the manager node by making the following changes,

<DeploymentSynchronizer>
    <Enabled>true</Enabled>
    <AutoCommit>true</AutoCommit>
    <AutoCheckout>true</AutoCheckout>
    <RepositoryType>svn</RepositoryType>
    <SvnUrl>http://localhost/svn/mySvnRep/</SvnUrl>
    <SvnUser>testuser</SvnUser>
    <SvnPassword>testpass</SvnPassword>
    <SvnUrlAppendTenantId>true</SvnUrlAppendTenantId>
</DeploymentSynchronizer>

Enabling DepSync on the worker nodes

In worker node you need to set the AutoCommit property to false as below,

<DeploymentSynchronizer>
    <Enabled>true</Enabled>
    <AutoCommit>false</AutoCommit>
    <AutoCheckout>true</AutoCheckout>
    <RepositoryType>svn</RepositoryType>
    <SvnUrl>http://localhost/svn/mySvnRep/</SvnUrl>
    <SvnUser>testuser</SvnUser>
    <SvnPassword>testpass</SvnPassword>
    <SvnUrlAppendTenantId>true</SvnUrlAppendTenantId>
</DeploymentSynchronizer>

[1] https://docs.wso2.com/display/CLUSTER420/SVN-based+Deployment+Synchronizer
[2] www.if-not-true-then-false.com/2010/install-svn-subversion-server-on-fedora-centos-red-hat-rhel

Friday, June 13, 2014

WSO2 ESB - JSON to SOAP (XML) transformation using Script sample


  • Reqired SOAP request as generated using SoapUI
 <?xml version="1.0" encoding="utf-8"?>  
 <soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/">  
 <soapenv:Body>  
 <m:newOrder xmlns:m="http://services.com">  
 <m:customerName>WSO2</m:customerName>  
 <m:customerEmail>customer@wso2.com</m:customerEmail>  
 <m:quantity>100</m:quantity>  
 <m:recipe>check</m:recipe>  
 <m:resetFlag>true</m:resetFlag>  
 </m:newOrder>  
 </soapenv:Body>  
 </soapenv:Envelope>  

  • The object that I used to test on Advanced REST Client[2]:

POST request
Content-Type   : application/json
Payload           : {"newOrder": { "request": {"customerName":"WSO2", "customerEmail":"customer@wso2.com", "quantity":"100", "recipe":"check", "resetFlag":"true"}}}


  • Proxy configuration

 <?xml version="1.0" encoding="UTF-8"?>  
 <proxy xmlns="http://ws.apache.org/ns/synapse"  
 name="IntelProxy"  
 transports="https,http"  
 statistics="disable"  
 trace="disable"  
 startOnLoad="true">  
 <target>   
 <inSequence>  
 <script language="js"><![CDATA[  
 var customerName = mc.getPayloadXML()..*::customerName.toString();  
 var customerEmail = mc.getPayloadXML()..*::customerEmail.toString();  
 var quantity = mc.getPayloadXML()..*::quantity.toString();  
 var recipe = mc.getPayloadXML()..*::recipe.toString();  
 var resetFlag = mc.getPayloadXML()..*::resetFlag.toString();  
 mc.setPayloadXML(  
 <m:newOrder xmlns:m="http://services.com">  
 <m:request>  
 <m:customerName>{customerName}</m:customerName>  
 <m:customerEmail>{customerEmail}</m:customerEmail>  
 <m:quantity>{quantity}</m:quantity>  
 <m:recipe>{recipe}</m:recipe>  
 <m:resetFlag>{resetFlag}</m:resetFlag>  
 </m:request>  
 </m:newOrder>);  
 ]]></script>  
 <header name="Action" value="urn:newOrder"/>  
 <log level="full"/>  
 </inSequence>  
 <outSequence>  
 <log level="full"/>  
 <property name="messageType" value="application/json" scope="axis2"/>  
 <send/>  
 </outSequence>  
 <endpoint>  
 <address uri="http://localhost/services/BusinessService/" format="soap11"/>  
 </endpoint>  
 </target>  
 <description/>  
 </proxy> 


Referance

[1] https://docs.wso2.org/display/ESB481/Sample+441%3A+Converting+JSON+to+XML+Using+JavaScript

[2] https://chrome.google.com/webstore/detail/advanced-rest-client/hgmloofddffdnphfgcellkdfbfbjeloo

Did you forgot your MySQL password

I have installed MySQL server on my machine for many testing purposes and after that I forgot the password I used in many cases :D

There is a very simple way to reconfigure MySQL in Linux. 

manoj@manoj-Thinkpad:~$ sudo dpkg-reconfigure mysql-server-5.5 

This will allow us to reset the password on our MySql server.

Wednesday, April 16, 2014

How to invoke secured API using httpClient

Today I faced difficulty when try to invoke published API on WSO2 API Manager using https protocol. The reason for this was before invoking I haven't set the truststore definition in my HttpClient. So after some effort and Googling I wrote a sample client project and I believe this will be useful to other as well.

So better publish it :)



To set up the sample to test this client you can use Deploying and Testing YouTube API sample API on our API Manager docs.

And on the client code you need to update the Authorization Bearer and URL according to your published API. In this sample I have used client-trust.jks inside my client. But it is always recommended that client should generate his own keystore, and export the public key to client-trust.jks and then client should invoke the API using his own keystore.

You can download the sample client maven project here.

Carbon 5.0.0 [C5] Milestone 03 - Architecture

Carbon 5 [C5] is the next generation of WSO2 Carbon platform. The existing Carbon platform has served as a modular middleware platform for more than 5 years now. We've built many different products, solutions based on this platform. All the previous major releases of Carbon were sharing the same high level architecture, even though we've changed certain things time to time.

Base architecture of the Carbon is modeled using the Apache Axis2's kernel architecture. Apache Axis2 is Web service engine. But it also has introduced a rich extensible server framework with a configuration and runtime model, deployment engine, clustering API and a implementation, etc. We extended this architecture and built a OSGI based modular server development framework called Carbon Kernel. It is tightly coupled with Apache Axis2. But now Apache Axis2 is becoming a dead project. We don't see enough active development on the trunk. Therefore we thought of getting rid of this tight coupling to Apache Axis2.

Carbon kernel has gained weight over the time. There are many unwanted modules there. When there are more modules, the rate of patching or the rate of doing patch releases increases. This is why we had to release many patch releases of Carbon kernel in the past. This can become a maintenance nightmare for developers as well as for the users. We need to minimize Carbon kernel releases.

The other reason for C5 is to make Carbon kernel a general purpose OSGi runtime, specialized in hosting servers. We will implement the bare minimal features required for server developers in the Carbon kernel.

Our primary goal of C5 is to re-architect the Carbon platform from the ground up with the latest technologies and patterns to overcome the existing architectural limitations as well as to get rid of the dependencies to the legacy technologies like Apache Axis2. We need to build a next generation middleware platform that will last for the next 10 years.

Current WSO2 CARBON architecture consists of the following components:

  • Artifact Deployment Engine 
  • Centralized Logging 
  • Pluggable Runtime Framework 
  • Clustering Framework 
  • Configuration and Context Model (Experimental) 
  • Hierarchical Tenancy Model (Experimental) 
The diagram below depicts the architecture with its components.


  • Artifact Deployment Engine

    Carbon Artifact Deployment Framework is responsible for managing the deployment and undeployment of artifacts in a carbon server. You can find the internal design architecture of this module and on how to implement a new deployer and to plug it with the Artifact Deployment Framework on here.
  • Centralized Logging

    Carbon Logging Framwork has integrated PaxLogging, which is a well known open source project for to implement strong logging backend inside Carbon server. You can find more about supporting logging API's and configuration information on here.
  • Pluggable Runtime Framework

    Carbon Pluggable Runtime Framework is responsible for handling and managing integrated 3rd party Runtime's on Carbon server. You can find the internal design architecture of this module and on how to plug new 3rd party runtime with the Pluggable Runtime Framework on here.
  • Clustering Framework

    The Clustering Framework provides the clustering feature for carbon kernel which adds support for High Availability, Scalabilty and Failover. The overall architecture of clustering implementation in a single node and implementation details can be found here.
  • Configuration and Context

    Carbon Configuration and context, model the CarbonConfiguration and allows CarbonRuntime implementations to retrieve the configuration instance. CarbonRuntime represents the complete server space and CarbonContext is the entity which provides the Carbon runtime related contextual information of the current executing thread.
  • Hierarchical Tenancy Model

    Carbon Hierarchical Tenancy Model will create OSGi isolated region for individual tenants. Each and every tenant deployed in a single JVM will get his own OSGi region. This would ensure class space, bundles and OSGi service level isolation for tenants and also provide application-level isolation for tenants.

    You can try out our Milestone 03 release on https://github.com/wso2/carbon-kernel/releases/tag/5.0.0-M3

    How To Contribute

    You can find more instructions on how to contribute on our documentation site. If you have any suggestions or interested in C5 discussions, please do so via dev@wso2.org or architecture@wso2.org mailing lists .

Wednesday, February 19, 2014

Opensource ESB Performance Comparison

WSO2 recently released the latest version on their Enterprice Service Bus which is WSO2ESB 4.8.1
Along with this they have done a performance analysis with numer of leading opensouce ESB's and according to the results WSO2 ESB has proven to be not only the current fastest opensource ESB but also a pioneer with the set of features it has.

Their results of the latest round of performance testing can be found in the article that published by WSO2: WSO2 ESB Performance Round 7.5.





You can download the latest WSO2 ESB 4.8.1 product here - WSO2 Enterprise Service Bus

The user guide and the documentation can be found here - WSO2ESB Documentation