Fork me on GitHub

The Service control adapter required to activate and monitor an existing service is nothing more then a POJO that encapsulates the logic needed to create the necessary infrastructure components required to activate and monitor the existing service element.

The easiest way to bootstrap this is to use the serviceExec element in the Rio OperationalString. The serviceExec element indicates that a service is to be created using the exec framework, that is created as and managed as an external process. The targeted service to be exec'd will be allocated to available compute resources based in the capability to match the operational & platform requirements to available compute resource (Cybernode) capabilities.

We will use the Tomcat example as a reference, and discuss the example's OperationalString to demonstrate the serviceExec element for the dynamic deployment of a Tomcat instance.

The OperationalString can be composed in both XML and using a Groovy based DSL. This example and discussion uses Groovy.

deployment(name: 'Tomcat Deploy') {
    groups System.getProperty(Constants.GROUPS_PROPERTY_NAME,
                              System.getProperty('user.name'))
    serviceExec(name: 'Tomcat') {
        software(name: 'Tomcat', version: '6.0.16')
        execute(inDirectory: 'bin', command: 'catalina.sh run') {
            environment {
                property name: "CATALINA_OPTS", value: "-Dcom.sun.management.jmxremote"
            }
        }
        maintain 1
    }
}

The important parts of the declaration are outlined below:

Element Description
groups The discovery group(s) the deployed service will use for joining the network. This declaration will first check if the -Dorg.rioproject.groups has been set, if not the user name is used
serviceExec The is the element that describes the external service to be created and managed. In our case it is Tomcat.
software This element describes a requirement that Tomcat be available as an installed component. If Tomcat is not found the service (Tomcat) will not be created. As we move through this example we will be able to dynamically install and configure Tomcat. For this declaration, Tomcat must be installed.
execute This element describes the command to exec, and any input arguments. As you can see it completely straight forward. The command (catalina.sh) location is constructed based on the derived location of the installed (and/or available) Tomcat component. Additionally, the CATALINA_OPTS environment variable is declared, allowing Tomcat to be started enabling remote JMX monitoring.
maintain This indicates how many instances of Tomcat to maintain.

Back to top

Version: 5.6. Last Published: 2017-01-01.