WSO2Con 2011: Develop, Test and Deploy your SOA Application through a Single Platform - Chathuri Wimalasena

Archived Content
This article is provided for historical perspective only, and may not reflect current conditions. Please refer to relevant product page for more up-to-date product information and resources.
  • By WSO2Con 2011
  • 22 Dec, 2011

Carbon Studio Architecture

To provide context for the development processes, Chathuri began with an overview of WSO2 Carbon Studio, which provides software developer tools for service hosting, message mediation, management of data sources and data access, repository management, composition and orchestration of business processes, and portal services.

Central to WSO2 Carbon Studio is the concept of a Carbon application (C-App), which is a deployable container for deployable items, Chathuri explained. She added that a C-App artifact will include metadata information, such as name and version, along with the artifact upon which the application will depend.

For example, an Axis2 C-App artifact will contain the actual Axis2 service archive and the metadata, and this all will be contained in a file called “Artifact XML.” Today, WSO2 Carbon Studio supports more than 20 C-App artifacts.

Development with WSO2 Carbon Studio

Chathuri next examined C-App development, deployment, debugging, and she noted that WSO2 Carbon Studio supports all three of these phases both on-premise and in the cloud.

"Carbon Studio is an Eclipse plug-in, so you have all the capabilities of being a Java IDE, " Chathuri said. She added that WSO2 has extended the Java IDE functionality with the introduction of rich editors used for configuration, extended search capabilities, and a debugging framework.

Deployment with Carbon Studio is similar to adding a Tomcat server in Eclipse, Chathuri explained. The developer simply has to start the server—for example the WSO2 Enterprise Service Bus or WSO2 Business Process Server—and then add the Carbon application into the server. When the application is deployed, the developers will see messages in their console, which will indicate whether it was successful or there were any issues. By going to the management console, they can check to see if the application is there.

In looking at debugging and testing, Chathuri identified four key functions: enable server hot update, start servers with the OSGi console enabled, redeploy application, and debug application.

"If you enable those features, your service will start with those features enabled,” Chathuri said.

WSO2’s on-premise and cloud middleware platforms are based on OSGi, so it is important to know the state of the OSGi bundles during the run time. Enabling the OSGi console gives developers all the functionality to do OSGi commands and find out the states of their bundles, Chathuri explained. Additionally, when the Hot Update function is enabled, it will automatically un-deploy an existing Carbon application and then deploy the modified Carbon application whenever a change is made.

The Hot Update feature “is quite useful when your application has a number of artifacts that are changing all the time,” Chathuri said. “It’s easier than manual deployment.”

Similarly, the Redeploy function allows developers to decide when they want to redeploy an application; it will remove the existing application from the server, and deploy the new one. Last, starting the server in Debug mode allows the developer to add a service as before, but when the service is invoked, the Debug point will hit, making it possible to debug the application and find any issues.

Deployment with WSO2 Carbon Studio

Chathuri then provided an overview of C-App deployment and lifecycle management.

In order to put an application in a production environment, it has to be packaged in a simple form. In WSO2 Carbon Studio, the packaging solution is a the Carbon Application Archive (CAR). This archive is a combination of the artifacts created in the development phase, and it can be deployed in any server. Additionally, the CAR may have access to archives and Web application archives, proxy servers, and possibly bundles if the CAR contains any Java sources.

To address the different artifacts in a CAR file, users must define their server roles. Therefore, there is a defined a server role for each and every artifact created by WSO2 Carbon Studio. Deployers will check for matching server roles and deploy only those artifacts into the server.

Since a CAR file is a self-contained archive, it can easily navigate through the processes of life cycle management, Chathuri explained.

"People can manage their applications through and around the development and quality assurance (QA) environments," Chathuri said. "Because the CAR is a self-contained entity, you can move the same CAR that you used in QA directly into production."

To learn more about how to automate development, testing and deployment in the cloud, view Chathuri’s full presentation here.

About Author

  • WSO2Con 2011
  • Sri Lanka