Features new in release GT 4.2.0:

Other Supported Features

Deprecated Features

Tested Platforms for DRS

Protocol changes since GT version 4.0.x:

API changes since GT version 4.0.x:

Exception changes since GT version 4.0.x:

Schema changes since GT version 4.0.x:

DRS depends on the following GT components:

DRS depends on the following 3rd party software:

The DRS is a WS-RF compliant service implemented using the Globus Java WS Core. It exposes a set of Resource Properties and operations to allow users to create replication resources, control replication resources' lifecycle, and inspect the state of replication resources' activities along with the success or failure of individual replicated data sets. In this release, the WSDL and the command-line clients are the primary public interfaces for developers. Two java interfaces exist on the service-side to allow developers and users to modify the source selection behavior of the DRS. These interfaces allow users to chose alternate schemes to select sources beyond the random selection provided by default.

Interfaces to influence source selection include:

Please see service-side interfaces for documentation on these interfaces.

The DRS provides a set of Resource Properties and SOAP operations to create, manipulate and inspect replication activities. Users will begin by creating a replication resource (AKA "Replicator") by invoking the create operation and passing it a URL of the replication request file (described in the domain-specific interface section). Users may start, stop, suspend and resume the Replicator when necessary. Typically a user is expected to simply start the resource and allow it to run through completion. During and after the course of replication activities performed by the resource, users may invoke standard "get resource property" and DRS-specific "find" operations to inspect the state of the resource. When the resource finishes the replication activities and the user has satisfactorily inspected the resource state, the resource should be destroyed using the standard "destroy" operation.

Supported operations include:

Supported resource properties for DataRep include:

Supported faults include:

For more information, please see the Replicator Port Type or the complete list of schemas.

The DRS domain-specific interface defines the structure and expected contents of a request file used when creating a replication resource. When the client invokes the create operation of the DRS, it will be expected to submit a properly formatted request file. It is important to understand the structure of the request file and to ensure that the file is well-formed.

For the present release, the DRS request file format is fairly trivial. The request file is structured as a "Table" style of rows and columns of text. Each row represent a requested replication item described in two columns. The first column contains the identifier of the data set which will be discovered and replicated. The identifier must be resolvable by the Replica Location Index (see the JNDI configuration for defaultIndexUrl). In most cases, it is expected that the identifier be a Logical Filename (LFN) per the Replica Location Service definition. The second column of the row contains the URL of the "destination" for the replication item. The two columns must be delimited by a TAB character and each row must be delimited by an EOL character.

	Note
	The service will not accept SPACE characters as a substitute for the TAB character.

The following example shows the output of a small request file.

% cat example.req
my-lfn-1        gsiftp://myhost:9001/sandbox/examples/files/my-pfn-1
my-lfn-2        gsiftp://myhost:9001/sandbox/examples/files/my-pfn-2
my-lfn-3        gsiftp://myhost:9001/sandbox/examples/files/my-pfn-3
my-lfn-4        gsiftp://myhost:9001/sandbox/examples/files/my-pfn-4
my-lfn-5        gsiftp://myhost:9001/sandbox/examples/files/my-pfn-5
    

The DRS requires certain JNDI settings to be properly configured. The installed JNDI configuration file may be found at $GLOBUS_LOCATION/etc/globus_wsrf_replicator/jndi-config.xml. To view the default configuration file (shipped with the GT 4.2.0 release) from the Globus CVS repository click here.

The settings are structured as name-value pairs. For example:

    <parameter>
      <name>defaultIndexUrl</name>
      <value>rls://127.0.0.1:39281</value>
    </parameter>
    

The following settings must be properly configured:

The following information applies to Java WS Core and those services built on it.

Logging in the Java WS Core is based on the Jakarta Commons Logging API. Commons Logging provides a consistent interface for instrumenting source code while at the same time allowing the user to plug-in a different logging implementation. Currently we use Log4j as a logging implementation. Log4j uses a separate configuration file to configure itself. Please see Log4j documentation for details on the configuration file format.

   #for debug level logging from org.globus.package.FooClass 
   log4j.category.org.globus.package.name.FooClass=DEBUG
   #for warnings from org.some.warn.package
   log4j.category.org.some.warn.package=WARN
   

To turn on debug logging for DRS, add the line:

 log4j.category.org.globus.replica=DEBUG

to the appropriate properties file.