Cloud Controller Architecture

The diagram above depicts a high level architecture of the WSO2 Cloud Controller. The Cloud Controller is a WSO2 Carbon based server that has several architectural components, that are namely,

Cloud controller service

The Cloud Controller Service is the main entry point for a Cloud Controller service consumer.  For more information on the service interface see Cloud Controller Service Interface.

Cloud controller deployer

This is an Axis2 deployer responsible for deploying or updating the cloud-controller.xml file. Fore more information on the cloud-controller.xml file see Cloud Controller Configuration Files

Cartridge deployer

This is an Axis2 deployer responsible for deploying or updating the cartridge definition files that reside in ${WSO2-CC}/repository/deployment/server/cartridges/ folder. The user has to define the Cartridges that the system is going to support in Cloud Controller. To define a Cartridge the user can simply drop a XML file which defines their Cartridge, into the ${WSO2-CC}/repository/deployment/server/cartridges/ folder either before starting the server or while the server is running.

  The following are the guidelines that a Cartridge XML file should follow:

• Unique file name.
• Adhere to one of the given XML schemas.
  
  • Cartridge Schema for Single Cartridge
  • Cartridge Schema for Multiple Cartridges
    

To view sample files see Sample Cartridge XML Files .

Service deployer

This is an Axis2 deployer responsible for deploying or updating the service definition files that reside in the {WSO2-CC}/repository/deployment/server/services/ folder. Carbon services need to be specifically defined in the Cloud Controller. However, this is not the case with non-Carbon services, because at the time of subscribing to Stratos-2 all the relevant services get automatically registered in the Cloud Controller.

To define a file drop the XML file that defines the service configuration into the {WSO2-CC}/repository/deployment/server/services/ folder. This can be done either before starting the server or while the server is running.

The service XML file should have a unique file name and should adhere to any of following two XML schemas.

• Service schema
  You can define only one service in a file.

• Services schema
  You can define multiple services in a single file.

To view a sample files see Sample Service XML Files

Axiom Xpath parser

The Axiom Xpath based parser is responsible for parsing all kinds of *.xml configuration files of the Cloud Controller.

Topology publisher

We use a central location such as the Cloud Controller to maintain the topology configuration. The topology configuration refers to the information on the various service clusters present in the Cloud environment.  

To view a sample file see Sample Topology Configuration

Keeping this information in the Cloud Controller alone is not sufficient as this configuration is needed in other locations as well, such as the Elastic Load Balancer (ELB), Artifact Distribution Coordinator (ADC) and other locations. As a result, the Cloud Controller syncs the topology with the other components. The following image explains how the topology synchronization takes place:

Topology synchronization

• The Cloud controller keeps building the topology configuration and publishes it in a periodical manner to a topic created in WSO2 Message Broker (MB) that is embedded into the Cloud Controller (CC). Changing the topology configuration can be done dynamically as well as publishing can be done when configuration changes arise. 
  
• Any subscriber   who needs this topology configuration can subscribe to the relevant topic and get synced.
• Subscribers should ideally generate the difference between the configuration (such as, the difference between what it received and what it has) and if a difference is present, act upon the change in the topology.

Building a topology

Topology configuration can be changed dynamically by removing an added topology or by updating an existing topology without restarting the servers. After a topology is dynamically changed it needs to be published to an up-to-date version on the topic. The producer-consumer patterncan be used for this purpose.

The Cloud Controller's Service Deployer (which is the producer) will track the changes and put them into a shared blocking queue that is shared with consumer. The Topology Builder (which is the consumer) grabs changes from the queue and adds or updates the topology configuration ${WSO2-CC}/repository/conf/service-topology.conf as shown in the above diagram.

BAM data publisher

We publish the information of the instances that are started up by the Cloud Controller to WSO2 BAM server. BAM data publisher is intelligent enough to publish events related to a newly spawned instance or a state changed existing instance. The following screenshot shows published data from BAM’s Cassandra explorer.

IaaS implementation layer

This layer contains the IaaS implementations. All these implementations are extensions of Cloud Controller’s IaaS abstract class. This class resides in Cloud Controller’s org.wso2.carbon.stratos.cloud.controller.interfaces package.

Please see Iaas Abstract Class   for more details.

jclouds

This layer is the jclouds API jclouds is an open source library that helps you get started in the cloud. The jclouds API gives you the freedom to use portable abstractions or cloud-specific features. For more information on jclouds got to http://www.jclouds.org/