Carbon Pluggable Runtime Framework - Part 2

The Carbon Pluggable Runtime Framework is the core module on kernel level for handling 3rd party Runtime management on Carbon server. A high level architecture of the runtime framework is shown in below diagram.

Runtime service
For runtime to be registered on the Runtime Framework, it should extend the provided Runtime SPI and expose the corresponding runtime service.

Runtime Service Listener
This will be listening to runtime register/unregister events and once runtime service is registered, the Runtime Service Listener will notify the RuntimeManager.

Runtime Manager
This will keep the information about available runtimes.

Once all the required runtime instances get registered, the Runtime Framework will register the Runtime Service which provides the utility functionalities on the Runtime Framework.

What will be the advantage of using Pluggable Runtime Framework

With Carbon Pluggable Runtime Framework we can integrate/plug different 3rd party Runtime implementations to Carbon server. Not only that this framework facilitate the server to manage the registered Runtime's in a controlled manner. For example during server maintenance the underlying framework will handle the Runtime's by putting them on maintenance mode and start back when server is back on normal state. The developer or user did not need to know underlying process once you registered the Runtime on the framework.

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 .

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.

How to upgrade SNAPSHOT version of carbon trunk

When upgrading a SNAPSHOT we need to apply this upgrade on orbit, kernal and platform trunks respectively. When upgrading we need to consider different types of SNAPSHOT entries on different files on trunk. I'm creating this tutorial because this will be useful to someone like I did :)

1) First we need to change all the x.x.0-SNAPSHOT entries of pom.xml files to next version value (ex: 4.1.0-SNAPSHOT to 4.2.0-SNAPSHOT)
this could be easily done using a single command
find . -name 'pom.xml'|xargs sed -i 's/4\.1\.0-SNAPSHOT/4\.2\.0-SNAPSHOT/g'

2) Need to change the 4.1.0.SNAPSHOT entry from carbon.product file (ex: 4.1.0.SNAPSHOT to 4.2.0.SNAPSHOT) on following directories
trunk/distribution/kernel/carbon.product
distribution/product/modules/p2-profile-gen/carbon.product

3) Need to change the x.x.0-SNAPSHOT entry on filter.properties file on following directory
kernal/trunk/distribution/product/modules/distribution/src/assembly

4) And on kernal and platform trunks extend the range of the valid snapshot versions according to our upgrade on parant/pom.xml
ex:
<carbon.platform.package.import.version.range>[4.1.0-SNAPSHOT, 4.2.0)
        </carbon.platform.package.import.version.range> 
to
<carbon.platform.package.import.version.range>[4.2.0-SNAPSHOT, 4.3.0)
        </carbon.platform.package.import.version.range>