Table of Contents
This page contains helpful information for migrating from GT3 to GT4.
For a good generic migration guide for GT3 services, see GT3.2 to GT4 Migration: A First HOWTO by Terry Harmer and Julie McCabe.
For some information about migrating from GT3 pre-Web Services to GT4 pre-Web Services, see Migrating from Globus Toolkit 2.4.3/3.2 to 4.0.1 on the Virtual Data Toolkit (VDT) website.
GT3 used GWSDL to describe service messages and operations. GT4 uses standard WSDL with one extensibility attribute to describe resource properties. Please see the WS-ResourceProperties specification for details on expressing the resource properties in WSDL.
In GT3 every service inherited some basic operations and functionality (from GridService port type) as required by the OGSI specification. However, in GT4 there is no such requirement (because the WSRF/WSN specifications do not require it). Also, the Factory port type defined in the OGSI specification does not exist in WSRF/WSN specifications. Therefore, there is no standard create operation or functionality provided by GT4.
GT3 relied on wrapped formatting of the WSDL. GT4 uses standard document formatting. This change introduces differences in how the Java interface for the service looks. Please see the design document and the document/literal section for more details.
In GT3, the business logic of the service and the state were coupled together in one class. In GT4, the business logic and the state are decoupled and placed in two separate classes. The business logic is put in a service class while the state is put in a resource class. The service is stateless while the resource is stateful. Also, GT4 introduces ResourceHome classes that are responsible for managing and discovering resources. Please see the programming model overview for details.
Even though a GT4 developer needs to modify two or three separate files the coding effort is about the same as in GT3.
In GT3, most of the configuration information was stored in the server-config.wsdd file. In GT4, since the business logic and state were decoupled, the service information is still kept in server-config.wsdd but resource information is now placed in the new jndi-config.xml file. Please see the JNDI section for more details.
Globus XIO has made very few changes in the API since its introduction. User of GT4.0 who are previously familiar with globus_xio will notice no difference.
No changes need to be made in applications using version 3.x releases of the C common libraries.
If you are running GT 3.0.0 or greater, the migration for GridFTP is relatively painless. There were only new features added. No changes were made to the existing protocol or APIs, so any existing client or application built using our client APIs will work unchanged. You may install new clients and servers on an as-opportunity-permits basis and will have no problems. Any combination of old/new client/server will work.
To upgrade your server, either install it in a $GLOBUS_LOCATION different than the GT 3 installation (either as
part of an entire GT 4 installation or by doing just make gridftp). Alternately, you can statically link the new
server to avoid versioning issues and replace the existing executable. The configuration files are very
different, so you will need to update the configuration.
To upgrade your client, simply build the client and use the new client as you would the old one.
Below is a list of new functionality available in GT 3.2 and higher (note that the MLST/MLSD feature is used by RFT in GT 3.2 and higher and is required if you want to be able to specify a directory to move):
New Functionality in 3.2:
Server Improvements
- Structured File Info
- MLST, MLSD
- checksum support
- chmod support
globus-url-copy changes
- File globbing support
- Recursive dir moves
- RFC 1738 support
- Control of restart
- Control of DC security
The RFT implementations in GT4 and GT3 are not interoperable, as they are built on different GT core implementations. In order to migrate to GT4 RFT you should follow the installation instructions for GT4, which can be found here.
Users of the GT3 RLS may reuse their existing databases with the GT4 RLS. No migration is required.
Migrating to GT 4.0 from GT version 3.2:
- The 4.0 protocol has been changed to be WSRF compliant. There is no backward compatibility between 4.0 and 3.2.
API changes since GT 3.2:
- The MJFS
createoperation has becomecreateManagedJoband, now provides the option to send a uuid. A client can use this uuid to recover a job EPR in the event that the reply message is not received. Given this new scheme, thestartoperation was removed. The createManagedJob() operation also allows a notification subscription request to be specified. This is the only way to reliably get all job state notifications. - The MJS
startoperation has been removed. Its purpose was to ensure that the client had received the job EPR prior to the job being executed (and thus consuming resources), and is redundant with the uuid functionality.
New GRAM Client Submission Tool:
- globusrun-ws has replaced managed-job-globusrun as the WS GRAM client submission program. The main reason was performance. The cost of JVM startup for each job submission through managed-job-globusrun was too much. globusrun-ws is written in C and thus avoids the JVM startup cost. globusrun-ws is very similar in functionality to managed-job-globusrun, but you will need to become familiar with the arguments and options.
RSL Schema Changes Since GT 3.2:
- RSL Substitutions RSL substitution syntax has changed to allow for a simpler RSL schema that can be parsed by standard tools. In GT 3.2, applications could define arbitrary RSL substitutions within an RSL document and rely on the GRAM service to resolve them. In GT4 WS GRAM, this feature is no longer present. In GT 4.0 there are 5 RSL variables: ${GLOBUS_USER_HOME}, ${GLOBUS_USER_NAME}, ${GLOBUS_SCRATCH_DIR}, and ${GLOBUS_LOCATION}.
- executable is now a single local file path. Remote URLs are no longer allowed. If executable staging is desired, it should be added to the fileStageIn directive.
- stdin is now a single local file path. Remote URLs are no longer allowed. If stdin staging is desired, it should be added to the fileStageIn directive.
- stdout is now a single local file path, instead of a list of remote URLs. If stdout staging is desired, it should be added to the fileStageOut directive.
- stderr is now a single local file path, instead of a list of remote URLs. If stderr staging is desired, it should be added to the fileStageOut directive.
- scratchDirectory has been removed.
- gramMyJobType has been removed. "Collective" functionality is always available if a job chooses to use it.
- dryRun has been removed. This is obsolete given the addition of the holdState attribute. setting holdState to "StageIn" should prevent the job from being submitted to the local scheduler. It can then be canceled once the StageIn-Hold state notification is received.
- remoteIoUrl has been removed. This was a hack for pre-ws GRAM involved with staging via GASS, and has no relevancy in the current implementation.
- File Staging related RSL attributes have been replaced with RFT file transfer attributes/syntax.
- RSL substitution definitions and substitution references have been removed in order to be able to use standard XML parsing/serialization tools.
- RSL variables have been added. These are keywords denoted in the form of ${variable name} that can be found in certain RSL attributes.
- Explicit credential references have been added, which, along with use of the new DelegationFactory service, replace the old implicit delegation model.
Fault changes since GT version 3.2:
- CacheFaultType was removed since there is no longer a GASS cache.
- RepeatedlyStartedFaultType
was removed since there is no longer a
startoperation. Repeat creates with the same submission ID simply return the job EPR. - SLAFaultType was changed to ServiceLevelAgreementFaultType for clarification.
- StreamServiceCreationFaultType was removed since there is no longer a stream service.
- UnresolvedSubstitutionReferencesFaultType was removed since there is no longer support for substitution definitions and references in the RSL.
- DatabaseAccessFaultType was removed since a database is no longer used to save job data.
Although the basic functionality remains the same for MDS in GT4, the architecture has changed from OGSI in GT3 to WSRF in GT4. In OGSI, services advertise service data; in WSRF, services advertise resource properties. Resource Properties and service data are very similar -- both provide a mechanism for expressing arbitrary data about grid resources in XML format, as well as query and notification/subscription interfaces to that data.
The GT4 Index Service provides the same functionality as the GT3 Index service; however, the GT4 Index Service supports WSRF service group registration and resource property query and subscription/notification mechanisms, while the GT3 Index Service supported OGSI service group registration and service data query and subscription/notification mechanisms.
The following table shows a mapping of some GT3 concepts/tools to GT4.
Table 1. Comparison of GT3 and GT4
| Description | GT3 Version | GT4 Version |
|---|---|---|
| Query Operations | FindServiceData (to retrieve a single service data element by name or to perform an XPath query against a service's service data elements) | GetResourceProperty (to retrieve a single resource property by name), GetMultipleResourceProperties (to retrieve multiple resource properties by name), and QueryResourceProperties (to perform an XPath query against a service's resource properties). |
| APIs used for queries | OGSI (GT3) Core APIs | WS Core APIs |
| Command-line clients used for queries | ogsi-find-service-data | wsrf-get-property, wsrf-get-properties,
wsrf-query |
| Available GUIs | globus-sdb (standalone client) and WebSDB (web interface) | WebMDS (web interface) |
| Operations for subscription/notification | OGSI NotificationSource / NotificationSink | WS-Notification |
| APIs used for subscription/notification | OGSI (GT3) Core APIs | WS Core APIs |
| Index registration mechanism | GT3 services can be configured to publish their service data to index services. | Index Servers maintain aggregating service groups that
include registration information (timeout values, the mechanism to
use to acquire information, and additional mechanism-specific parameters)
The registration is accomplished by
adding an entry to an aggregating service group via the
mds-servicegroup-add command. In addition, services
may be configured to register themselves to the default index server
running in the same container. |
A more detailed mapping of OGSI concepts to WSRF concepts can be found here.
This version is not compatible with the GT3 version of CAS because of protocol changes. To migrate to this version, this component needs to be installed completely independent of any current GT3 CAS installs.
No special procedures are required for GSI-OpenSSH installations migrating from GT3 to GT4. GSI-OpenSSH is backward compatible.