{section}
{column}

h1. Introduction

Petals ESB can be deployed into the cloud. By this way, to optimize hardware resources consumption:
* Petals ESB containers are instantiated on-demand,
* Service providers are placed on the right Petals ESB container according to the system load.

In a user point of view, the Petals Virtual Container (PVC) will be the service infrastructure running all service consumers and service providers. The PVC is composed of:
* nodes of the Petals Registry Overlay, that are automatically instantiated according to the system load of the Petals Registry nodes,
* Petals ESB containers that are automatically instantiated according to the system load of containers.

The user will deploy its regular Petals artifacts (shared library, components, SA or deployable SU) into the PVC. Service providers will be placed on the right container, and all dependencies (shared library, components) will be automatically deployed on this container.

{column}
{column:width=35%}
{panel:title=Table of contents}{toc:outline=true}{panel}
{panel:title=Contributors}{contributors:order=name|mode=list|showAnonymous=true|showCount=true|showLastTime=true}{panel}
{column}
{section}

h1. Preparing the environment

Deployment of a PVC is assumed by [Roboconf|http://roboconf.net]. Make sure you have an operational Roboconf installation.

Before to install anything, you must define your software components to Roboconf:
* the software components of your applications used as service providers exposed into the PVC,
* the software components of the PVC, ie: mainly service units,
* the software components of your applications consuming service providers available into the PVC.

{gliffy:name=PVC_Overview|align=center|version=3|size=M}

Using several Roboconf applications is very interesting to keep the agility introduced by the usage of services deployed on the PVC part. In this way:
* the governance of applications is made easier because no synchronization is required between applications,
* an applicative resource can be re-deployed, only its dependencies are informed of configuration changes to take into account.

In a Roboconf point of view, each software component set is a Roboconf application that must be defined. See the Roboconf application to known how to define your Roboconf applications.
A Roboconf application template is provided to easily define your PVC. With this template, you have mainly to define the service units that must be deployed into the PVC.

{info}The new component *Petals Cockpit*, a web application in progress, will be able to generate your Roboconf application for the PVC part, and interact with the Roboconf engine. And so, it will be easier to instantiate PVCs.{info}

h1. Installing the PVC

Once all your Roboconf applications are ready, you can deploy them using the Roboconf Administration Console.

h1. Writing the Roboconf application for your PVC instance

Waiting the release of Petals Cockpit, we must write our instance of PVC as a Roboconf application.

To explain how to write a such application, we will use the following example:
* The process "Vacation" is deployed as service unit of the SE Activiti running into our PVC. This process provides a business process to manage vacation request.
* The process interacts with an external resources to archives the vacation requests and to log task status. The external resources is accessed through several web-services
* A portal is proposed to users to create and validate vacation requests.

So, we have 3 Roboconf applications:
* the Roboconf application for the portal,
* the PVC,
* and a Roboconf application archiving vacation requests and task status.

{info}Source code associated to this sample is available here: [https://github.com/petalslink/petals-virtual-container].{info}
{info}Docker is used as IaaS in this sample.{info}
{note}Extracts of source code given below are for comprehension. It's not the right source code. To get it, see the Git repository of the sample.{note}

h2. The Roboconf application "External resource"

This applicative resource is a web application running on Tomcat8 cluster, composed of:
* a load balancer redirecting incoming HTTP SOAP request on an available Tomcat8 server where the web application is deployed,
* several servers running Tomcat.
{gliffy:name=TomcatCluster|size=M|version=2}

So the model of this Roboconf application is:
{section}
{column}
*Component definitions*
{code}
Tomcat8_VM {
installer: target;
children: Tomcat8;
}

Tomcat8 {
installer: script;
exports: ip, port = 8080;
children: Tomcat8_Application_WAR;

children: HAProxy;
}

HAProxy {
installer: script;
imports: Tomcat8.port (optional), Tomcat8.ip (optional);
exports: ip, httpPort = 80, statsPort = 8080;
}
{code}

{column}
{column}
*Default instantiation*
{code}
# A VM with HAProxy_VM load balancer
instance of HAProxy_VM {
name: HAProxy VM;

instance of HAProxy {
name: Haproxy;

httpPort: 80;
statsPort: 8080;
}
}

# A VM with Tomcat
instance of Tomcat8_VM {
name: Tomcat VM1;

instance of Tomcat8 {
name: Tomcat;

instance of Tomcat8_Application_WAR {
name: samplesActivitiSOAPservices;

applicationFile: samples-SOAP-services.war;
}
}
}

# Another VM with Tomcat
instance of Tomcat8_VM {
name: Tomcat VM2;

instance of Tomcat8 {
name: Tomcat;

instance of Tomcat8_Application_WAR {
name: samplesActivitiSOAPservices;

applicationFile: samples-SOAP-services.war;
}
}
}
{code}
{column}
{section}
h2. The Roboconf application "Portal"

The portal is a web application running on a simple instance of Tomcat8
{gliffy:name=Portal|size=M|version=2}

So the model of this Roboconf application is:
{section}
{column}

{column}
{column}

{section}