Fractal Deployment Framework

Fractal Deployment Framework

List of Tables

2.1. Values for the element hostname of a host
2.2. Values for the element user of a host
2.3. Values for the element transfer of a host
2.4. Values for the element protocol of a host
2.5. Values for the element shell of a host
3.1. Definitions of the JAVA personality
3.2. Elements of the JAVA.JRE software
3.3. Elements of the JAVA.RMI.REGISTRY software
3.4. Properties of the JAVA.RMI.REGISTRY software
3.5. Definitions of the JAVA personality
3.6. Definitions of the JOnAS personality
3.7. Elements of the JONAS.SERVER software
3.8. Elements of the JONAS.Library software
3.9. Elements of the JONAS.JONAS_ROOT software
3.10. Elements of the JONAS.JONAS_BASE software
3.11. Elements of the JONAS.CLUSTER_DAEMON software
3.12. Properties of the JOnAS.SERVER software
3.13. Properties of the JOnAS.JONAS_BASE, JOnAS.JONAS_ROOT and JOnAS.CLUSTER_DAEMON software
3.14. Definitions of the TOMCAT personality
3.15. Elements of the TOMCAT.SERVER software
3.16. Elements of the TOMCAT.WAR.COMPONENT software
3.17. Properties of the TOMCAT.SERVER software
3.18. Definitions of the PEtALS personality
3.19. Elements of the PEtALS.SERVER software
3.20. Elements of the PEtALS.JBI and PEtALS.SA software
3.21. Properties of the PEtALS.SERVER Software
3.22. Definitions of the JADE personality
3.23. Elements of the JADE.BOOT software
3.24. Elements of the JADE.NODE software
3.25. Properties of the JADE.BOOT software
3.26. Properties of the JADE.NODE Software
3.27. Definitions of the JASMINe personality
3.28. Elements of the JASMINe.FRAMEWORK software
3.29. Elements of the JASMINe.GUI software
3.30. Elements of the JASMINe.JADEBOOT software
3.31. Elements of the JASMINe.JADENODE software
3.32. Elements of the JASMINe.JADEJMX software
3.33. Properties of the JASMINe.JADEBOOT software
3.34. Properties of the JASMINe.JADENODE software
3.35. Properties of the JASMINe.JADEJMX software
3.36. Definitions of the ORCHESTRA personality
3.37. Elements of the ORCHESTRA.SERVER software
3.38. Elements of the ORCHESTRA.BPEL.PROCESS software
3.39. Properties of the ORCHESTRA.SERVER software
3.40. Properties of the ORCHESTRA.BPEL.PROCESS software
3.41. Definitions of the MySQL personality
3.42. Elements of the MySQL.SERVER software
3.43. Properties of the MySQL.SERVER software
3.44. Definitions of the Geronimo personality
3.45. Elements of the Geronimo.SERVER software
3.46. Properties of the Geronimo.SERVER software
3.47. Definitions of the ACTIVEBPEL personality
3.48. Elements of the ACTIVEBPEL.ENGINE software
3.49. Elements of the ACTIVEBPEL.PROCESS software
3.50. Definitions of the OpenCCM personality
3.51. Elements of the OpenCCM.SERVER software
3.52. FDF Procedure Instructions
3.53. Software Features

Chapter 1. The Fractal Deployment Framework

Overview

Fractal Deployment Framework (FDF) is a component-based software framework to facilitate the deployment of distributed applications on networked systems. For that, FDF is composed of a high level deployment description language, a library of deployment components, and a set of end-user tools.

The high level FDF deployment description language allows end-users to easily describe their deployment configurations, i.e. the list of software to deploy and the target hosts. This language relies on a library of deployment components wrapping various file transfer protocols (e.g., FTP, SCP), remote access protocols (e.g., TELNET, SSH), Unix and Windows shells, Internet-related notions (e.g., hostname, port, host), and software personalities (e.g., middleware, services, daemons, application servers, application components). Finally, FDF provides a graphical user interface allowing end-users to load their deployment configurations, execute and manage them.

The main principle of FDF is to describe each entity involved in a deployment process, instead of scripting each step of the process.

FDF also deals with dependencies between software: it's possible, in one step, to deploy a whole system, including each software layer, from a virtual machine to the top level application layer.

Installation

You can download FDF here. Then, unpack the archive and set the FDF_HOME variable to the unpacked directory.

The requirements for using FDF are:

  • A Java Runtime Environment (with PATH pointing $JAVA_HOME/bin)

FDF concepts

This section presents all the concepts manipulated within FDF. FDF is many things at the same time: a high level description language, a deployment framework engine and a graphical user interface to manage the deployment.

Figure 1.1, “Representation of the Fractal Deployment Framework” shows the organization of the framework: thanks to a description file, FDF composes its deployment components in order to install, configure and start (but also stop, unconfigure and uninstall) descripted software on the descripted network. All these steps can be administrated from the Graphical User Interface: FDF Explorer.

Figure 1.1. Representation of the Fractal Deployment Framework

Representation of the Fractal Deployment Framework


This is a list of the main concepts mentionned in the rest of this documentation:

  • A FDF software is a abstraction of the deployment process of a given software. It describes each step of the deployment of the software, with the FDF language.
  • A FDF instruction represents a command performed by FDF during the deployment of a software.
  • A FDF procedure is a sequence of FDF instructions. FDF defines the deployment as a set of the 4 following procedures: install, start, stop and uninstall.
  • A FDF personality is a set of software, libraries, parameters, or other concepts related to a given software.
  • A FDF software property is a FDF parameter for the configuration of a software.

Chapter 2. Network Description

All the hosts of the network can be declared in an element called INTERNET.NETWORK. Each HOST component is defined with the following elements :

Here is an example of a network with 2 hosts named 'host-1' and 'host-2'. host-1 is accessed by the user 'doe' with the SCP transfer and SSH protocol. Its shell is a Bourne shell. host-2 is accessed by the same user with the JSCP transfer and JSSH protocol. Its shell is a C shell.

        Hosts = INTERNET.NETWORK {

          host-1 = INTERNET.HOST {
            hostname = INTERNET.HOSTNAME(NameOfTheHost);
            user     = INTERNET.USER(doe,password,/home/doe/.ssh/id_rsa);
            transfer = TRANSFER.SCP;
            protocol = PROTOCOL.OpenSSH;
            shell    = SHELL.SH;
          }

          host-2 = INTERNET.HOST {
            hostname = INTERNET.HOSTNAME(NameOfTheHost);
            user     = INTERNET.USER(doe,password,/home/doe/.ssh/id_rsa);
            transfer = TRANSFER.JSCP;
            protocol = PROTOCOL.JSSH;
            shell    = SHELL.CSH;
          }

        }
        

Table 2.1. Values for the element hostname of a host

DefinitionDescription
INTERNET.HOSTNAME(NameOfHost)
The name (or the IP) of the host.
INTERNET.DYNAMICHOSTNAME
Used when the name of the host is not known statically (e.g. after a reservation on the Grid5000 network). The name is computed at runtime.


Table 2.2. Values for the element user of a host

DefinitionDescription
INTERNET.USER(login,password,privateKey)

Identity of the user of the host.

login is mandatory.

password is required if there is no private key.

privateKey is required if there is no password.



Table 2.3. Values for the element transfer of a host

DefinitionDescription
TRANSFER.Apache_FTP
Apache implementation of a FTP client. This is included in FDF.
TRANSFER.JSCP
A SCP client implemented with the JSCH library (included in FDF).
TRANSFER.JSFTP
A SFTP client implemented with the JSCH library (included in FDF).
TRANSFER.PSCP
PuTTY implementation of a SCP client. It assumes that PUTTY is installed on the local machine.
TRANSFER.SCP
SCP client using the 'scp' command.


Table 2.4. Values for the element protocol of a host

DefinitionDescription
PROTOCOL.ApacheTelnet([true|false])
Apache implementation of the Telnet protocol. Boolean (optional) = false if the OS of the targeted host is the same than the OS of the FDF host (default=false).
PROTOCOL.JTelnet([true|false])
JTelnet implementation of the Telnet protocol. Boolean (optional) = false if the OS of the targeted host is the same than the OS of the FDF host (default=false).
PROTOCOL.ExternalTelnet
Telnet protocol, using the 'telnet' command as an external process.
PROTOCOL.SSH
SSH protocol, using the 'ssh' command as an external process.
PROTOCOL.OpenSSH
SSH protocol, using the 'ssh' command as an external process.
PROTOCOL.JSSH
The SSH protocol implemented with the JSCH library.
PROTOCOL.PLINK
PuTTY implementation of the SSH protocol. It assumes that PUTTY is installed on the local machine.
PROTOCOL.LOCAL_SH
A local SH shell.
PROTOCOL.LOCAL_CSH
A local CSH shell.
PROTOCOL.LOCAL_WIN
A local Windows shell.


Table 2.5. Values for the element shell of a host

DefinitionDescription
SHELL.SH
To use when the shell of the remote host is a SH shell.
SHELL.CSH
To use when the shell of the remote host is a CSH shell.
SHELL.WinCommand
To use when the shell of the remote host is a Windows shell.


This is another example of a host description with the software element. This element is a collection of software (see Chapter 3, Software Description). In this example, this element contains the Java and Ant software.

        host-1 = INTERNET.HOST {
          hostname = INTERNET.HOSTNAME(NameOfTheHost);
          user     = INTERNET.USER(doe,password,/home/doe/.ssh/id_rsa);
          transfer = TRANSFER.Apache_FTP;
          protocol = PROTOCOL.JTelnet(true);
          shell    = SHELL.WinCommand;
          software {
            java = JAVA.JRE {
              archive = JAVA.ARCHIVE(/home/archives/JRE-1.5.tgz);
              home    = JAVA.HOME(/home/doe/jdk1.5.0);
            }
            ant = ANT.APACHE_ANT {
              archive = ANT.ARCHIVE(/home/archives/apache-ant-1.6.5.tgz);
              home    = ANT.HOME(/home/doe/apache-ant-1.6.5);
            }
          }
        }
        

In the following, we present how to describe a software. If there's no specific indication, each software has to be declared with the host element, which refers to an instance of INTERNET.HOST, previously declared.

Chapter 3. Software Description

Software deployment relies on FDF software included in personalities. A FDF software is an abstraction of the deployment process for a given software: each step of the deployment is described with the same language than for hosts description.

This chapter presents this concepts of software and personality: the section called “How to Use a Software Personality ?” lists the existing FDF software personalities and their usage, and the section called “How to write a personality ?” explains how to write a new personality.

Note 1: In the following, each software described for FDF requires to have a host element. Some exceptions can be observed for cases where a software depends on another one and set its hosts from the host of the dependant software.

Note 2: Most of existing personalities relie on Java. Each software that have a dependency on JAVA.JRE needs to have a 'java' element in its description. But for facilitate the documentation reading, we suppose that a JAVA.JRE software is defined in the 'software' element of the host. With this construction, the java-dependent software does not need any more to have the 'java' element: FDF automatically recover it from the host.

