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

Wednesday, September 25, 2013

How to set MySql data-source on WSO2 product

Today I'm going to explain how to set your MySql datasource to WSO2 product. You can simply do this by few number of steps.


  1. Create new data in your MySql database say 'userstore'
      • CREATE DATABASE userstore;
  2. Copy  your mysql connector jar (ex: mysql-connector-java-5.1.12-bin.jar) to PRODUCT_HOME/repository/components/lib directory.
  3. Now go to master-datasource.xml file at PRODUCT_HOME/repository/conf/datasources
  4. Replace the datasource tag with the following,
 <datasource> 
 <name>WSO2_CARBON_DB</name>
      <description>The datasource used for registry and user manager</description>
      <jndiConfig>
           <name>jdbc/WSO2CarbonDB</name>
      </jndiConfig>
      <definition type="RDBMS">
      <configuration>
           <url>jdbc:mysql://localhost:3306/userstore?autoReconnect=true</url>
           <username>root</username>
           <password>123</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>

Set your MySql url, username and password accordingly.

Once you start your server with sh ./wso2server.sh -Dsetup all the required scripts will be run and your database base will be updated.

Now you are ready to go :)


Friday, June 28, 2013

Servicepack patches applying procedure

Recently I was involved in implementing Servicepack feature on Carbon kernel. Up to this implementation WSO2 products only supported to apply patches as needed. But when time goes this number of patches get increased(sometimes patche0001 to patch0100 so on....) and it will be difficult to maintain and sometimes some of these patches can get missed and will be difficult to check. Servicepack implementation was taken into account to address this scenario.

Let me first tell you the structure of a Servicepack. Servicepack is a collection of patches combined to one such that it will be easy to distribute to a customer. (ex: patch0001 to patch0080). It mainly contain two elemets,

  • lib directory : which contain all the jar files corresponding to the patches that will be applied by Servicepack
  • servicepack_patches.txt file : contain the list of patch numbers included on the servicepack




With this approach during server start up with ./wso2server.sh -DapplyPatches the code will first check on available service packs on $CARBON_HOME/repository/components/servicepack directory and apply the latest Servicepack available in the directory. Then with the help of servicepack_patches.txt file of the Servicepack patch applying process will apply the remaining patches that was not applied by Servicepack to the server.

The order the patches and Servicepacks get installed will be shown in the below diagram. It will first apply patch0000 which is the plugins backup directory if exist. Then it apply the latest Servicepack available. Finally the process apply the remaining patches which was not applied by Servicepack.



Then we will verify the components inside applied latest Servicepack and patch list with the $CARBON_HOME/repository/components/plugins directory. If plugins directory contain the latest patch list we assume the process is successfully completed :)

CarbonApp Deployment Process


In this artical I will discuss about the deployment process of CApp artifacts. CApp namly CarbonApplication Deployer is an collection of different artifacts bundled to a single deployable component. When deploying a CApp on any WSO2 product it directly deploy all the relevent artifacts for the product by calling the relevant artifact deployers programmatically. This will be done by the CAppDeployer when the corresponding CApp get deployed. According to this process the deployment of the artifacts will be synchronous and the artifact deployment will be atomic. So if the CApp successfully deployed we can guarantee that all the artifacts have successfully deployed.



Steps involved during deployment of CarbonApp,
  • Artifacts inside CApp get extracted to temp location
  • CAppDeployer then call the relevant deployer based on the artifact and deploy the artifacts
  • When the CApp get deployed all its artifacts are up and running


The sample code to the new implementation is shown in the below segments. In this case I have given the example code for webapp deployment. The deployment of the other artifacts will be in same fashion except synapse artifacts.

Generate MD5 thumbprint form security certificate

Recently I was involved in implementing keystore validation on default wso2carbon keystore. The main idea behind this implementaion was to make customer aware about security risks by leaving default JKS in production because wso2 keystore is publically available since we are an open source company.

During system validation what I did was obtain the primary keystore of the vendor and validate its MD5 thumbprint value with default wso2carbon certificate thumbprint value. This method used to generate the thumb print form an X509Certificate is interesting and I hope this will be useful to someone someday + me :)


/**
* Generate the MD5 thumbprint of the certificate
*
* @param certificate that we need the thumbprint
* @return MD5 thumbprint value
* @throws CertificateEncodingException
* @throws NoSuchAlgorithmException
*/
private String getCertFingerprint(X509Certificate certificate) throws CertificateEncodingException, NoSuchAlgorithmException {
MessageDigest digestValue = MessageDigest.getInstance("MD5");
byte[] der = certificate.getEncoded();
digestValue.update(der);
byte[] digestInBytes = digestValue.digest();
return hexify(digestInBytes);
}

/**
* Helper method to hexify a byte array.
* @param bytes
* @return hexadecimal representation
*/
private String hexify(byte bytes[]) {

char[] hexDigits = {'0', '1', '2', '3', '4', '5', '6', '7',
'8', '9', 'a', 'b', 'c', 'd', 'e', 'f'};
StringBuffer buf = new StringBuffer(bytes.length * 2);

// appending : marks to make fingerprint more readable
for (int i = 0; i < bytes.length; ++i) {
buf.append(hexDigits[(bytes[i] & 0xf0) >> 4]);
buf.append(hexDigits[bytes[i] & 0x0f] + ":");
}
// removing the last : value from the buffer string
buf.deleteCharAt(buf.length()-1);
return buf.toString();
}