WSO2 Carbon Kernel 5.0.0-alpha: Introduction to the all new jar-to-OSGi-bundle converter tool

WSO2 Carbon-kernel 5.0.0-alpha has been released with all new features integrated into it. You will be able to gather an excellent insight into it from the release notes, WSO2 Carbon documentation and you can check out the source code from this link.

But speaking of its all new features, I am intending to analyse one such new feature that has been introduced into the kernel, through this post. The new Java Archive (.jar) to OSGi-bundle converter, a functionality which had been part of the earlier Carbon-kernel versions as well, has been revamped and brought forward along with a fresh approach. 

A good introduction to this feature can be found in the documentation itself and I believe reading the docs will be really beneficial in order to understand its functionality, usage, imposed restrictions, reasons for the change in implementation and etc.

Since the above link I have provided covers the high level details about the tool, I intend to analyse its implementation within this post.

As mentioned in the article, this functionality was part of the org.wso2.carbon.server module of the previous Carbon-kernel versions. The following two Java classes primarily contained all implementation of the jar-to-bundle converter functionality.

• Utils.java
• DefaultBundleCreator.java

When you observed these two classes, the following points would become evident to you:

• The implementation is tightly coupled with the Carbon-kernel such that you cannot specify any desired source Java archive (.jar) file or directory containing such files and a destination directory for the generated OSGi bundles. 
• No usage of the all new Java features such as NIO package, lambda expressions, streams and etc.
• The execution of this functionality occurs at the server startup, which effectively increments the server startup time, further. 

Hence, we have decided to implement this as a separate module which is equivalent to an optional tool which the user can execute rather than executing it at the server startup, by default. Hence, we have introduced a fresh Maven module within the Carbon-kernel code base named tools. Plus this tool can be used to make jar-to-bundle conversion(s) between any two specified locations unlike in the previous case which only transacted between the CARBON_HOME/repository/components/lib and CARBON_HOME/repository/components/dropins directories. The usage instructions for this tool has been provided in the documentation. 

The new implementation is primarily composed of four classes which are as follows:

• BundleGenerator.java - Contains the executor main method along with validations on file paths and file permissions, user arguments and etc.
• BundleGeneratorUtils.java - Contains utility methods which are used during the conversion process.
• Constants.java - Defines constants used within BundleGeneratorUtils.java class' utility methods.
• JarToBundleConverterException.java - a custom exception class for the tool.

In-depth analysis of all classes and their methods can be found in the Java Doc comments.

Finally, it has to be mentioned that further improvements will take place in the future in relation with this tool. Any suggestions and ideas in relation with this tool are highly appreciated.  

An analysis of a Proof of Concept (PoC) Java application which deploys the WSO2 Carbon 5 kernel in Docker Containers with the support of orchestration capabilities of Google Kubernetes

In this post, I have chosen to provide an analysis of a Proof of Concept (PoC) Java application which is capable of deploying a sample version of the WSO2 Carbon 5 kernel in Docker Containers with the help of Docker Container orchestration capabilities of Google Kubernetes. This post may not contain detailed analysis of all the Docker and Google Kubernetes concepts utilized but I intend to make future posts which may cover advanced details related to these concepts. 

Following are the basic functionalities, I have added to the application:

• Deploy a tenant-specified number of Docker Container instances (inside Kubernetes Pods) with the WSO2 Carbon kernel running inside, each of them.
• Scale the number of Docker Container instances (inside Kubernetes Pods) running during the application run time.
• Make a rolling update to a currently deployed version of the Carbon kernel with an updated version of the Carbon kernel.
• Roll back to an older build version of the currently deployed version of the Carbon kernel.
• Remove a currently deployed tenant specific set of Docker Container instances.

Note: In this application, a particular tenant (user) can have only a single set of Docker instances  (with Carbon kernel deployed) running during the application run time. The tenant can make a rolling update to deploy an updated kernel version.

You can use this GitHub link to check the Java implementation of these functionalities and the instructions to run this application has been provided in the README.md file in the repository. In addition, I have added the sample wso2carbon-kernel-5.0.0-SNAPSHOT.zip file to the following GitHub link.

When analyzing the application implementation, the Docker and Kubernetes concepts have been used as follows:

• The tenant has to provide the Carbon kernel zip file which will be deployed. 
• Initially, the application will generate a Dockerfile which provides instructions to deploy the kernel zip and run the bin/wso2server.sh file at the initiation of each Docker Container.
• Build up a Docker Image using the Dockerfile generated.   
• Google Kubernetes Replication Controller concept has been used to generate the tenant specified number of Pods, where each pod contains one running Docker Container instance of the above generated Docker Image.
• During scaling, the Replication Controller is updated with the new number of replicas. Depending on the updated value, new replicas are added to the existing number of Pods to meet the new value (if the updated value is higher than the previous) or existing Pods are deleted to meet the new value (if the updated value is lower than the previous)
• During a rolling update, it is first checked if the specified tenant has an already running set of Container instances and if yes, a new Docker Image will be built as in the case of deployment operation and that particular Image will be updated in the already running Replication Controller. The currently running Pods will be deleted (since they are running the previous Docker Image) in order to make way for the Replication Controller to spring up new Pods with the updated Docker Image. If not deployed, the tenant is requested to deploy the kernel before making a rolling update. 
• During a rollback operation, a similar procedure to that of a rolling update is carried out from the point of updating the Replication Controller, with the only difference being that the tenant has to choose the new Docker Image from existing Docker Images (previous build versions of the kernel from the same tenant) before the Replication Controller is updated.

Note: 

• This application has been well tested in Ubuntu 14.04.3 LTS OS trusty version and has not  yet been tested in any other platform. 
• Except for minor bugs in relation with file permissions which have not yet been fixed, this application performs the basic functionalities mentioned above quite convincingly.
• I have used spotify/docker-client as the Docker Remote API, fabric8's Kubernetes API and Apache Stratos' Kubernetes client for Kubernetes operations in the Java code.

I expect to spend further time on fixing existing bugs and carrying out further testing in the future. Any comments, suggestions and help with regards to this application and related topics are highly appreciated.