How to Use a Software Personality ?

This section presents how to use the existing FDF software. Let's note that in the following, each personality will be described with a 'host' element in it. You can skip it only if the software is declared inside a host (in the 'software' component, see Chapter 2, Network Description), or if the personality is made for recovering its host from another software

Java Personality

The JAVA personality allows the deployment of Java. The archive of this software is available here. Note that, if the archive is an auto installer (e.g. with licence agreement), you must execute it and then re-archive the targeted directory.

Figure 3.1, “Organization of the JAVA Personality” represents the organization between software and properties inside the Java personality and the relations with other elements outside of this personality.

Figure 3.1. Organization of the JAVA Personality

Organization of the JAVA Personality


This personality contains the following definitions:

Table 3.1. Definitions of the JAVA personality

NameDescription
JAVA.JRE Software for the deployment of a Java Runtime Environment (also usable for Java Developpement Kit).
JAVA.RMI.REGISTRY Software for the deployment of a Java RMI registry.
JAVA.ARCHIVE(path_to_archive)Parameter representing a Java archive.
JAVA.HOME(home_directory) Parameter representing the Java Home directory.
JAVA.DependOn(XXX) To use in another software (XXX) that depends on Java.
JAVA.RMI.PORT(value)Parameter representing a Java RMI port.


The following example is the minimal description to write for using the JAVA.JRE and JAVA.RMI.REGISTRY software:

            java-1 = JAVA.JRE {
              archive = JAVA.ARCHIVE(/home/user/archives/JRE.tgz);
              home = JAVA.HOME(/targetDirectory/jre);
              host = Hosts/host-1;
            }

            java-rmi-1 = JAVA.RMI.REGISTRY {
              host = Hosts/host-1;
              java = java-1;
            }
        

Table 3.2, “Elements of the JAVA.JRE software” and Table 3.3, “Elements of the JAVA.RMI.REGISTRY software” list the elements of software for the JAVA personality.

Table 3.2. Elements of the JAVA.JRE software

NameDefinitionDescription
archiveJAVA.ARCHIVEPath to the Java archive
homeJAVA.HOMEPath to the Java Home



Table 3.3. Elements of the JAVA.RMI.REGISTRY software

NameDefinitionDescription
javaJAVA.JRE The Java Runtime Environment on which depends the RMI registry.
propertiesNone See Table 3.4, “Properties of the JAVA.RMI.REGISTRY software”.



Table 3.4, “Properties of the JAVA.RMI.REGISTRY software” lists the configurable properties of the JAVA.RMI.REGISTRY software.

Table 3.4. Properties of the JAVA.RMI.REGISTRY software

NameDefinitionDescriptionDefault value
portJAVA.RMI.PORTThe port to use for the registry1099



The following example is a description using all configurable elements of the JAVA personality:

            host-1 = INTERNET.HOST {
              hostname = INTERNET.HOSTNAME(NameOfTheHost);
              user = INTERNET.USER(doe,password,/home/doe/.ssh/id_rsa);
              transfer = TRANSFER.Apache_FTP;
              protocol = PROTOCOL.JTelnet(true);
              shell = SHELL.WinCommand;
            }

            java-1 = JAVA.JRE {
              archive = JAVA.ARCHIVE(/home/user/archives/JRE.tgz);
              home = JAVA.HOME(/targetDirectory/jre);
              host = Hosts/host-1;
            }

            java-rmi-1 = JAVA.RMI.REGISTRY {
              host = Hosts/host-1;
              java = java-1;
              properties {
                port = JAVA.RMI.PORT(1099);
              }
            }
        

It's also possible to describe software inside the description of a host. By this way, the host element of the software doesn't have anymore to be described. Next examples illustrate the several possibilities about a java software description and its location on a host of the network.

        host-1 = INTERNET.HOST {
          hostname = INTERNET.HOSTNAME(NameOfTheHost);
          user = INTERNET.USER(doe,password,/home/doe/.ssh/id_rsa);
          transfer = TRANSFER.Apache_FTP;
          protocol = PROTOCOL.JTelnet(true);
          shell = SHELL.WinCommand;
          software {
            java = JAVA.JRE {
              archive = JAVA.ARCHIVE(/home/archives/JRE-1.5.tgz);
              home = JAVA.HOME(/home/doe/jdk1.5.0);
            }
          }
        }

        java-rmi-1 = JAVA.RMI.REGISTRY {
          host = Hosts/host-1
          # The 'java' element is not declared, so FDF will search it
          # inside the 'software' element of 'host-1'
          properties {
            port = JAVA.RMI.PORT(1099);
          }
        }
    

In this last example, both java and java-rmi software are described inside the software element of the host.

        host-1 = INTERNET.HOST {
          hostname = INTERNET.HOSTNAME(NameOfTheHost);
          user = INTERNET.USER(doe,password,/home/doe/.ssh/id_rsa);
          transfer = TRANSFER.Apache_FTP;
          protocol = PROTOCOL.JTelnet(true);
          shell = SHELL.WinCommand;
          software {
            java = JAVA.JRE {
              archive = JAVA.ARCHIVE(/home/archives/JRE-1.5.tgz);
              home = JAVA.HOME(/home/doe/jdk1.5.0);
            }
            java-rmi = JAVA.RMI.REGISTRY {
              properties {
                port = JAVA.RMI.PORT(1099);
              }
            }
          }
        }
    

Ant Personality

The ANT personality allows the deployment of Ant . The archive of this software is available here .

Figure 3.2, “Organization of the ANT Personality” represents the organization between software and properties inside the ANT personality and the relations with other elements outside of this personality.

Figure 3.2. Organization of the ANT Personality

Organization of the ANT Personality


This personality contains the following definitions:

Table 3.5. Definitions of the JAVA personality

NameDescription
ANT.APACHE_ANTSoftware for the deployment of Ant.
ANT.RUN(path_to_build.xml,task)Software for executing a ant task.
ANT.ARCHIVE(path_to_archive)Parameter representing a Ant archive.
ANT.HOME(home_directory) Parameter representing the Ant Home directory.
ANT.DependOn(XXX) To use in another software (XXX) that depends on Ant.


The following example is a standart description to deploy the Ant software:

            ant-1 = ANT.APACHE_ANT {
              archive = ANT.ARCHIVE(/home/user/archives/apache-ant.tgz);
              home = ANT.HOME(/targetDirectory/apache-ant);
              host = /Hosts/host-1;
            }

            ant-task = ANT.RUN(/mySoftware/build.xml,execute) {
              ant = ant-1;
            }
        

JOnAS Personality

The JOnAS personality allows the deployment of the JOnAS JEE server, and its libraries. The archive of this software is available here .

Figure 3.3, “Organization of the JOnAS Personality” represents the organization between software and properties inside the JOnAS personality and the relations with other elements outside of this personality.

Figure 3.3. Organization of the JOnAS Personality

Organization of the JOnAS Personality


This personality contains the following definitions:

Table 3.6. Definitions of the JOnAS personality

NameDescription
JOnAS.SERVER Software for the deployment of the JOnAS server.
JOnAS.Library Software for the deployment of the JOnAS server, as a library ( i.e. install the server without starting it: the start of the server is done by another software).
JOnAS.JONAS_BASE Software for the deployment of a JOnAS BASE server.
JOnAS.JONAS_ROOT Software for the deployment of a JOnAS ROOT server
JOnAS.CLUSTER_DAEMON Software for the deployment of a JOnAS cluster daemon.
JOnAS.ARCHIVE(path_to_archive)Parameter representing a JOnAS archive.
JOnAS.BASE(jonasbase_directory) Parameter representing the JONAS_BASE variable.
JOnAS.ROOT(jonasroot_directory) Parameter representing the JONAS_ROOT variable.
JOnAS.DOMAIN(name) Parameter representing the name of a JOnAS domain.
JOnAS.DependOn(XXX) To use in another software (XXX) that depends on JOnAS.
JOnAS.JClientRepresents the 'jclient' command line.
JOnAS.JClientCmd(command) Represents the value to use with the 'jclient' command.
JOnAS.NAME(name)Parameter representing the name of JOnAS.
JOnAS.FILE(path_to_file) Parameter representing a file to use with JOnAS.
JOnAS.EJB(path_to_archive)Represents an EJB to deploy on JOnAS.
JOnAS.EAR(path_to_archive)Represents an EAR to deploy on JOnAS.
JOnAS.WAR(path_to_archive)Represents a WAR to deploy on JOnAS.
JOnAS.RAR(path_to_archive)Represents a RAR to deploy on JOnAS.


The following example is the minimal description to write for using the JOnAS.SERVER software:

            jonas-1 = JOnAS.SERVER {
              archive    = JOnAS.ARCHIVE(/home/user/archives/jonas.tgz);
              root       = JOnAS.ROOT(/targetDirectory/jonas);
              host       = Hosts/host-1;
            }
        

Table 3.7, “Elements of the JONAS.SERVER software”, Table 3.8, “Elements of the JONAS.Library software”, Table 3.9, “Elements of the JONAS.JONAS_ROOT software”, Table 3.10, “Elements of the JONAS.JONAS_BASE software” and Table 3.11, “Elements of the JONAS.CLUSTER_DAEMON software” list the elements of software for the JOnAS personality.

Table 3.7. Elements of the JONAS.SERVER software

NameDefinitionDescription
archiveJOnAS.ARCHIVEPath to the JOnAS archive.
rootJOnAS.ROOTPath to JOnAS Root.
propertiesNone See Table 3.12, “Properties of the JOnAS.SERVER software” .



Table 3.8. Elements of the JONAS.Library software

NameDefinitionDescription
archiveJOnAS.ARCHIVEPath to the JOnAS archive.
homeJOnAS.ROOTPath to JOnAS Root.
baseJOnAS.BASEPath to JOnAS Base.



Table 3.9. Elements of the JONAS.JONAS_ROOT software

NameDefinitionDescription
archiveJOnAS.ARCHIVEPath to the JOnAS archive.
rootJOnAS.ROOTPath to JOnAS Root.
propertiesNone See Table 3.13, “ Properties of the JOnAS.JONAS_BASE, JOnAS.JONAS_ROOT and JOnAS.CLUSTER_DAEMON software ” .



Table 3.10. Elements of the JONAS.JONAS_BASE software

NameDefinitionDescription
archiveJOnAS.ARCHIVEPath to the JOnAS archive.
baseJOnAS.BASEPath to JOnAS Base.
propertiesNone See Table 3.13, “ Properties of the JOnAS.JONAS_BASE, JOnAS.JONAS_ROOT and JOnAS.CLUSTER_DAEMON software ” .
jonasrootJOnAS.JONAS_ROOT The JOnAS Root software on which depends JOnAS Base.



Table 3.11. Elements of the JONAS.CLUSTER_DAEMON software

