Deployment Background Information

Knowing the Files

To completely understand service deployment, it is important to know what files are generated by Introduce and why they are needed for the service to join a target Grid. A basic Grid service created by Introduce has the following components:

Ant targets for build, deploy, and test operations
custom configuration files for IDE integration, e.g., Eclipse project files for editing of the service using the Eclipse platform (www.eclipse.org)
standard interface for both client and service communication
fully implemented client APIs
stubs for the service implementation methods
configuration files for service metadata and resource properties and the registration of metadata and properties
configuration files and associated code specifying service authentication and authorization requirements
A file specifying the service properties
The diagram below shows the use of the different common files of an example Introduce-generated service. It shows the files used for configuring registration and security for the grid service, as well as those used by Introduce for synchronization, and those used for build and deployment.

All of these files are automatically modified by Introduce as needed. The files listed below are the files that typically are modified by a service deployer during deploy-time (note: we clarify here that a service deployer uses Introduce to set the values in these files and Introduce in turn edits the files). Introduce provides a "Deployment" panel to eliminate the need to manually edit these files directly. If ther is a valid reason to edit the files directly, please refer to the Advanced section of this article to learn how to do this properly.

Please note that modifying any of the files below after the service has been deployed will necessitate a subsequent service deployment (a running service won't read the updated files until they are deployed to the container, which happens during service deployment).
What follows is a description of 2 of the files that the user can edit using the Introduce "Deployment" window. We will present step-by-step instructions for modifying these files later in this article.

deploy.properties

Grid service advertisement information is specified in the deploy.properties file. Introduce updates this file during deployment with the advertisement information that the service deployer entered into Introduce. The table below lists each of properties that can be configured in the file GENERATED_SERVICE_HOME/deploy.properties.

Property Name	Value(s)	Description
perform.index.service.registration	true or false	Whether or not the service should register with the Index Service
index.service.url	URL	The URL of the Index Service to register with.
index.service.index.refresh_milliseconds	Integer	How often to reregister with the index service (this should be a relatively large amount of time and is simply useful for making sure the index service does not lose your registration).
index.service.registration.refresh_seconds	Integer	When registering to the index service this number tell the index service how often, in milliseconds, to contact me for updated met

service.properties

Service properties are specified in the service.properties file. These properties are added by the service developer specifically so that the Grid service can be customized for specific environments. Please note that it is very error prone to manually edit this file. See the "Advanced" section later in this document for additional details. Some examples of service.properties that could be added by the service developer are:

Property Name	Value(s)	Description
gridGrouperURL	URL	Grid Grouper service URL
serviceStemSystemName	File Path; ex: Training:photosharingtutorial:<HOSTNAME>	System name of the service stem in Grid Grouper

Introduce service model file

Introduce keeps a model of the service in the introduce.xml file. That is, all user interactions with the Introduce UI directly change the introduce.xml file. Needless to say, manually editing the file is not recommended

Container Configuration

In addition to understanding key files in deployment, it is also important to understand container configuration since the service will be deployed to a container. The deployment panel in Introduce will show basic information about the service you are going to deploy and provides the ability to choose the container to deploy to. In order to deploy an Introduce generated service to the container, it is required that ant is installed and that the container is installed as a pre-requisite for deployment. When a service deployer uses the installer to configure a container, the Installer directs the service deployer (on the last panel in the Installer wizard) to set an appropriate environment variable to point to the container. Introduce will detect the available containers on the host machine by checking for the existing of the following environment variables: GLOBUS_LOCATION (Globus), CATALINA_HOME (Tomcat), JBOSS_HOME (JBoss)).

A container must be installed and configured before the service deployer can deploy a service to it. A service deployer installs and configures a container using the caGrid installer. While using the installer, the first choice to make is which container to install (JBoss, Tomcat) and whether the container will be secure. You will also have to provide a hostname and select a shutdown port for the container. The following information aims to explain each of these options.

Container Selection

Tomcat is the primary recommended container, both for its simplicity and ease of use. Choose that if you have no other reasons to choose differently.

JBoss is an appropriate container if you would like to deploy applications other than Grid services. That is, JBoss is an enterprise application server that hosts multiple applications (such as Tomcat). If you have other kinds of applications in addition to Grid applications (e.g., J2EE applications) that you need to run, it may be a better choice to install JBoss so that you can deploy these other applications to minimize the systems administration burden.

Secure vs. non-Secure

A container can be either secure or non-secure. A non-secure container can only host non-secure Grid services. A secure container can host secure Grid services. Therefore, the service deployer must know from the service creator whether the service is secure or not (this should be in the documentation).

Every secure container is secure by definition because it has a Grid identity that it uses to securely communicate with other Grid entities. You specify the grid identity implicitly by selecting the host certificate and host key file during configuration. If you do not yet have a host certificate and key, you can use GAARDS to request a host certificate during installation. If you elect this option, the installer will allow you to open GAARDS to obtain these host credentials. For complete steps on obtain host credentials using GAARDS, see: 7.4 Obtain Host Credentials. Otherwise, you specify the location of the host certificate and key for the container to use. To see a complete explanation on how Grid security works, please see GAARDS

Providing a hostname

During the installation of a container, you must configure your container with a domain name that other Grid entities will use to contact your service. The domain name must be fully qualified and publically resolvable. It is important you use a publicly resolvable DNS name (or static IP), otherwise you will later need to edit configuration files manually to change this value.

Shutdown Port

The shutdown port is used during the shutdown of the container. It is important that this port is not already in use on the machine. Specifically, shutting down the container using the container's shutdown scripts will contact the service using the shutdown port. Please note that it is not required (and indeed it would be bad practice) to open this port through the firewall. Make sure the shutdown port is only accessible internally.

What happens when a container is installed?

After you configure the container settings using the caGrid installer, the Installer installs the container on your machine. There are two primary steps to this process, outlined as follows:

The installer unzips your container of choice.
The installer deployed Globus to the container.
The installer configures your container using the information you specific in the installer. For example, if you specified a "secure" container, then the installer will configure the container to enable security and properly configure the container's identity using the specified host certificate and key file.
If you selected a target Grid when you installed caGrid, the installer automatically configures the container for that Grid. The installer will deploy Globus to that container and then deploy SyncGTS, configuring SyncGTS to synchronize with your target Grid. Please note that, as a result, when you use Introduce to deploy your service to the container, you must configure your service to advertise to the Index service in the same target Grid. Thus, your service must be deployed to the same target grid for which the container is configured! For more information on syncGTS see, SyncGTS

Important note about target grids: If caGrid is configured with a target grid during installation of caGrid, part of that configuration includes configuring Introduce. Therefore, the default target grid for all new services created in Introduce is whichever Grid was chosen when caGrid was installed. This means that any new service is configured to advertise to that target Grid's Index Service. However, after a service is created, configuring caGrid with a target Grid has no effect on the existing service. Thus, to deploy a service to another target Grid means that you must use the "Deploy service" Introduce window to modify the Index service URL and other properties discussed earlier so that the service can advertise to the correct target Grid. If you are a service deployer and you did not create the service, it is therefore likely that you will need to edit the service advertisement settings in Introduce during deployment.

Knowledgebase