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 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 GT System Administrator's Guide.

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>
...