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.

Introduction to CARBON Runtimes - Part 1

What is a Runtime

When we considering a Runtime many aspects of a Runtime can be taken into consideration depending on its capabilities and features of it. For example if we consider Apache Axis2 Runtime it is a web service engine, Apache Tomcat is a implementation of the Java Servlet and JavaServer and Apache Synapse is a mediation engine likewise. Each of these Runtimes has its own features and capabilities. 

How features of a Runtime can be used

To facilitate its features a Runtime can expose different services that can be used. For example if we consider Axis2 Runtime it has Axis2Deployer which is responsible for artifact deployment and Axis2Runtime which is responsible about the Runtime aspect.

The Runtime can be utilized in Carbon by implementing the provided SPI implementations on the server. For example, by implementing the Deployer SPI, server can expose its custom deployer in such a way that it is recognised by the Deployment Engine. Likewise, Runtime SPI can be used to implement the runtime service.

Carbon Runtime Status

In the Carbon context, Runtime can be defined as an application level runtime instance that can run on top of Carbon OSGI framework. Runtime can have a different runtime status, depending on the state of the carbon server. Following diagram shows the available status options of a runtime.

Pending : A given Runtime is in idle state (before the Runtime initialization).

Inactive : The runtime has being initialized successfully. Runtimes can perform operations such as deploying artifacts.

Active : After the start() method of the runtime has been completed, the given runtime is fully functional and it can server requests to the runtime.

Maintenance : In this status, the runtime is on hold for maintenance work. That is, we are temporarily holding the serving of requests while the runtime is on intermediate/maintenance mode.

Git Branching Model

In Git version control system we can maintains multiple branches. For this example lets take Master branch and Development Branch.

• Master Branch

This branch contains the most recently released Carbon Kernel. This is the main branch where the source code of HEAD always reflectsproduction-ready state.

• Development Branch 

This branch is the main branch where the HEAD always reflects a state with the latest on going trunk development changes for the next release.

Start working on new feature

When you start to work on a new feature, you can create a separate feature branch for your self from the develop branch and start working. You can then merge your changes to the development branch once you complete the feature. The following instructions will guide you to start.

Task	Command	Description
Commit your changes	git commit -a -m "your commit message"	Committing your changes to your local git repository
Creating a feature branch	git checkout -b myfeature development	You can create a new feature branch called myfeature from thedevelopment branch
Delete the worked feature branch	git branch -d myfeature
Incorporating changes to development branch	git checkout development	This will add your changes to your local development branch
Push the changes to development branch	git push origin development	Push the changes to the central git repository under development branch

For more information visit http://nvie.com/posts/a-successful-git-branching-model/