Grid Service Deployment Introduction

Deploying a service may seem complicated at times. But it doesn't have to be! Once a service is created, the next step is to make it running and accessible on a target Grid with a successful deployment. A caGrid service is only a piece of software on your machine and cannot be accessed until deployed to a Grid. This guide first provides a detailed overview of the deployment process and important background information. It then walks you through the process in a "hands-on" approach. Finally, it discusses the process to verify a successful deployment and reviews common troubleshooting and deployment best practices.

Audience

This guide is intended for systems administrators and others who are responsible for ensuring a service is accessible on the Grid. Put another way, this guide is intended for anyone acting in a "deployment" role. The deployment role focuses on the process of deploying a Grid service to join a target Grid. This guide is also intended for service developers and others that need to understand the Grid service deployment process. Since readers of this article may have varying levels of knowledge about the Grid and may not be familiar with the terminology used throughout this article, this article provides a glossary. The glossary covers basic concepts about the Grid in order to ensure that everyone has a common understanding before continuing with the rest of the guide. Please note that review of the glossary is strongly recommended, as the usage of specific terms in this guide may be different from how these terms are used in other caGrid documents.

Purpose

The purpose of this guide is to ensure that you have a complete understanding of the concepts and steps involved in deploying a Grid service to "join a target Grid". When reading this guide, it is critical to keep in mind that you have a choice of Grids to integrate with (that is, this article explains the Grid deployment process using a Grid-agnostic approach). "Joining a target Grid" involves deploying the Grid service to integrate with a "target Grid". A "target Grid" is simply a Grid of your choice.

Glossary

Important key terms that users should be familiar with:

caGrid - caGrid is open source grid software infrastructure aimed at enabling multi-institutional data sharing and analysis in clinical, translational research, and research environments.
Grid - A Grid is an interconnected set of computing resources for the purpose of data sharing and analysis by a virtual organization. For caGrid and caBIG specifically, a Grid links computer and data resources of multiple organizations to securely share and analyze vast quantities of data. Computers, servers, or databases are shared as Grid services and join a target Grid by conforming to the Grid's data sharing and security policies. Most grids sit on a layer above the Internet and have core directory services and security services to incorporate services into the Grid. For purposes of this article, a Grid is a set of caGrid services that are deployed together by members of a virtual organization. In particular, there is not "one Grid" but many Grids.
Grid entity - a Grid user (person) or a Grid service (software) that has joined a target Grid.
Joining a target Grid - Every service is integrated into one target Grid. That means it interacts with other services that have also joined that same Grid. There is a conceptual difference between a service joining a target Grid and caGrid (the software) being configured to use a target Grid (see next entry). Please note that when you configure caGrid to use a target Grid, Introduce (see glossary for definition) is configured a) to utilize core services in that Grid and b) to create services that will join that target Grid. However, after the service is created, the target Grid that the service will join is completely customizable. A service deployer/administrator uses Introduce to deploy the service. At that time, the service deployer can configure the target Grid that the service should join. We will discuss this in further detail later in this article.
Configure caGrid to use a target Grid - Re-configure the software included in the caGrid distribution to utilize services from a chosen target Grid. An example is the GAARDS UI. Re-configuring caGrid to use the OSU-hosted Community Training Grid will (among other things) configure the GAARDS UI to use the security service deployed to the Community Training Grid. That, in turns, allows a user of the GAARDS UI to, for example, login to the Community Training Grid. Configuring caGrid to use a target Grid also configures the Introduce toolkit. There are other functions performed when configuring the target Grid, but as of caGrid 1.3, these are the most noticeable.
Configure a container - A service developer or service deployer uses the caGrid installer to configure a container that will host a Grid service. Containers are either secure or non-secure. A non-secure container can only host non-secure Grid services. A secure container can host secure Grid services (and non-secure Grid services). Every secure container is secure by definition because it has a (one) Grid identity that it uses to communicate with other Grid entities. Configuring a secure container with this identity involves specifying the host certificate and key that the container will use when communicating with the Grid.
Secure Grid service - a service that has authentication and authorization policies set using Introduce. For example, a service may require that Grid entities contacting the service provides its Grid identity to the service or it may require authorization checks when a Grid entity invokes service operations
Non-secure Grid service - a service that is openly accessible to all Grid entities. A non-secure Grid service cannot receive Grid credentials from entities invoking service operations, so the service cannot verify who is accessing the service and also cannot perform authorization. Moreover, a non-secure Grid service has no identity and so can only contact Grid services that allow anonymous access (access without a Grid identity).
Grid container - a web application container (e.g., Apache Tomcat) that hosts one or more Grid services. The caGrid installer supports configuration of JBoss and Apache Tomcat.
Deploy a service - A Grid service by itself is software that lives on a computer. In order to run the software program to share or analyze data, the service must be deployed to a Grid container. Then, the Grid service administrator starts the container to make the service accessible to other Grid entities.
Index Service - Every Grid has its own service directory, called the Index Service, that supports service advertisement and discovery for services in one Grid. This service directory is the "white" and "yellow" pages for a Grid. A service advertises itself to the Index Service. The Index service then contacts the service to aggregate metadata. Clients can use the Index Service to discover available services based on service metadata. The service deployer configures a target Index service during deployment.