NameDefinitionDescription
archiveJOnAS.ARCHIVEPath to the JOnAS archive.
baseJOnAS.BASEPath to JOnAS Base.
jonasrootJOnAS.JONAS_ROOT The JOnAS Root software on which depends the Cluster Daemon.
propertiesNone See Table 3.13, “ Properties of the JOnAS.JONAS_BASE, JOnAS.JONAS_ROOT and JOnAS.CLUSTER_DAEMON software ” .



Table 3.12, “Properties of the JOnAS.SERVER software” lists the configurable properties of the JOnAS.SERVER software.

Table 3.12. Properties of the JOnAS.SERVER software

NameDefinitionDescriptionDefault value
http-portHTTP.PORT The http port to use for the administration console 9000
nameJOnAS.NAMEThe name of the Jonas instanceJOnAS
domainJOnAS.DOMAINThe name of the Jonas domainThe value of the 'name' element



Table 3.13, “ Properties of the JOnAS.JONAS_BASE, JOnAS.JONAS_ROOT and JOnAS.CLUSTER_DAEMON software ” lists the configurable properties of the JOnAS.JONAS_BASE, JOnAS.JONAS_ROOT and JOnAS.CLUSTER_DAEMON software.

Table 3.13.  Properties of the JOnAS.JONAS_BASE, JOnAS.JONAS_ROOT and JOnAS.CLUSTER_DAEMON software

NameDefinitionDescriptionDefault value
nameJOnAS.NAMEThe name of the Jonas instanceJOnAS
domainJOnAS.DOMAINThe name of the Jonas domainThe value of the 'name' element



