----
h1. Advanced Deployment
----
h2. Deploying Multiple caGrid Services
There are two primary issues to keep in mind when deploying multiple caGrid services:
* Classpath conflicts
* SyncGTS conflicts
h3. Classpath Issue
The first issue, classpath conflicts, arises because all caGrid services are deployed to the Globus web application inside your container. Recall that each web application in the container has its own classpath. The result is that all caGrid services share one classpath. When two different caGrid services have conflicting jar files, the result is a classpath conflict. This can result in errors that are extremely difficult to track down.
h3. Classpath Recommendation
Thus, our *recommendation* is to only deploy one caGrid service per container. We emphasize that this is not a *requirement* but a *recommendation*. We also note that the "one service per container" recommendation explicitly excludes the SyncGTS service, which is installed to all containers. The recommendation applies to the caGrid service that is deployed to a configured container (resulting in SyncGTS and another Grid service co-existing in one container).
h3. SyncGTS Issue
The second issue, SyncGTS conflicts, arises because SyncGTS modifies the files in the trusted certificates directory. By default, this is the USER_HOME_DIRECTORY/.globus/certificates directory. If you have multiple SyncGTS services that are configured for multiple different target Grids, you can run into a situation where the SyncGTS instances are conflicting and overriding each others certificates. The following situations clearly demonstrate when a problem will arise:
h3. SyncGTS Issue Examples
# User "joe" installed two caGrid containers and deployed one service to each container. Both containers are configured for the "Community Training Grid", resulting in a SyncGTS service (one per container) that periodically synchronizes with the Training Grid. This setup has no problems, as each time SyncGTS runs, it sees that the certificates in JOE_HOME_DIR/.globus/certificates directory match those from the Community Training Grid GTS service and leaves them in the directory.
# User "joe" installed two caGrid containers, one that is configured for the caBIG Stage Grid and one that is configured for the caBIG Production Grid. Because these Grids are two separate deployments (meaning they have completely separate trust fabrics), this configuration will exhibit problems. One container, with a SyncGTS service configured for the caBIG Production Grid, will periodically contact the Production Grid GTS and place the certificates in the JOE_HOME_DIR/.globus/certificates directory. The other container, with a SyncGTS services configured for the caBIG Staging Grid, will periodically contact the Staging Grid GTS and place the certificates in the JOE_HOME_DIR/.globus/certificates directory. This will result in unpredictable behavior. It may be that at any give point in time, the JOE_HOME_DIR/.globus/certificates directory has certificates from the Production Grid, from the Staging Grid, or some mix of certificates. Thus, when the services use the certificates directory to perform a trust check for a client that is contacting the service, the check may fail (meaning clients will not be able to contact secure services that are deployed to these containers).
h3. SyncGTS Recommendation
Thus, our *recommendation* is to ensure that each user account runs caGrid services that have all joined only one target Grid. In the event that you need to run services that join multiple target Grids, you need to create multiple user accounts, one per target Grid.
h2. Manually Editing Configuration Files
Although not recommended, it is sometimes necessary to manually edit some deployment files generated by Introduce. We strongly suggest that you use the Introduce graphical interface to edit any of those files. This is to avoid any simple syntax errors that will prohibit the service from deploying properly. However, if you cannot use Introduce to deploy the service, then you will need to manually edit the files. please remember to follow proper syntax rules for Java properties files (both the deploy,properties file and service.properties files are Java properties files). Additional technical information can be found at the following link:
http://publib.boulder.ibm.com/infocenter/cicsts/v3r1/index.jsp?topic=/com.ibm.cics.ts31.doc/dfha2/dfha2ah.htm
h2. Proxy
Administration
...