With the 4.0 release of WSO2 Carbon we have changed the internal architecture of the platform in a significant way. In the pre Carbon 4 era, WSO2 carbon used to get deployed as a web-app on apache-tomcat servlet container under the hood. The hight level architecture looked like,
As shown in the above diagram Carbon framework get deployed as just another web-app in Apache tomcat server. Hence, in the in the Carbon 3.2.0 architecture there were two Carbon environments,
However with this approach there was a noticeable disadvantage:
JAR duplication - Carbon based products like WSO2 Applicaton Server allows users to deploy web-applications. To share some of the core APIs with the third-party web-apps we had to move them-out/duplicate from the Carbon OSGi environment. (Eg: Carbon Context API).
The Solution : Make Tomcat a bundle and move it in to the OSGi environment
In the new architecture we run our application within a pure OSGi environment. There is no bridging between environments. One of the reasons that blocked us from moving to this clear architectural model was the unavailability of tomcat as a bundle. We created a OSGi bundle version of embedded tomcat, which is somewhat similar to existing OSGified jetty servlet container.
Some of the pros of the above approach includes:
1. There is no jar duplication. Hence almost all the carbon related jars resides in $CARBON_HOME/repository/components/plugins directory
2.Now the all the Carbon libs are visible to the third-party web-apps. This is one of reasons why we are going to support native support for CXF web-apps.
3. Now carbon can be deployed in any OSGi framework/platform with minimal set of modifications - its a set of bundles.
However a techy user still can deploy Carbon as a web-app in another servlet container like Apache-tomcat standalone server, JBoss, IBM WAS, etc. :)
The documentation will follow.
As shown in the above diagram Carbon framework get deployed as just another web-app in Apache tomcat server. Hence, in the in the Carbon 3.2.0 architecture there were two Carbon environments,
- The OSGi environment - the area where coloured in light blue
- The Non OSGi environment - rest of the area
However with this approach there was a noticeable disadvantage:
JAR duplication - Carbon based products like WSO2 Applicaton Server allows users to deploy web-applications. To share some of the core APIs with the third-party web-apps we had to move them-out/duplicate from the Carbon OSGi environment. (Eg: Carbon Context API).
The Solution : Make Tomcat a bundle and move it in to the OSGi environment
In the new architecture we run our application within a pure OSGi environment. There is no bridging between environments. One of the reasons that blocked us from moving to this clear architectural model was the unavailability of tomcat as a bundle. We created a OSGi bundle version of embedded tomcat, which is somewhat similar to existing OSGified jetty servlet container.
Some of the pros of the above approach includes:
1. There is no jar duplication. Hence almost all the carbon related jars resides in $CARBON_HOME/repository/components/plugins directory
2.Now the all the Carbon libs are visible to the third-party web-apps. This is one of reasons why we are going to support native support for CXF web-apps.
3. Now carbon can be deployed in any OSGi framework/platform with minimal set of modifications - its a set of bundles.
However a techy user still can deploy Carbon as a web-app in another servlet container like Apache-tomcat standalone server, JBoss, IBM WAS, etc. :)
The documentation will follow.
