This documentation is for WSO2 Application Server 5.2.0. View documentation for the latest release.
Introduction to Carbon Applications - Application Server 5.2.0 - WSO2 Documentation
||
Skip to end of metadata
Go to start of metadata

Carbon Applications will be renamed to Composite Applications in the upcoming release, because we will be supporting both Carbon-based and non Carbon-based applications.

A Carbon Application, abbreviated as a C-App, is a collection of artifacts deployable on a Carbon instance. These artifacts are usually java-based or xml configurations, designed differently for each product in the Carbon platform. Users have to deploy these artifacts to generate services. In a single Carbon-based solution, there can be numerous artifacts used, such as Axis2 services, data services, synapse configurations, endpoints, proxy services, mediators, registry resources, BPEL workflows etc. Usually, these artifacts are created in a development environment and then moved one by one into staging/production environments. When moving a Carbon solution from one setup to another, the user has to manually configure these artifacts to build up the entire solution. This is a time-consuming process.

Alternatively, bundling configuration files and artifacts in a C-App makes it easy for users to port their Web service based solutions across environments. Carbon Applications save time by providing the facility to export your entire solution as a single C-App artifact and simply deploy it in the server. WSO2 Developer Studio can be used to develop your individual artifacts and export them as a single C-App artifact. You can then deploy it on any Carbon server which has C-App deployment capabilities.

Since a C-App consists of a set of artifacts to be deployed in different products, when a user tries to deploy a C-App in a particular carbon product, all its artifacts cannot be deployed in that particular product instance. To sort out which can be deployed in which, the ServerRole property is used.

The ServerRole Property

A server role is a parameter that is mentioned in the carbon.xml file (<PRODUCT_HOME>/repository/conf) of all WSO2 Carbon-based products. When a C-App is being deployed, it reads the ServerRoles property from the carbon.xml and deploys only the resources which match the server-role values in there. 

Each product has a different default ServerRoles property as follows:

  • WSO2 Application Server - "ApplicationServer"
  • WSO2 Business Activity Monitor - "BusinessActivityMonitor"
  • WSO2 Business Process Server - "BusinessProcessServer"
  • WSO2 Business Rules Server - "BusinessRulesServer"
  • WSO2 Data Services Server - "DataServicesServer"
  • WSO2 Enterprise Service Bus - "EnterpriseServiceBus"
  • WSO2 Gadget Server - "GadgetServer"
  • WSO2 Governance Registry - "GovernanceRegistry"
  • WSO2 Identity Server - "IdentityServer"
  • WSO2 Mashup Server - "MashupServer"

In C-App development time, you have to specify a server role for each and every artifact in the C-App. It assigns a logical ServerRole to each and every artifact since, at development time, we are aware of the physical server in which a particular artifact will be deployed.

For example, say you are developing an Axis2 service and planning to deploy all your services in a single Application Server instance in the production setup. You may set the server role as "appserver1". At the deployment time of the C-App, you have to set the server roles for each and every Carbon instance in your setup. You can set one or more roles which can be assigned to the current Carbon instance. The product name is set as the default value for the server role of each product. The following three methods can be used to set the ServerRole.

Using the Management Console

This is the easiest and the most recommended way to configure your server roles. For more information, please refer to section: Server Roles for C-Apps.

Using carbon.xml File

You can find the ServerRoles element in <PRODUCT_HOME>/repository/conf/carbon.xml file. For example,

<ServerRoles>
     <Role>DataServicesServer</Role>
</ServerRoles>

You can set multiple Role elements here to specify the roles acted by the current server. For example, if you want this server to act as appserver1 and dataservices1 servers, configuration is as follows.

<ServerRoles>
     <Role>appserver1</Role>
     <Role>dataservices1</Role>
</ServerRoles>

Before setting the above, ensure that the current server has capability to deploy Axis2 services and data services. When you deploy a C-App artifact on this server, all artifacts which have the above two server roles will be deployed on the current instance. Others will be ignored.

Using a System Property

You can use the system property ServerRoles to specify the server roles that can be acted by the current Carbon instance. When you start the server, pass the server roles as a comma separated list. For example,

sh wso2server.sh -DserverRoles=appserver1,dataservices1

Once you use the management console to set server roles, you can't change that configuration using the other two methods. Server roles are stored in the Registry when they are configured through the management console. Values in the Registry are always given priority over others.

  • No labels