Introduction to service deployment

There are two steps involved in adding a Grid service to the Grid. The first (and lengthiest) step, performed by a service developer, is to develop the software that will provide functionality needed by the Grid service.. After the developer has verified the service is working as expected, a service deployer (anyone acting in a deployment role) integrates the Grid service with a target Grid. It's important to think of the Grid service itself as a piece of software with some desired capability that can be accessed from the Grid. In order to be able to contact and utilize the service, however, the Grid service must first be runningand accessible.

The first step, running the Grid service, involves starting up the Grid service so that other Grid entities can communicate with your Grid service. For example, running the Grid service allows users to invoke operations on your service. You run the Grid service by deploying it to a Grid container and starting the container, which listens on a port of your choice.

The first step to making the service accessible to others on a target Grid involves configuring the service's properties before deployment in order to choose the Index service for your chosen target Grid. Configuring the Index service will enable your service to advertise to that Index service. The second step is to configure the container to which you will deploy your service. At a high level, both secure and non-secure containers are configured for a target Grid and also configured with an appropriate domain name. Moreover, configuring a secure container involves ensuring your container has an identity that it uses to communicate with other Grid entities.

In summary, to ensure your service is both running and accessible, configure your Grid service properties and then configure your container properties as needed to join a target Grid of your choice. Then you deploy your service to the container and start the container.

Details on the Grid Deployment Process

First, the service deployer choose a container for service deployment. The service deployment features of Introduce currently support deploying Grid services to a Globus, JBoss or Tomcat container. We note that since caGrid 1.2, the recommended containers include Tomcat and JBoss (not Globus), as these two containers are intended for production use. Introduce displays the directory in which the container lives (which it gleans from the appropriate environment variable that specifies this location).

Next, the service developer configures service properties. The Introduce deployment framework supports the use of service properties so that the service can be customized for use as needed during deployment time. As an example, a service might have a service property to configure a database connection. When the service is deployed (using Introduce), the graphical interface prompts the deployer for the desired values (note: the defaults for the values are specified by the service developer). Introduce configures the service's deploy.properties file with the specified properties. This allows a very convenient way for those deploying the service to configure it appropriately for their environment, without requiring knowledge of how the grid service uses these configuration properties. We will discuss this in more detail later in this article.

Next, the service deployer configures the advertisement properties so that the service advertises properly to the Index service of the chosen target Grid.

Finally, the service deployer deploys the service. Introduce utilizes the layout of the Grid Archive (GAR) structure to organize and package a deployable service. Once the GAR for a service is generated by the deployment framework, the GAR can deployed to the appropriate container. Please note that in all cases an Introduce-generated Grid service is deployed as a service to the Globus web application. The Globus web application, in turn, is deployed to a supported web container. For both the two containers supported by caGrid, Tomcat and JBoss, the Globus web application is actually deployed directly to Tomcat. For JBoss support, Tomcat is in turn deployed to JBoss. This is graphically illustrated in the following diagram.

Note: The installer can be used to install and configure either JBoss or Tomcat