The following example is a description using all configurable elements of the JOnAS personality. In this example, 1 JOnAS server is described (jonas-1) and 8 business applications are described to be deployed on it (4 in the 'applications' element of 'jonas-1, and 4 outside of 'jonas-1', with a reference on the jonas server, thanks to the 'jonas' element in the business application description).

            jonas-1 = JOnAS.SERVER {
              archive = JOnAS.ARCHIVE(/home/user/archives/jonas.tgz);
              root    = JOnAS.ROOT(/targetDirectory/jonas);
              host    = Hosts/host-1;

              properties {
                http-port = HTTP.PORT(9000);
                name = JOnAS.NAME(JOnAS);
                domain = JOnAS.DOMAIN(JOnAS-domain);
              }
              
              applications {
                ear-1 = JOnAS.EAR(/home/user/archives/sample-ear-1.ear,MustBeInstalled);
                war-1 = JOnAS.WAR(/home/user/archives/sample-war-1.war,MustBeAutoload);
                ejb-1 = JOnAS.EJB(/home/user/archives/sample-ejb-1.jar,Standalone);
                rar-1 = JOnAS.RAR(/home/user/archives/sample-rar-1.rar,AlreadyInstalled);
              }
            }
            
            jonas-2 = JOnAS.Library {
              archive = JOnAS.ARCHIVE(/home/user/archives/jonaslib.tgz);
              home = JOnAS.ROOT(/targetDirectory/jonaslib);
              base = JOnAS.BASE(/targetDirectory/jonasbase1);
              host = Hosts/host-1;
            }
            
            jonas-3 = JOnAS.JONAS_ROOT {
              archive = JOnAS.ARCHIVE(/home/user/archives/jonasroot.tgz);
              root = JOnAS.ROOT(/targetDirectory/jonasroot);
              host = Hosts/host-1;
              properties {
                name = JOnAS.NAME(jonasRoot);
                domain = JOnAS.DOMAIN(JOnAS-domain);
              }
            }
            
            jonas-4 = JOnAS.JONAS_BASE {
              archive = JOnAS.ARCHIVE(/home/user/archives/jonasbase.tgz);
              base = JOnAS.BASE(/targetDirectory/jonasbase2);
              jonasroot = jonas-3;
              properties {
                name = JOnAS.NAME(jonasBase);
                domain = JOnAS.DOMAIN(JOnAS-domain);
              }
            }
            
            cluster = JOnAS.CLUSTER_DAEMON {
              archive = JOnAS.ARCHIVE(/home/user/archives/clusterDaemon.tgz);
              base = JOnAS.BASE(/targetDirectory/clusterd);
              jonasroot = jonas-3;
              properties {
                name = JOnAS.NAME(jonasBase);
                domain = JOnAS.DOMAIN(JOnAS-domain);
              }
            }
            
            ear-2 = JOnAS.EAR(/home/user/archives/sample-ear-2.ear,MustBeInstalled) {
              jonas = jonas-1;
            }

            war-2 = JOnAS.WAR(/home/user/archives/sample-war-2.war,MustBeAutoload) {
              jonas = jonas-1;
            }

            ejb-2 = JOnAS.EJB(/home/user/archives/sample-ejb-2.jar,Standalone) {
              jonas = jonas-1;
            }

            rar-2 = JOnAS.RAR(/home/user/archives/sample-rar-2.rar,AlreadyInstalled) {
              jonas = jonas-1;
            }
            
            # This element will launch the 'jclient' command for ejb-2
            jclient = JOnAS.JClient {
              jonas = jonas-1;
              command = JOnAS.JClientCmd(command_for_jclient);
              dependencies {
                /ejb-2;
              }
            }
            
        

HTTPD Personality

The HTTPD Personality allows the deployment of the Apache HTTP Server. The archive of this software is available here .

Figure 3.4, “Organization of the HTTPD Personality” represents the organization between software and properties inside the HTTPD personality and the relations with other elements outside of this personality.

Figure 3.4. Organization of the HTTPD Personality

Organization of the HTTPD Personality


Tomcat Personality

The TOMCAT personality allows the deployment of the Apache Tomcat Servlet Engine. The archive of this software is available here .

Figure 3.5, “Organization of the TOMCAT Personality” represents the organization between software and properties inside the TOMCAT personality and the relations with other elements outside of this personality.

Figure 3.5. Organization of the TOMCAT Personality

Organization of the TOMCAT Personality


This personality contains the following definitions:

Table 3.14. Definitions of the TOMCAT personality

NameDescription
TOMCAT.SERVER Software for the deployment of the Tomcat servlet engine.
TOMCAT.ARCHIVE(path_to_archive)Parameter representing a Tomcat archive.
TOMCAT.HOME(home_directory) Parameter representing the home directory of Tomcat.
TOMCAT.DependOn(XXX) To use in another software (XXX) that depends on Tomcat.
TOMCAT.WAR.COMPONENT Software for the deployment of a servlet on Tomcat.
TOMCAT.WAR.ARCHIVE(path_to_archive)Parameter representing a servlet archive.
TOMCAT.WAR.NAME(name)Parameter representing the name of a servlet.


The following example is the minimal description to write for using the TOMCAT.SERVER and TOMCAT.WAR.COMPONENT software:

            tomcat-1 = TOMCAT.SERVER {
              archive = TOMCAT.ARCHIVE(/home/user/archives/apache-tomcat.tgz);
              home    = TOMCAT.HOME(/targetDirectory/apache-tomcat);
              host    = Hosts/host-1;
            }
  
            servlet-1  = TOMCAT.WAR.COMPONENT {
              archive = TOMCAT.WAR.ARCHIVE(/home/user/archives/servlet.tgz);
              name    = TOMCAT.WAR.NAME(servlet_name);
              tomcat  = tomcat-1;
            }
   
        

Table 3.15, “Elements of the TOMCAT.SERVER software” and Table 3.16, “Elements of the TOMCAT.WAR.COMPONENT software” list the elements of software for the TOMCAT personality.

Table 3.15. Elements of the TOMCAT.SERVER software

NameDefinitionDescription
archiveTOMCAT.ARCHIVEPath to the Tomcat archive.
homeTOMCAT.HOMEPath to the Tomcat home.
propertiesNoneSee Table 3.17, “Properties of the TOMCAT.SERVER software”.



Table 3.16. Elements of the TOMCAT.WAR.COMPONENT software

NameDefinitionDescription
archiveTOMCAT.WAR.ARCHIVEPath to the Tomcat WAR archive.
nameTOMCAT.WAR.NAMEName of the application of the WAR.
tomcatTOMCAT.SERVERThe Tomcat server on which depends the WAR.



Table 3.17, “Properties of the TOMCAT.SERVER software” lists the configurable properties of the TOMCAT.SERVER software.

Table 3.17. Properties of the TOMCAT.SERVER software

NameDefinitionDescriptionDefault value
http-portHTTP.PORTThe http port used for the Tomcat administration page8080
http-userHTTP.USERThe login of the admin user.admin
http-passwordHTTP.PASSWORDThe password of the admin user.admin



The following example is a description of a Tomcat server using all configurable elements of the TOMCAT personality:

            tomcat-1 = TOMCAT.SERVER {
              archive = TOMCAT.ARCHIVE(/home/user/archives/apache-tomcat.tgz);
              home    = TOMCAT.HOME(/targetDirectory/apache-tomcat);
              host    = Hosts/host-1;
              properties {
                http-port = HTTP.PORT(7080);
                http-user = HTTP.USER(Aladdin);
                http-password = HTTP.PASSWORD(open-sesame);
              } 
            }
        

PEtALS Personality

The PEtALS personality allows the deployment of the PEtALS Enterprise Service Bus. The archive of this software is available here . Note that, if the archive is an auto installer ( e.g. with licence agreement), you must execute it and then re-archive the targeted directory.

Figure 3.6, “Organization of the PEtALS Personality” represents the organization between software and properties inside the PEtALS personality and the relations with other elements outside of this personality.

Figure 3.6. Organization of the PEtALS Personality

Organization of the PEtALS Personality


This personality contains the following definitions:

Table 3.18. Definitions of the PEtALS personality

NameDescription
PEtALS.SERVER Software for the deployment of the PEtALS server
PEtALS.NAME(name) Represents the name of a PEtALS server
PEtALS.ARCHIVE(path_to_archive)Parameter representing a PEtALS archive
PEtALS.HOME(home_directory) Parameter representing the home directory of PEtALS
PEtALS.DOMAIN(name)Parameter representing a PEtALS domain
PEtALS.DOMAIN.NAME(name)Represents the name of a PEtALS domain
PEtALS.DOMAIN.MODE(mode)Represents the mode of a PEtALS domain (static|dynamic|standalone)
PEtALS.DOMAIN.MULTICAST(ip,port)Represents the multicast ip/port used within a PEtALS domain for communication between servers
PEtALS.SUBDOMAIN(name)Parameter representing a PEtALS subdomain
PEtALS.SUBDOMAIN.NAME(name)Represents the name of a PEtALS subdomain
PEtALS.PORTRepresents the port used by a PEtALS server to listen messages
PEtALS.TIMEOUTRepresents the timeout period (in ms) before a JBI component lifecycle state change is considered as blocked
PEtALS.JBI Software for the deployment of a JBI component on PEtALS
PEtALS.SA Software for the deployment of a Service Assembly on PEtALS


The following example illustrate how to use the PEtALS personality. A PEtALS.SERVER must be placed in a PEtALS.SUBDOMAIN, itself placed in a PEtALS.DOMAIN. Furthermore, references to thoses definitions must start with "petals" for PEtALS.SERVER, "sub-domain" and domain, in order to generate a well-formed configuration file (topology.xml) for the PEtALS domain.

        
            domain = PEtALS.DOMAIN(PEtALS) {
              mode = PEtALS.DOMAIN.MODE(static);
              multicast = PEtALS.DOMAIN.MULTICAST(224.7.65.50,8000);

              sub-domain-1 = PEtALS.SUBDOMAIN(subdomain1) {

                petals-1 = PEtALS.SERVER(1) {
                  archive = PEtALS.ARCHIVE(/archives/petals.zip);
                  home    = PEtALS.HOME(/usr/local/petals);
                  host    = Hosts/host1;
                }

                petals-2 = PEtALS.SERVER(2) {
                  archive = PEtALS.ARCHIVE(/archives/petals.zip);
                  home    = PEtALS.HOME(/usr/local/petals);
                  host    = Hosts/host2;
                }
              }

              sub-domain-2 = PEtALS.SUBDOMAIN(subdomain2) {

                petals-3 = PEtALS.SERVER(3) {
                  archive = PEtALS.ARCHIVE(/archives/petals.zip);
                  home    = PEtALS.HOME(/usr/local/petals);
                  host    = Hosts/host3;
                }

                petals-4 = PEtALS.SERVER(4) {
                  archive = PEtALS.ARCHIVE(/archives/petals.zip);
                  home    = PEtALS.HOME(/usr/local/petals);
                  host    = Hosts/host4;
                }
              }

            }
  
  
            # Description of JBI components to deploy on PEtALS servers

            JBI-Components {

              JBI1-on-host1 = PEtALS.JBI {
                archive = PEtALS.ARCHIVE(/archives/jbi-1.zip);
                petals  = domain/sub-domain-1/petals-1;
              }

              JBI2-on-host1 = PEtALS.JBI {
                archive = PEtALS.ARCHIVE(/archives/jbi-2.zip);
                petals  = domain/sub-domain-1/petals-2;
              }

              JBI1-on-host2 = PEtALS.JBI {
                archive = PEtALS.ARCHIVE(/archives/jbi-3.zip);
                petals  = domain/sub-domain-2/petals-3;
              }
            }

        

Table 3.19, “Elements of the PEtALS.SERVER software” and Table 3.20, “Elements of the PEtALS.JBI and PEtALS.SA software” list the elements of software for the PEtALS personality.

Table 3.19. Elements of the PEtALS.SERVER software

NameDefinitionDescription
archivePEtALS.ARCHIVEPath to the PEtALS archive.
homePEtALS.HOMEPath to the PEtALS Home.
propertiesNoneSee Table 3.21, “Properties of the PEtALS.SERVER Software”.



Table 3.20. Elements of the PEtALS.JBI and PEtALS.SA software

NameDefinitionDescription
archivePEtALS.ARCHIVEArchive of the JBI or SA component
petalsPEtALS.SERVERThe PEtALS server on which depends the JBI or SA.



Table 3.21, “Properties of the PEtALS.SERVER Software” lists the configurable properties of the PEtALS.SERVER software.

Table 3.21. Properties of the PEtALS.SERVER Software

NameDefinitionDescriptionDefault Value
petals-portPEtALS.PORTThe port used by PEtALS servers to listen messages.7720
rmi-portJAVA.RMI.PORTThe port used by PEtALS servers for java RMI communication.7720
jmx-userJMX.USERThe name of the user that control PEtALS throught JMX.''
jmx-passwordJMX.PASSWORDThe password of the JMX user.''
jmx-portJMX.PORTThe port used to control PEtALS throught JMX.8081
joram-domainportJORAM.DOMAINPORTThe port used for communication on the Joram domain.7740
joram-tcpportJORAM.TCPPORTThe port used for Joram TCP communications.7760
dream-portDREAM.PORTThe port used by DREAM for communication between PEtALS servers.7800
task-timeoutPEtALS.TIMEOUTThe timeout (in ms) before a JBI component lifecycle state change is considered as blocked.5000



The following example is a description of a PEtALS server using all configurable elements of the PEtALS personality:

                petals-1 = PEtALS.SERVER(1) {
                  archive = PEtALS.ARCHIVE(/archives/petals.zip);
                  home    = PEtALS.HOME(/usr/local/petals);
                  host    = Hosts/host1;
                  properties {
                    petals-port      = PEtALS.PORT(7721);      ##### default = 7720
                    rmi-port         = JAVA.RMI.PORT(3001);    ##### default = 3000
                    jmx-user         = JMX.USER(open);         ##### default = petals
                    jmx-password     = JMX.PASSWORD(sesame);   ##### default = petals
                    jmx-port         = JMX.PORT(7701);         ##### default = 7700
                    joram-domainport = JORAM.DOMAINPORT(7741); ##### default = 7740
                    joram-tcpport    = JORAM.TCPPORT(7761);    ##### default = 7760
                    dream-port       = DREAM.PORT(7801);       ##### default = 7800
                    task-timeout     = PEtALS.TIMEOUT(10000);  ##### default = 5000
                  }
                }
        

Jade Personality

The JADE personality allows the deployment of Jade . This software can be recovered from its svn repository: svn://svn.forge.objectweb.org/svnroot/jasmine/Jade

With Jade, each host of the network hosts a JadeNode which is the entity that monitor the host. A particular JadeNode has to be installed on one host of the domain, in order to deal with the JadeNode of each host: this JadeNode is called 'JadeBoot'. So in the JADE personality of FDF, you will find two software: BOOT and NODE.

Figure 3.7, “Organization of the JADE Personality” represents the organization between software and properties inside the JADE personality and the relations with other elements outside of this personality.

Figure 3.7. Organization of the JADE Personality

Organization of the JADE Personality


This personality contains the following definitions:

Table 3.22. Definitions of the JADE personality

NameDescription
JADE.BOOTSoftware for the deployment of a Jade boot.
JADE.NODESoftware for the deployment of a Jade node.
JADE.ARCHIVE(path_to_archive)Parameter representing a Jade archive.
JADE.HOME(home_directory) Parameter representing the Jade Home directory.
JADE.DOMAIN(jadeboot-hostname) Element that fixes the jadeboot hostname for a set of jadenodes.
JADE.PORT(value)Parameter representing a Jade port.
JADE.PARAMETER(name,value)Parameter representing a Jade parameter.


The following example is the minimal description to write for using the JADE.BOOT and JADE.NODE software:

            jadeboot-host-1 = JADE.BOOT {
              archive = JADE.ARCHIVE(/home/user/archives/JadeBoot.tgz);
              home    = JADE.HOME(/targetDirectory/jadeboot);
              host    = Hosts/host-1;
              properties {
                oscar-repository-url          = HTTP.LINK(http://proton.inrialpes.fr/~jlegrand/repo.dev/repository.xml);
                oscar-auto-start-1            = JADE.PARAMETER(Autostarted bundles,
                                                 'http://proton.inrialpes.fr/~jlegrand/repo/bundlerepository/base/shell.jar
                                                  http://proton.inrialpes.fr/~jlegrand/repo/bundlerepository/base/bundlerepository.jar
                                                  http://proton.inrialpes.fr/~jlegrand/repo/bundlerepository/properties.jar
                                                  http://proton.inrialpes.fr/~jlegrand/repo/bundlerepository/jade/jadeboot.jar');
                jadeboot-urls-deployable-file = HTTP.LINK(http://proton.inrialpes.fr/~jlegrand/jade/examples);
              }
            }

            jadenode-host-2 = JADE.NODE {
              archive  = JADE.ARCHIVE(/home/user/archives/JadeNode.tgz);
              home     = JADE.HOME(/targetDirectory/jadenode);
              host     = Hosts/host-2;
              jadeboot = jadeboot-host-1;
              properties {
                oscar-repository-url = HTTP.LINK(http://proton.inrialpes.fr/~jlegrand/repo.dev/repository.xml);
                oscar-auto-start-1   = JADE.PARAMETER(Autostarted bundles,'http://proton.inrialpes.fr/~jlegrand/repo/bundlerepository/base/shell.jar
                                         http://proton.inrialpes.fr/~jlegrand/repo/bundlerepository/base/bundlerepository.jar
                                         http://proton.inrialpes.fr/~jlegrand/repo/bundlerepository/properties.jar
                                         http://proton.inrialpes.fr/~jlegrand/repo/bundlerepository/jade/jadenode.jar');
              }
            }
        

Table 3.23, “Elements of the JADE.BOOT software” and Table 3.24, “Elements of the JADE.NODE software” list the elements of software for the JADE personality.

Table 3.23. Elements of the JADE.BOOT software

NameDefinitionDescription
archiveJADE.ARCHIVEPath to the Jadeboot archive.
homeJADE.HOMEPath to the Jadeboot Home.
propertiesNoneSee Table 3.25, “Properties of the JADE.BOOT software”.



Table 3.24. Elements of the JADE.NODE software

NameDefinitionDescription
archiveJADE.ARCHIVEPath to the Jadenode archive.
homeJADE.HOMEPath to the Jadenode Home.
jadebootJADE.BOOTThe Jadeboot on which depends the Jadenode.
propertiesNoneSee Table 3.26, “Properties of the JADE.NODE Software”.



Table 3.25, “Properties of the JADE.BOOT software” and Table 3.26, “Properties of the JADE.NODE Software” list the configurable properties of the JADE.BOOT and JADE.NODE software.

Table 3.25. Properties of the JADE.BOOT software

NameDefinitionDescriptionDefault value
oscar-repository-urlHTTP.LINKThe URL of the Oscar repository used by Jade (Required).None
oscar-profileJADE.PARAMETERThe name of the Oscar profile.jadeboot
oscar-auto-start-1JADE.PARAMETERThe list of bundles to start with the jadeboot (Required).None
jadeboot-registry-hostJADE.PARAMETERThe name of the jadeboot host.Value of the hostname where jadeboot is deployed
jadeboot-registry-portJADE.PARAMETERPort of the Fractal RMI registry.1238
jadeboot-discovery-hostJADE.PARAMETERThe localisation of the Node discovery service.Value of the hostname where jadeboot is deployed
jadeboot-discovery-portJADE.PARAMETERThe port of the Node discovery service.9998
jade-reflexJADE.PARAMETERActivate the system representation.false
jade-reflex-nameJADE.PARAMETERThe name of the Fractal bootstrap.None
jade-reflex-dual-nameJADE.PARAMETERThe name of the Reflex Fractal bootstrap.None
jade-reflex-autoJADE.PARAMETEREnables the automatic reflex mode.None
jadeboot-urls-deployable-fileHTTP.LINKThe list of URL deployable bundles.None
jadeboot-jndi-portJADE.PARAMETERThe port of the Joram JNDI.1239
osgi-http-portHTTP.PORTThe HTTP port of the OSGI platform.9090
jonathan-connectionfactory-hostJADE.PARAMETERIP address bound to interface that Jonathan must use to create connection.None



Table 3.26. Properties of the JADE.NODE Software

NameDefinitionDescriptionDefault Value
oscar-repository-urlHTTP.LINKThe URL of the Oscar repository.http://proton.inrialpes.fr/~jlegrand/repo.jasmine/repository.xml
oscar-profileJADE.PARAMETERThe name of the Oscar profile.jadenode
oscar-auto-start-1JADE.PARAMETERThe list of bundles to start with the jadenode (Required).None
jade-registry-hostJADE.PARAMETERJadeboot hostnameHostname of the jadeboot
jade-registry-portJADE.PARAMETERPort of the Fractal RMI registryPort of the jadeboot registry
jade-discovery-hostJADE.PARAMETERLocalisation of the Node discovery serviceHostname of the jadeboot
jade-discovery-portJADE.PARAMETERPort of the Node discovery serviceDiscovery port of the jadeboot
jade-reflexJADE.PARAMETERActivation of the System representationfalse
jade-reflex-nameJADE.PARAMETERName of the Fractal bootstrap useful for the Reflex serviceNone
jade-reflex-dual-nameJADE.PARAMETERName of the Reflex Fractal bootstrap useful for the Reflex serviceNone
jade-reflex-autoJADE.PARAMETEREnables the automatic reflex mode.None
jadenode-heartbeat-pulseJADE.PARAMETERHeatbeat period in secondNone
osgi-http-portHTTP.PORTThe HTTP port of the OSGI platform.9090
jonathan-connectionfactory-hostJADE.PARAMETERIP address bound to interface that Jonathan must use create connectionNone



The following example is a description using all configurable elements of the JADE personality:

            jadeboot-host-1 = JADE.BOOT {
              archive  = JADE.ARCHIVE(/home/user/archives/JadeBoot.tgz);
              home     = JADE.HOME(/targetDirectory/jadeboot);
              host     = Hosts/host-1;
              properties {
                oscar-repository-url            = HTTP.LINK(http://proton.inrialpes.fr/~jlegrand/repo.jasmine/repository.xml);
                oscar-auto-start-1              = JADE.PARAMETER(Autostarted bundles,
                                                   'http://proton.inrialpes.fr/~jlegrand/repo.jasmine/bundlerepository/base/shell.jar
                                                    http://proton.inrialpes.fr/~jlegrand/repo.jasmine/bundlerepository/base/bundlerepository-extended.jar
                                                    http://proton.inrialpes.fr/~jlegrand/repo.jasmine/bundlerepository/properties.jar
                                                    http://proton.inrialpes.fr/~jlegrand/repo.jasmine/bundlerepository/jade/2.0M1/jadeboot.jar');
                jadeboot-urls-deployable-file   = JADE.PARAMETER(url of directories and jars containing deployable adl files,
                                                    http://proton.inrialpes.fr/~jlegrand/jade/examples/2.0M1/;
                                                    http://proton.inrialpes.fr/~jlegrand/jade/examples/j2ee.jar;
                                                    http://proton.inrialpes.fr/~fmetral/jade/joramTypes.jar);
                oscar-profile                   = JADE.PARAMETER(Oscar profile name,jadeboot);
                jadeboot-registry-host          = JADE.PARAMETER(Jadeboot hostname,hostname_of_jadeboot);
                jadeboot-registry-port          = JADE.PARAMETER(Port of the Fractal RMI registry,1238);
                jadeboot-discovery-host         = JADE.PARAMETER(Localisation of the Node discovery service,hostname_of_jadeboot);
                jadeboot-discovery-port         = JADE.PARAMETER(Port of the Node discovery service,9998);
                jade-reflex                     = JADE.PARAMETER(Activation of the System representation,false);
                jade-reflex-name                = JADE.PARAMETER(Name of the Fractal bootstrap, useful for the Reflex service,boot);
                jade-reflex-dual-name           = JADE.PARAMETER(Name of the Reflex Fractal bootstrap, useful for the Reflex service,boot);
                jade-reflex-auto                = JADE.PARAMETER(Enables the automatic reflex mode,false);
                jadeboot-jndi-port              = JADE.PARAMETER(Port of the Joram JNDI,1239);
                osgi-http-port                  = HTTP.PORT(9090);
                jonathan-connectionfactory-host = JADE.PARAMETER(IP address bound to interface that Jonathan must use to create connection,"jadeboot-ip");
              }
            }
            
            jadenode-host-2 = JADE.NODE {
              archive    = JADE.ARCHIVE(/home/user/archives/JadeNode.tgz);
              home       = JADE.HOME(/targetDirectory/jadeboot);
              host       = Hosts/host-2;
              jadeboot   = jadeboot-host-1;
              properties {
                oscar-repository-url     = HTTP.LINK(http://proton.inrialpes.fr/~jlegrand/repo.jasmine/repository.xml);
                oscar-profile            = JADE.PARAMETER(Oscar profile name,jadenode);
                oscar-auto-start-1       = JADE.PARAMETER(Autostarted bundles,
                                            'http://proton.inrialpes.fr/~jlegrand/repo.jasmine/bundlerepository/base/shell.jar
                                             http://proton.inrialpes.fr/~jlegrand/repo.jasmine/bundlerepository/base/bundlerepository-extended.jar
                                             http://proton.inrialpes.fr/~jlegrand/repo.jasmine/bundlerepository/properties.jar
                                             http://proton.inrialpes.fr/~jlegrand/repo.jasmine/bundlerepository/jade/2.0M1/jadenode.jar');
                jade-registry-host       = JADE.PARAMETER(Jadeboot hostname,hostname_of_jadeboot);
                jade-registry-port       = JADE.PARAMETER(Port of the Fractal RMI registry,1238);
                jade-discovery-host      = JADE.PARAMETER(Localisation of the Node discovery service,hostname_of_jadeboot);
                jade-discovery-port      = JADE.PARAMETER(Port of the Node discovery service,9998);
                jade-reflex              = JADE.PARAMETER(Activation of the System representation,false);
                jade-reflex-name         = JADE.PARAMETER(Name of the Fractal bootstrap useful for the Reflex service,node);
                jade-reflex-dual-name    = JADE.PARAMETER(Name of the Reflex Fractal bootstrap useful for the Reflex service,node);
                jade-reflex-auto         = JADE.PARAMETER(Enables the automatic reflex mode,false);
                jadenode-heartbeat-pulse = JADE.PARAMETER(Heatbeat period in second,3);
                osgi-http-port           = HTTP.PORT(9090);
                jonathan-connectionfactory-host = JADE.PARAMETER(IP address bound to interface that Jonathan must use create connection,"jadenode-ip");              }
              }
            }           
        

JASMINe Personality

The JASMINe personality allows the deployment of JASMINe. The archive of this software is available here. JASMINe relies on Jade, but, for instance, the embedded Jade version isn't the same than the version provided in the JADE personality. So the JASMINe personality uses its own JADEBOOT and JADENODE software.

Figure 3.8, “Organization of the JASMINe Personality” represents the organization between software and properties inside the JASMINe personality and the relations with other elements outside of this personality.

Figure 3.8. Organization of the JASMINe Personality

Organization of the JASMINe Personality


This personality contains the following definitions:

Table 3.27. Definitions of the JASMINe personality

NameDescription
JASMINe.FRAMEWORK Software for the deployment of the JASMINe engine.
JASMINe.GUI Software for the deployment of the JASMINe user interface.
JASMINe.JADEBOOT Software for the deployment of a jadeboot for JASMINe.
JASMINe.JADENODE Software for the deployment of a jadenode for JASMINe.
JASMINe.JADEJMX Software for the deployment of jadejmx (for JMX management) for JASMINe.
JASMINe.ARCHIVE(path_to_archive)Parameter representing a JASMINe archive.
JASMINe.HOME(home_directory) Parameter representing the home directory of JASMINe.
JASMINe.DependOn(XXX) To use in another software (XXX) that depends on JASMINe.


The following example is the minimal description to write for using software of the JASMINe personality:

            jadeboot-host-1 = JASMINe.JADEBOOT {
              archive = JADE.ARCHIVE(/home/user/archives/Jadeboot.tgz);
              home    = JADE.HOME(/targetDirectory/jadeboot);
              host    = Hosts/host-1;
              properties {
                oscar-repository-url   = HTTP.LINK(http://proton.inrialpes.fr/~jlegrand/repo.dev/repository.xml);
                oscar-auto-start-1     = JADE.PARAMETER(Autostarted bundles,
                                          'http://proton.inrialpes.fr/~jlegrand/repo/bundlerepository/base/shell.jar
                                           http://proton.inrialpes.fr/~jlegrand/repo/bundlerepository/base/bundlerepository.jar
                                           http://proton.inrialpes.fr/~jlegrand/repo/bundlerepository/properties.jar
                                           http://proton.inrialpes.fr/~jlegrand/repo/bundlerepository/jade/jadeboot.jar');
              }
            }

            jadenode-host-2 = JASMINe.JADENODE {
              archive = JADE.ARCHIVE(/home/user/archives/Jadenode.tgz);
              home    = JADE.HOME(/targetDirectory/jadenode);
              jadeboot = jadeboot-host-1;
              host = Hosts/host-2;
              properties {
                oscar-repository-url = HTTP.LINK(http://proton.inrialpes.fr/~jlegrand/repo.dev/repository.xml);
                oscar-auto-start-1   = JADE.PARAMETER(Autostarted bundles,
                                        'http://proton.inrialpes.fr/~jlegrand/repo/bundlerepository/base/shell.jar
                                         http://proton.inrialpes.fr/~jlegrand/repo/bundlerepository/base/bundlerepository.jar
                                         http://proton.inrialpes.fr/~jlegrand/repo/bundlerepository/properties.jar
                                         http://proton.inrialpes.fr/~jlegrand/repo/bundlerepository/jade/jadenode.jar');
              }
            }

            jadejmx-host-1 = JASMINe.JADEJMX {
              archive = JADE.ARCHIVE(/home/user/archives/Jadejmx.tgz);
              home    = JADE.HOME(/targetDirectory/jadejmx);
              host = Hosts/host-1;
            }

            JASMINe-1 = JASMINe.FRAMEWORK {
              archive = JASMINe.ARCHIVE(/home/user/archives/Jasmine.tgz);
              home    = JASMINe.HOME(/targetDirectory/jasmine);
              jadeboot = jadeboot-host-1;
              jonas = JOnAS.SERVER {
                archive = JOnAS.ARCHIVE(/home/user/archives/jonas.tgz);
                root = JOnAS.ROOT(/targetDirectory/jonas);
                base = JOnAS.BASE(/targetDirectory/jonasBase);
              }
            }

            JASMINe-GUI = JASMINe.GUI {
              archive = JASMINe.ARCHIVE(/home/user/archives/JasmineGUI.tgz);
              home    = JASMINe.HOME(/targetDirectory/jasmineUI);
              jasmine = JASMINe-1;
              jadejmx = jadejmx-host-1;
              jadeboot = jadeboot-host-1;
            }
        

Table 3.28, “Elements of the JASMINe.FRAMEWORK software”, Table 3.29, “Elements of the JASMINe.GUI software”, Table 3.30, “Elements of the JASMINe.JADEBOOT software”, Table 3.31, “Elements of the JASMINe.JADENODE software” and Table 3.32, “Elements of the JASMINe.JADEJMX software” list the elements of software for the JASMINe personality.

Table 3.28. Elements of the JASMINe.FRAMEWORK software

NameDefinitionDescription
archiveJASMINe.ARCHIVEPath to the JASMINe framework archive.
homeJASMINe.HOMEPath to the JASMINe framework home.
jonasJOnAS.SERVERThe JOnAS server on which depends the JASMINe framework.
jadebootJASMINe.JADEBOOTThe Jadeboot on which depends the JASMINe framework.
ant (optional if defined inside the host)ANT.APACHE_ANTThe ANT software on which depends the JASMINe framework.



Table 3.29. Elements of the JASMINe.GUI software

NameDefinitionDescription
archiveJASMINe.ARCHIVEPath to the JASMINe GUI archive.
homeJASMINe.HOMEPath to the JASMINe GUI home.
jadejmxJASMINe.JADEJMXThe Jade JMX software on which depends JASMINe GUI.
jadebootJASMINe.JADEBOOTThe Jadeboot software on which depends JASMINe GUI.
jasmineJASMINe.FRAMEWORKThe JASMINe framework on which depends JASMINe GUI.



Table 3.30. Elements of the JASMINe.JADEBOOT software

NameDefinitionDescription
archiveJADE.ARCHIVEPath to the Jadeboot archive.
homeJADE.HOMEPath to the Jadeboot home.
propertiesNoneSee Table 3.33, “Properties of the JASMINe.JADEBOOT software”.
ant (optional if defined inside the host)ANT.APACHE_ANTThe ANT software on which depends the Jadeboot.



Table 3.31. Elements of the JASMINe.JADENODE software

NameDefinitionDescription
archiveJADE.ARCHIVEPath to the Jadenode archive.
homeJADE.HOMEPath to the Jadenode home.
jadebootJASMINe.JADEBOOTThe Jadeboot software on which depends the JASMINe Jadenode.
ant (optional if defined inside the host)ANT.APACHE_ANTThe ANT software on which depends the Jadenode.
propertiesNoneSee Table 3.34, “Properties of the JASMINe.JADENODE software”.



Table 3.32. Elements of the JASMINe.JADEJMX software

NameDefinitionDescription
archiveJADE.ARCHIVEPath to the Jade JMX archive.
homeJADE.HOMEPath to the Jade JMX home.
ant (optional if defined inside the host)ANT.APACHE_ANTThe ANT software on which depends Jade JMX.
propertiesNoneSee Table 3.35, “Properties of the JASMINe.JADEJMX software”.



Table 3.33, “Properties of the JASMINe.JADEBOOT software”, Table 3.34, “Properties of the JASMINe.JADENODE software” and Table 3.35, “Properties of the JASMINe.JADEJMX software” list the configurable properties of the JASMINe personality.

Table 3.33. Properties of the JASMINe.JADEBOOT software

NameDefinitionDescriptionDefault value
oscar-repository-urlHTTP.LINKThe URL of the Oscar repository used by Jade (Required).None
oscar-auto-start-1JADE.PARAMETERThe list of bundles to start with the jadeboot (Required).None
jadeboot-registry-hostJADE.PARAMETERThe name of the jadeboot host.Hostname of the jadeboot
jadeboot-registry-portJADE.PARAMETERPort of the Fractal RMI registry.1238



Table 3.34. Properties of the JASMINe.JADENODE software

NameDefinitionDescriptionDefault value
oscar-repository-urlHTTP.LINKThe URL of the Oscar repository used by Jade (Required).None
oscar-auto-start-1JADE.PARAMETERThe list of bundles to start with the jadeboot (Required).None



Table 3.35. Properties of the JASMINe.JADEJMX software

NameDefinitionDescriptionDefault value
rmi-portJADE.PORTThe port of the RMI registry.9098



Orchestra Personality

The ORCHESTRA personality allows the deployment of the Orchestra BPEL processes workflow engine. The archive of this software is available here .

Figure 3.9, “Organization of the ORCHESTRA Personality” represents the organization between software and properties inside the ORCHESTRA personality and the relations with other elements outside of this personality.

Figure 3.9. Organization of the ORCHESTRA Personality

Organization of the ORCHESTRA Personality


This personality contains the following definitions:

Table 3.36. Definitions of the ORCHESTRA personality

NameDescription
ORCHESTRA.SERVER Software for the deployment of the ORCHESTRA server.
ORCHESTRA.ARCHIVE(path_to_archive)Parameter representing an Orchestra archive.
ORCHESTRA.HOME(home_directory) Parameter representing the home directory of Orchestra.
ORCHESTRA.BPEL.PROCESS Software for the deployment of a BPEL process on the ORCHESTRA server.
ORCHESTRA.BPEL.ARCHIVEParameter representing an BPEL archive.
ORCHESTRA.BPEL.HOME Parameter representing the home directory of a BPEL process.
ORCHESTRA.BPEL.NAME Parameter representing the name of a BPEL process.
ORCHESTRA.BPEL.CLIENTCLASS Parameter representing the class of a BPEL client.
ORCHESTRA.BPEL.CLIENTARGS Parameter representing the arguments of a BPEL client.


The following example is the minimal description to write for using the ORCHESTRA.SERVER and ORCHESTRA.BPEL.PROCESS software:

            ant-1 = ANT.APACHE_ANT {
              archive = ANT.ARCHIVE(/home/user/archives/apache-ant.tgz);
              home    = ANT.HOME(/targetDirectory/apache-ant);
              host = Hosts/host-1;
            }

            orchestra-1 = ORCHESTRA.SERVER {
              archive = ORCHESTRA.ARCHIVE(/home/user/archives/orchestra.tgz);
              home    = ORCHESTRA.HOME(/targetDirectory/orchestra);
              host = Hosts/host-1;
              jonas = JOnAS.Library {
                archive = JOnAS.ARCHIVE(/home/user/archives/jonas.tgz);
                home = JOnAS.ROOT(/targetDirectory/jonas);
                base = JOnAS.BASE(/targetDirectory/jonasBase);
              }
              ant = ant-1;
            }

            bpel-1 = ORCHESTRA.BPEL.PROCESS {
              archive   = ORCHESTRA.BPEL.ARCHIVE(/home/user/archives/bpel.zip);
              home      = ORCHESTRA.BPEL.HOME(/targetDirectory/bpel-1);
              name      = ORCHESTRA.BPEL.NAME(bpel-name);
              className = ORCHESTRA.BPEL.CLIENTCLASS(Main_class_of_the_client);
              args      = ORCHESTRA.BPEL.CLIENTARGS(arguments_of_the_client);
              outWS     = INTERNET.WEBSERVICE(external_service_wsdl_file);
              orchestra = orchestra-1;
            }

        

Table 3.37, “Elements of the ORCHESTRA.SERVER software” and Table 3.38, “Elements of the ORCHESTRA.BPEL.PROCESS software” list the elements of software for the ORCHESTRA personality.

Table 3.37. Elements of the ORCHESTRA.SERVER software

NameDefinitionDescription
archiveORCHESTRA.ARCHIVE(path_to_archive)Path to the Orchestra archive.
homeORCHESTRA.HOME(home_directory)Path to the Orchestra home.
jonasJOnAS.LibraryThe JOnAS server on which depends the Orchestra server.
propertiesNoneSee Table 3.39, “Properties of the ORCHESTRA.SERVER software”.



Table 3.38. Elements of the ORCHESTRA.BPEL.PROCESS software

NameDefinition
archiveORCHESTRA.BPEL.ARCHIVE(path_to_archive)
homeORCHESTRA.BPEL.HOME(home_directory)
nameORCHESTRA.BPEL.NAME(bpel-name)
classNameORCHESTRA.BPEL.CLIENTCLASS(class-name)
argsORCHESTRA.BPEL.CLIENTARGS(client-args)
outWSINTERNET.WEBSERVICE(external_service_wsdl_file)
orchestraORCHESTRA.SERVER
propertiesNone



Table 3.39, “Properties of the ORCHESTRA.SERVER software” lists the configurable properties of the ORCHESTRA.SERVER software.

Table 3.39. Properties of the ORCHESTRA.SERVER software

NameDefinitionDescriptionDefault value
database-portDATABASE.PORTThe port of the Orchestra database.9001
tomcat-portHTTP.PORTThe port of the underlying Tomcat server.9000
a3server-portJORAM.TCPPORTThe port of the Joram server.16010
jrmp-portJAVA.RMI.PORTThe JRMP port.1099



Table 3.40, “Properties of the ORCHESTRA.BPEL.PROCESS software” lists the configurable properties of the ORCHESTRA.BPEL.PROCESS software.

Table 3.40. Properties of the ORCHESTRA.BPEL.PROCESS software

NameDefinitionDescriptionDefault value
http-portHTTP.PORTThe webservice HTTP port of the BPEL process.9000



MySQL Personality

The MySQL personality allows the deployment of a MySQL database. The archive of this software is available here.

Figure 3.10, “Organization of the MySQL Personality” represents the organization between software and properties inside the MySQL personality and the relations with other elements outside of this personality.

Figure 3.10. Organization of the MySQL Personality

Organization of the MySQL Personality


This personality contains the following definitions:

Table 3.41. Definitions of the MySQL personality

NameDescription
MySQL.SERVER Software for the deployment of a MySQL database.
MySQL.ARCHIVEParameter representing a MySQL archive.
MySQL.HOME Parameter representing the MySQL Home directory.
MySQL.USERParameter representing a MySQL user.
MySQL.PASSWORD Parameter representing the password of a MySQL user.
MySQL.PORT Parameter representing the port of a MySQL database.
MySQL.DataHOME Parameter representing the home directory of MySQL data.


The following example is the minimal description to write for using the MySQL software:

            MySQL-host1 = MySQL.SERVER {
              archive   = MySQL.ARCHIVE(/home/user/archives/MySQL.tgz);
              home      = MySQL.HOME(/targetDirectory/mySQL);
              host      = Hosts/host-1;
            }
        

Table 3.42, “Elements of the MySQL.SERVER software” lists the elements of the MySQL.SERVER software.

Table 3.42. Elements of the MySQL.SERVER software

NameDefinitionDescription
archiveMySQL.ARCHIVE(path_to_archive)Path to the MySQL archive.
homeMySQL.HOME(home_directory)Path to the MySQL home.
propertiesNoneSee Table 3.43, “Properties of the MySQL.SERVER software”.



Table 3.43, “Properties of the MySQL.SERVER software” lists the configurable properties of the MySQL.SERVER software.

Table 3.43. Properties of the MySQL.SERVER software

NameDefinitionDescriptionDefault value
data-homeMySQL.DataHOMEHome directory for MySQL data$MYSQL_HOME/data
mysql-portMySQL.PORTPort of the MySQL database3306
mysql-userMySQL.USERUser name of the databaseadmin
mysql-passwordMySQL.PASSWORDPassword of the MySQL useradmin



The following example is a description using all configurable elements of the MySQL software:

            MySQL-host1 = MySQL.SERVER {
              archive   = MySQL.ARCHIVE(/home/user/archives/MySQL.tgz);
              home      = MySQL.HOME(/targetDirectory/mySQL);
              host      = Hosts/host-1;
              properties {
                data-home      = MySQL.DataHOME(/targetDirectory/mySQL/data);
                mysql-port     = MySQL.PORT(3306);
                mysql-user     = MySQL.USER(admin);
                mysql-password = MySQL.PASSWORD(admin);
              }
            }
        

Geronimo Personality

The Geronimo personality allows the deployment of the Geronimo JEE server. The archive of this software is available here.

Figure 3.11, “Organization of the Geronimo Personality” represents the organization between software and properties inside the Geronimo personality and the relations with other elements outside of this personality.

Figure 3.11. Organization of the Geronimo Personality

Organization of the Geronimo Personality


This personality contains the following definitions:

Table 3.44. Definitions of the Geronimo personality

NameDescription
Geronimo.SERVERSoftware for the deployment of a Geronimo.
Geronimo.ARCHIVE(path_to_archive)Parameter representing a Geronimo archive.
Geronimo.HOME(home_directory) Parameter representing the Geronimo Home directory.


The following example is a standart description to deploy the Geronimo.SERVER software:

            geronimo-1 = Geronimo.SERVER {
              archive = ANT.ARCHIVE(/home/user/archives/geronimo.tgz);
              home    = ANT.HOME(/targetDirectory/geronimo);
              host = /Hosts/host-1;
              properties {
                http-port = HTTP.PORT(8080);
              }
            }
        

Table 3.45, “Elements of the Geronimo.SERVER software” lists the elements of the Geronimo.SERVER software.

Table 3.45. Elements of the Geronimo.SERVER software

NameDefinitionDescription
archiveGeronimo.ARCHIVEPath to the Geronimo archive.
homeGeronimo.HOMEPath to the Geronimo home.
propertiesNoneSee Table 3.46, “Properties of the Geronimo.SERVER software”.



Table 3.46, “Properties of the Geronimo.SERVER software” lists the configurable properties of the Geronimo.SERVER software.

Table 3.46. Properties of the Geronimo.SERVER software

NameDefinitionDescriptionDefault value
http-portHTTP.PORTThe HTTP port of the web administration page of Geronimo.8080



ActiveBPEL Personality

The ACTIVEBPEL personality allows the deployment of ActiveBPEL . The archive of this software is available here .

Figure 3.12, “Organization of the ACTIVEBPEL Personality” represents the organization between software and properties inside the ACTIVEBPEL personality and the relations with other elements outside of this personality.

Figure 3.12. Organization of the ACTIVEBPEL Personality

Organization of the ACTIVEBPEL Personality


This personality contains the following definitions:

Table 3.47. Definitions of the ACTIVEBPEL personality

NameDescription
ACTIVEBPEL.ENGINESoftware for the deployment of ActiveBPEL.
ACTIVEBPEL.PROCESS Software for the deployment of a BPEL process onto ActiveBPEL.
ACTIVEBPEL.ARCHIVE(path_to_archive)Parameter representing an ActiveBPEL archive.
ACTIVEBPEL.HOME(home_directory) Parameter representing the ActiveBPEL Home directory.
ACTIVEBPEL.DependOn(XXX) To use in another software (XXX) that depends on ActiveBPEL.


The following example is a standart description to write for deploying the ActiveBPEL engine and a BPEL process on it. ActiveBPEL relies on the Tomcat servlet engine. Note that there are 2 ways to describe an ACTIVEBPEL.ENGINE software : if tomcat is declared inside the 'software' element of a host, the ACTIVEBPEL.ENGINE software requires only its 'host' element (activeBPEL-1 in the example), otherwise, the ACTIVEBPEL.ENGINE software requires only its 'tomcat' element (activeBPEL-2 in the example).

            tomcat-1 = TOMCAT.SERVER {
                archive    = TOMCAT.ARCHIVE(/home/user/archives/apache-tomcat.tgz);
                home       = TOMCAT.HOME(/targetDirectory/apache-tomcat);
                host       = Hosts/host-1;
            }

            activeBPEL-1 = ACTIVEBPEL.ENGINE {
              archive = ACTIVEBPEL.ARCHIVE(/home/user/archives/activeBpel.tgz);
              home    = ACTIVEBPEL.HOME(/targetDirectory/activeBpel);
              tomcat  = tomcat-1;
            }
  
            activeBPEL-2 = ACTIVEBPEL.ENGINE {
              archive = ACTIVEBPEL.ARCHIVE(/home/user/archives/activeBpel.tgz);
              home    = ACTIVEBPEL.HOME(/targetDirectory/activeBpel);
              # We assume that 'host-2' contains a TOMCAT.SERVER inside its
              # 'software' element
              host = /Hosts/host-2;
            }
  
            process-1 = ACTIVEBPEL.PROCESS {
              archive = ACTIVEBPEL.ARCHIVE(/home/user/archives/process.zip);
              activebpel = activeBPEL-1;
            }
          

Table 3.48, “Elements of the ACTIVEBPEL.ENGINE software” and Table 3.49, “Elements of the ACTIVEBPEL.PROCESS software” list the elements of software for the ACTIVEBPEL personality.

Table 3.48. Elements of the ACTIVEBPEL.ENGINE software

NameDefinitionDescription
archiveACTIVEBPEL.ARCHIVEPath to the ActiveBPEL archive.
homeACTIVEBPEL.HOMEPath to the ActiveBPEL home.
tomcatTOMCAT.SERVERThe Tomcat server on which depends ActiveBPEL.



Table 3.49. Elements of the ACTIVEBPEL.PROCESS software

NameDefinitionDescription
archiveACTIVEBPEL.ARCHIVEPath to the ActiveBPEL process archive.
activebpelACTIVEBPEL.ENGINEThe ActiveBPEL engine on which depends the process.



The property of the ACTIVEBPEL.ENGINE software (http-port) is recovered from the Tomcat software. So, for a customization of the HTTP port of ActiveBPEL, see Table 3.17, “Properties of the TOMCAT.SERVER software”

OpenCCM Personality

The OpenCCM personality allows the deployment of OpenCCM. The archive of this software is available here .

Figure 3.13, “Organization of the OpenCCM Personality” represents the organization between software and properties inside the OpenCCM personality and the relations with other elements outside of this personality.

Figure 3.13. Organization of the OpenCCM Personality

Organization of the OpenCCM Personality


This personality contains the following definitions:

Table 3.50. Definitions of the OpenCCM personality

NameDescription
OpenCCM.SERVER Software for the deployment of the OpenCCM platform.
OpenCCM.OWOpenCCMSoftware Software for the deployment of the an OpenCCM platform recovered from a repository (e.g. Objectweb).
OpenCCM.OpenCCM-0-9-0_JacORB-2-1 Software for the deployment of OpenCCM-0.9.0 with JarORB-2.1
OpenCCM.DCI Software for the deployment of the OpenCCM Distributed Computing Infrastructure (DCI) manager
OpenCCM.IORParameter representing a CORBA IOR (Interoperable Object Reference), i.e. the reference to a CORBA object instance
OpenCCM.JCSSoftware for the deployment of the OpenCCM Java Component Server (JCS), that hosts CORBA business components
OpenCCM.NMSoftware for the deployment of the OpenCCM Node Manager, a part of the DCI infrastructure. NodeManager entities host the CORBA business components, register to the DCI manager
OpenCCM.NSSoftware for the deployment of a CORBA Naming Service
OpenCCM.AFMSoftware for the deployment of the OpenCCM Assembly Factory that is responsible of the deployment of CCM assembly archives (*.aar files)
OpenCCM.COMANCHESoftware for the deployment of the OpenCCM micro HTTP server to publish IOR of started CORBA services (NS, DCI, etc.)
OpenCCM.DEPLOYERSoftware for the deployment of the OpenCCM Deployer entity that orchestrate and manage the deployment of CCM applications
OpenCCM.DISPLAYParameter representing the value of the DISPLAY variable
OpenCCM.PROXYSoftware for the deployment of the OpenCCM Proxy entity that is used to pass firewalls
OpenCCM.EXPLORERSoftware for the deployment of the OpenCCM Explorer console that manages at runtime CCM applications
OpenCCM.ARCHIVEParameter representing an OpenCCM archive
OpenCCM.HOMEParameter representing the home directory of OpenCCM
OpenCCM.DependOnTo use in another software (XXX) that depends on OpenCCM, such as the DCI or NS


Table 3.51, “Elements of the OpenCCM.SERVER software” list the elements of software for the OpenCCM personality.

Table 3.51. Elements of the OpenCCM.SERVER software

NameDefinition
archiveOpenCCM.ARCHIVE
homeOpenCCM.HOME
orbCORBA.ORB
javaJAVA.JRE


The following example is a description using all configurable elements of the OpenCCM personality:

            ORB-host1 = CORBA.ORB {
                archive = CORBA.ARCHIVE(Archive_File_URI);
                home = CORBA.HOME(Corba_Home_URI);
                host = Hosts/host1;
            }
            ORB-host2 = CORBA.ORB {
                archive = CORBA.ARCHIVE(Archive_File_URI);
                home = CORBA.HOME(Corba_Home_URI);
                host = Hosts/host2;
            }
            OpenCCM-host1 = OpenCCM.SERVER {
                archive = OpenCCM.ARCHIVE(Archive_File_URI);
                home = OpenCCM.HOME(OpenCCM_Home_URI);
                orb = Software/ORB-host1;
                java = Software/JRE-host1;
                host = Hosts/host1;
            }
            OpenCCM-host2 = OpenCCM.SERVER { 
                archive = OpenCCM.ARCHIVE(Archive_File_URI);
                home = OpenCCM.HOME(OpenCCM_Home_URI);
                orb = Software/ORB-host2;
                java = Software/JRE-host2;
                host = Hosts/host2;
            }
            Comanche-host1 = OpenCCM.COMANCHE {
                openccm = Software/OpenCCM-host1;
                host = Hosts/host1;
            }
          }

          OpenCCM_Deployment = FDF.SEQUENTIAL-COLLECTION(OpenCCM Deployment) {
  
            NameService = OpenCCM.NS { 
                comanche = Software/Comanche-host1;
                host = Hosts/host1;
                ior_ns = OpenCCM.IOR(http://host1:8080/NameService.IOR);
            }
            OpenCCM_DCI = OpenCCM.DCI(DefaultDCI) { 
                ns = OpenCCM_Deployment/NameService;
                comanche = Software/Comanche-host1;   
                host = Hosts/host1;
                ior_dci = OpenCCM.IOR(http://host1:8080/DCI.IOR);
            }
            Assembly_Factory = OpenCCM.AFM(DefaultFactory) {
                dci = OpenCCM_Deployment/OpenCCM_DCI;
                openccm = Software/OpenCCM-host1;   
                host = Hosts/host1;     
            }
            OpenCCM_Servers = FDF.PARALLEL-COLLECTION(OpenCCM Servers){
                cs-host1 = OpenCCM.JCS(ComponentServer1){ 
                    ns = OpenCCM_Deployment/NameService;
                    openccm = Software/OpenCCM-host1;
                    host = Hosts/host1;
                }                                   
                cs-host2 = OpenCCM.JCS(ComponentServer2){ 
                    ns = OpenCCM_Deployment/NameService;
                    openccm = Software/OpenCCM-host2;
                    host = Hosts/host2;
                }
            }
          }

          # Description of an assembly of CORBA components to deploy on OpenCCM servers

            Chat-demo = OpenCCM.DEPLOYER(chat,/tmp/chat.aar){ 
                openccm = Software/OpenCCM-host2;
                host = Hosts/host2;
                dci = OpenCCM_Deployment/OpenCCM_DCI;
            }
    
          # Description of OpenCCM Explorer console to manage the application

            OpenCCM-Explorer = OpenCCM.EXPLORER { 
                openccm = Software/OpenCCM-host2;
                host = Hosts/host2;
                dci = OpenCCM_Deployment/OpenCCM_DCI;
            } 
        

FDF Personality

The FDF Personality allows the deployment of the FDF software itself. In other words, FDF can deploy itself

Figure 3.14, “Organization of the FDF Personality” represents the organization between software and properties inside the FDF personality and the relations with other elements outside of this personality.

Figure 3.14. Organization of the FDF Personality

Organization of the FDF Personality


How to write a personality ?

Writing a FDF personality just requires to have a README of the software describing each step of the deployment. When you start to write a personality, you must think about what you will need. For example, most software need an archive and a home parameter, but some other ones depend on certain libraries or software. It means that the personality will depend on another FDF personality. We will first present a basic personality that doesn't used any software features, and step by step, we will show how to write a more and more complex personality.

Next example shows the file SOFTWARE.fdf (stored in the FOO personality) that describes the deployment of an imaginary software called 'foo'. In this example, we only show the skeleton of the personality: there's no business or parameter elements.

          FOO.SOFTWARE = org.objectweb.fdf.components.software.Software(foo,FooHeader) {

            properties {
              # list of properties for the software 'foo'
            }

            dependencies {
              # list of software needed to deploy foo
              start-when-install {
                # list of software that have to be started for installing foo
              }
            }

            foo {
              internal-deployment {
                install {
                  # Sequence of instructions to execute when installing the foo software
                }
                configure {
                  # Sequence of instructions to execute when configuring the foo software
                }
                start {
                  # Sequence of instructions to execute when starting the foo software
                }
                stop {
                  # Sequence of instructions to execute when stopping the foo software
                }
                unconfigure {
                  # Sequence of instructions to execute when unconfiguring the foo software
                }
                uninstall [
                  # Sequence of instructions to execute when uninstalling the foo software
                }
              }
            }
          }
    

Each procedure of the deployment process (install, configure, start, ...) is described as a sequence of instructions. The list of instructions usable in such sequences is given in Table 3.52, “FDF Procedure Instructions”

The previous example was a basic personality, where all actions of deployment steps are described. But FDF provides personality features, shown in Table 3.53, “Software Features”, that factorizes common sequences of actions needed for a given step.

Table 3.52. FDF Procedure Instructions

NameArgumentsDescription
SHELL.Execute
- command: the command to send to the remote shellExecute a command via the shell of the host associated to the software
SHELL.Fork
- command: the command to send to the remote shellExecute a command via the shell of the host associated to the software, and run it in background
SHELL.LaunchProcess

- processName: the name of the process to launch

- command: the command to launch on the remote shell

Execute a command via the shell of the host associated to the software, and store its pid, for killing it in the future
SHELL.KillProcess

- processName: the name of the process to kill

- signal: the signal for the kill command (default=2)

Kill the process according to its name
SHELL.CopyFile

- source: the path to the file to copy

- destination: the path of the destination

Copy a file from 'source' to 'destination'
SHELL.MakeDirectory
- name: the name of the directory to createCreate a directory on the software's host
SHELL.RemoveDirectory
- name: the name of the directory to removeRemove a directory from the software's host
SHELL.RemoveFile
- name: the name of the file to removeRemove a file from the software's host
SHELL.SetVariable

- name: the name of the variable to set

- value: the value of the variable

Set an environment variable on the shell of the software
SHELL.UnsetVariable
- name: the name of the variable to unsetUnset a variable from the shell of the software
SHELL.AddVariable

- name: the name of the variable to edit

- value: the value to add to the variable

Add a value to an existing variable on the shell of the software
SHELL.AddPath
- value: the value to add to the PATH variableAdd a value in the PATH environment variable on the shell of the software
TRANSFER.Upload

- from: the local path to the file to upload

- to: the destination where to upload the file

Upload a file from the host where FDF runs to the host where the software is deployed
TRANSFER.UploadGeneratedFile

- filename: the name of the file to generate

- from: the local path to the generated file to upload

- to: the destination where to upload the generated file

Generate a file, according to a template file (see ??) and upload it to the host where the


In this example, we show how to use the runnable components inside deployment procedures:

        start {
          cd-home       = SHELL.ChangeDirectory(#[home]);
          start-process = SHELL.LaunchProcess(name_of_the_process,command_to_launch);
        }
        stop {
          kill-process = SHELL.KillProcess(name_of_the_process);
        }
    

Note that in some procedures, you may use FDF variables, using syntax #[variable_name] (as done just above with the #[home] variable). The values of those variables are replaced at runtime by FDF.

Table 3.53. Software Features

NameArgumentsDescription
software.Installable

- name: the name of the component representing the software

- header: the header to display in FDF logs

- archive: the archive of the software

- home: the home of the software

Describe the 'install' and 'uninstall' procedures. The 'install' procedure contains the following steps: remove the 'home' directory (for deploying the archive in a cleaned up space), upload the archive and unarchive it into the home directory. The 'uninstall' procedure cancels the side effects of the 'install' one.
software.Manageable

- name: the name of the component representing the software

- adminURL: the URL of the administration page of the software

Allow to open the web administration page of the software, when started.
software.Hosting
- name: the name of the component representing the software For software that hosts other software. This feature enables the sharing of the host component for the hosted software.
software.Hosted

- name: the name of the component representing the software

- header: the header to display in FDF logs

- hosting-software: the name of the software that hosts this software

For software hosted by other ones. With this feature, the host of the software will be recovered from 'hosting-software'.
software.AlreadyInstalled

- name: the name of the component that is already started

- header: the header to display in FDF logs

For software that are already started (and then installed), needed for other software deployment.
software.Unstoppable
- name: the name of the component representing the software For software that doesn't run endlessly and stop by themselves when their job is done.
software.Iconable

- name: the name of the component representing the software

- icon: the icon of the software

Customize the representation of the software in FDF Explorer with the graphical icon.


In the following example, the software foo is declared as an installable, iconable and manageable software:

        FOO.SOFTWARE =
          software.Installable(foo,FooHeader,archive,home),
          software.Manageable(foo,http://...), # Fix the URL administration page of foo
          software.Iconable(FOO/Icon.png) {    # This suppose that the directory 'FOO' contains the icon named 'Icon.png'

            archive = software.ARCHIVE(UNDEFINED);
            home    = software.HOME(UNDEFINED);

            foo {
              internal-deployment {
                start { ... }
                stop { ... }
              }
            }

        }
    

Note that in the example above, the 'archive' component definition (resp. 'home') is 'software.Archive' (resp. 'software.Home'). But you can customize your parameter definitions. Here is the example for a dedicated FOO.Archive (resp. FOO.Home) parameter (the file 'Archive.fdf' (resp. Home.fdf) will be stored in the 'FOO' folder):

      FOO.ARCHIVE(value) = software.Archive(Foo,${value})
      {
      }
    
      FOO.HOME(value) = software.Home(Foo,${value})
      {
      }
    

Now, let's imagine that our software depends on another software, named 'bar'. The component called 'dependencies' is made for automatically apply to 'bar' the procedure (install, start, ...) called on 'foo'.

      FOO.SOFTWARE = software.DependOn(foo,bar) {
      
        # Foo depends on Bar:
        bar { }

        foo {
          internal-deployment {
            ...
          }
        }
      }
    

With this construction, the system administrator will only have to give the reference to 'bar':

      my-bar = BAR.SOFTWARE {
        ...
      }

      my-foo = FOO.SOFTWARE {
        archive = ...
        home = ...
        host = ...
        bar = /my-bar;
      }
    

But sometimes, this kind of dependency is not sufficient for handling the deployment of a business software. The typical example is an EJB component: its installation doesn't only require the installation of the server on which it relies. The server must be started when the EJB installation begins.

That's the purpose of the component 'start-when-install' defined in the 'dependencies' component, which deals with such kind of synchronisation:

      FOO.SOFTWARE = ... {

        bar { }

        dependencies {
          start-when-install {
            /bar;
          }
        }
        ...
      }
    

Now, you will see how to use 'FDF parameters' inside software personalities. These parameters are declared with the following syntax:

      FOO.SOFTWARE = ... {

        param1 = software.Parameter(default_value); # Note that you can use your own FOO.Parameter

        foo {
          internal-deployment {
            # A possible usage of this parameter can be inside an instruction, as SHELL.Execute:
            start {
              my-command = SHELL.Execute(... #[param1] ...);
            }
          }

          internal-parameters {
            # The final value of param1 is replaced thanks to a primitive FDF component: the formatter.
            # This component formats all parameters placed in 'internal-parameters' of a software.
            /param1;
          }
        }
      }
    

In this example, the default value of 'param1' is set in the 'foo' personality. Therefore, if the system administrator doesn't declare 'param1' inside its 'foo' description, the command will be launched with the default value.

Chapter 4. Use FDF

In this chapter, we will present how to run FDF and perform a deployment. We will illustrate this with the JOnAS example. This example is available in 'examples/jonas', but of course, if you want to test it, you have to edit this file in order to set the correct values for archive, home and so on.

Launch a FDF Description

When you have retrieved FDF (see the section called “Installation”), go in the ${FDF_HOME}/bin directory, and type the command (for Unix):

        > ./fdf.sh explorer
        

And for Windows:

        > fdf explorer
        

FDF Explorer will appear. At this time, no FDF description is loaded.

Then load your FDF description file (Explorer/Load in the menu). The left panel in of the Explorer will display all entities described in the FDF file. Then, when selecting a software in this panel, its dependencies are shown on the right panel.

Next image shows a description of the JOnAS J2EE server loaded with FDF.

Figure 4.1. JEE deployment with FDF Explorer

JEE deployment with FDF Explorer


FDF Explorer Usage

Once FDF description is loaded, you can perform the deployment by clicking on components representing your software. A right clic in the left panel (as shown on the figure), or in the graph on the right panel, will display all procedures you can invoke, according to the software current status.

Figure 4.2. Example of an EJB Deployment

Example of an EJB Deployment