Features in GT 4.2.1 WS RLS

Tested platforms include:

Protocol changes since GT 4.2.0

API changes since GT 4.2.0

Exception changes since GT 4.2.0

Schema changes since GT 4.2.0

WS RLS depends on the following GT components:

WS RLS depends on the following 3rd party software:

Security recommendations include:

The WS RLS 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, add and remove mappings from logical names to target names, to define and undefine attribute definitions associated with names, and to create, modify and delete attributes associated with names. A custom query expression dialect is defined by the WS RLS which may be used to query the mapping and attributes represented by the Resource Properties of the service.

The WSDL defines the only public interface to the WS RLS at this time.

The resource properties for the ReplicaLocationCatalog ReplicaLocatoinIndex port types are listed below:

	Note
	As a preview component the current WS-RLS specifies the following RPs but in most cases does not implement them in the current release. The developers of the component are providing the interfaces for review.

The WS RLS requires certain WSDD and JNDI settings to be properly configured. The installed JNDI configuration file may be found at $GLOBUS_LOCATION/etc/globus_wsrf_replicalocation_resource/jndi-config.xml. To view the default JNDI file (current snapshot) from the Globus CVS repository click here. The installed WSDD configuration file may be found at $GLOBUS_LOCATION/etc/globus_wsrf_replicalocation_service/server-config.wsdd. To view the default WSDD file (current snapshot) from the Globus CVS repository click here. In most cases, you will not need to alter either of these files.

This information is in addition to the basic configuration instructions in the Installing GT 4.2.1.

The WS RLS's WSDD determines which services will be activated by the GT Java WS Core container. By default, the WS RLS defines two services.

The WS RLS's JNDI configuration determines the resource class to be used for each service defined by the WS RLS WSDD. It also determines other critical settings used by these resources. In this file, you will find settings for the two default services defined in the WSDD.

Each service has a JNDI Resource of name RLSConnectionSource. This JNDI Resource is used by the WS RLS service to open a connection to the backend RLS service. In many cases, you may find that the default settings require no modification for your setup. The url parameter sets the endpoint for the backend RLS. The certfile and keyfile parameters set the certificate and key files to be used by the WS RLS to communicate securely with the backend RLS.

You will notice that the default settings use the container's suggested certificate and key file paths. If you have chosen different paths in which to keep these files, please adjust the settings accordingly. At present, the WS RLS uses a single identity (defined by the certificate and key) to authenticate itself with the RLS in order to perform any user requested operations. When the WS RLS interface is finalized, it will most likely use a different approach to authentication between WS RLS and the back end RLS. At this time, we expect that the interface will change such that the caller's credentials will be used to make calls between the WS RLS and the back end RLS on behalf of the originating caller.

...
    <resource
        name="RLSConnectionSource"
        type="org.globus.replica.rls.connection.impl.PooledRLSConnectionSource">
    <resourceParams>
      <parameter>
        <name>factory</name>
        <value>org.globus.wsrf.jndi.BeanFactory</value>
      </parameter>
      <parameter>
        <name>url</name>
        <value>rls://localhost</value>
      </parameter>
      <parameter>
        <name>certfile</name>
        <value>/etc/grid-security/containercert.pem</value>
      </parameter>
      <parameter>
        <name>keyfile</name>
        <value>/etc/grid-security/containerkey.pem</value>
      </parameter>
    </resourceParams>
    </resource>
...
    

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
   

Generating verbose log output is a critical aid in troubleshooting of the WS RLS and is useful when communicating problems to Globus support lists. To increase logging detail, add the following lines to the $GLOBUS_LOCATION/container-log4j.properties file.

...
log4j.category.org.globus.replica.location=DEBUG
log4j.category.org.globus.replica.rls=DEBUG
...