Java WS Core provides per- gar configuration and supports configuration profiles. The configuration information of a service is mainly encapsulated in two separate configuration files:

server-config.wsdd (Web Service Deployment Descriptor) - contains information about the web service.
jndi-config.xml (JNDI configuration file) - contains information about the resource management.

A service that supports security might also have the security-config.xml (security deployment descriptor) file. Please see Java WS Security Descriptor Framework for details.

All these configuration files are dropped into the $GLOBUS_LOCATION/etc/<gar.id>/ directory during the deployment process.

2. Syntax of the interface:

2.1. Global Configuration

The global properties are specified in the <globalConfiguration> section of *server-config.wsdd files in the $GLOBUS_LOCATION/etc/globus_wsrf_core/ directory. The configuration item name corresponds to the "name" attribute in a <parameter> sub element, and the value is put as a "value" attribute within the same parameter element.

Table 1. General configuration parameters

Name	Value	Description	Comments
logicalHost	<hostname>	This parameter specifies the hostname to use instead of the default local host. It is equivalent to setting the `GLOBUS_HOSTNAME` environment property. Can be FQDN or just hostname.	Optional
disableDNS	<boolean>	This parameter specifies whether to perform DNS lookup on the `logicalHost` parameter. By default, `"false"` is assumed (DNS lookup is performed).	Optional
domainName	<domain name>	This parameter specifies the domain name to append to the host name if the host name is not qualified by a domain.	Optional
publishHostName	<boolean>	This parameter specifies whether to publish the hostname or the ip address. It is only used when DNS lookups are enabled (`disableDNS` is false).	Optional
server.id	<string>	This parameter specifies the server id. The server id is used to uniquely identify each container instance. For example, each container gets its own persistent directory based on the server id. By default, the standalone container server id is "`<ip>-<containerPort>`". In Tomcat, the server id will default to "`<ip>-<webApplicationName>`".	Optional

Table 2. Standalone/embedded container-specific configuration parameters

Name	Value	Description	Comments
containerThreads	<int>	This parameter controls the initial thread pool size for the container. If not set, it defaults to 1.	Optional
containerThreadsMax	<int>	This parameter sets the maximum number of threads for the container. By default it is set to 4 * the `containerThread` setting.	Optional
containerThreadsHighWaterMark	<int>	This parameter controls when the thread pool of the container should start shrinking (if the number of idle threads exceeds this number). By default it is set to 2 * the `containerThread` setting.	Optional
containerTimeout	<int>	This parameter controls the container timeout. That is, the maximum amount of time the container will wait to receive a message from the client. By default it is set to 3 minutes.	Optional
webContext	<name>	This parameter specifies the context name under which the services are published under: `http://<host>:<port>/<webContext>/services/MyService`. By default "`wsrf`" name is used. In Tomcat, this parameter is set to the web application's name.	Optional

Table 3. Default container thread pool settings

Type	Min. threads	Max. threads
standalone	2	20
embedded	1	3

2.2. Service Configuration

2.2.1. WSDD

An example of a deployment descriptor for a CounterService:

 <service name="CounterService" provider="Handler" use="literal"
     style="document"> <parameter name="className"
     value="org.globus.wsrf.samples.counter.CounterService"/> <parameter
     name="handlerClass" value="org.globus.axis.providers.RPCProvider"/> <parameter
     name="scope" value="Application"/>
     <wsdlFile>share/schema/core/samples/counter/counter_service.wsdl</wsdlFile>
     <parameter name="allowedMethodsClass" value="com.counter.CounterPortType"/>
     <parameter name="providers" value=" DestroyProvider SetTerminationTimeProvider
     GetRPProvider SubscribeProvider GetCurrentMessageProvider"/> </service>

Services are defined in a <service> element. The "name" attribute of the <service> element defines the remotely accessible name of the service. The service handle will have the form of <hosting environment URL>/foo, where:

the hosting environment URL typically is http://<host>:<port>/wsrf/services.
foo is the name of the service (<service name="foo" ...>).

The use attribute should be set to literal and the style attribute to document for all WSRF/WSN based services. The configuration information for a service is defined by various <parameter> sub-elements within a <service> element. The configuration item name corresponds to the "name" attribute in a <parameter> sub element, and the value is put as a "value" attribute within the same parameter element.

Table 4. Axis Standard Parameters

Name	Value	Description	Comments
className	<class>	This parameter specifies a class that implements the web service methods.	Required
handlerClass	<class>	This parameter specifies what dispatcher to use to send a request to a service method. This parameter is required if the provider attribute of the service is set to `Provider`. The default dispatcher we provide is called org.globus.axis.providers.RPCProvider. It enables special features such as operation providers or security support.	Recommended in our environment
scope	<value>	Scope value can be one of: Request (the default), Application, or Session. If Request scope is used, a new service object is created for each SOAP request that comes in for the service. If Application scope is used, only a single instance of the service object is created and used for all SOAP requests that come in for the service. If Session scope is used, a new service object is created for each session-enabled client who accesses the service. Note: Only Request and Application scopes are supported when used with org.globus.axis.providers.RPCProvider handlerClass.	Application scope is recommended
wsdlFile	<path>	This parameter points to a wsdl file for the service. The wsdl file must contain the wsdl:service entry. The file location can be relative or absolute. A relative file location is recommended.	Required in our environment
allowedMethods	<list of methods>	This parameter specifies a space or comma separated list of method names that can be called via SOAP. `"*"` indicates that all methods of the service class can be invoked via SOAP.	Optional. By default all methods are allowed.

Table 5. Java WS Core Parameters

Name	Value	Description	Comments
loadOnStartup	<boolean>	If set to true this parameter will cause the web service and the corresponding ResourceHome (if any) to be initialized (with proper security settings if configured) at container startup. This is useful for restarting some tasks, etc. at container startup without having to call the service. Please check Section 1.4, “Lifecycle and activation” for details.	Optional
allowedMethodsClass	<class>	This parameter is similar to the allowedMethods standard Axis property but it specifies a Java class or an interface that is introspected to come up with a list of allowed methods that can be called remotely on the service. It is useful for easily restricting the SOAP-accessible methods of the service. Usually the class specified in this parameter would be the remote interface class generated for the service. This parameter only has effect if used with org.globus.axis.providers.RPCProvider handlerClass.	Optional
providers	<list of providers>	This parameter specifies a space separated list of provider names or class names. Please see the Operation provider support section for details. This parameter only has effect if used with org.globus.axis.providers.RPCProvider handlerClass.	Optional

Please see Custom Deployment for details on Axis Web Services Deployment Descriptor.

2.2.2. JNDI

An example of a JNDI configuration bit for a CounterService:

 <service name="CounterService"> <resource name="home"
     type="org.globus.wsrf.samples.counter.CounterHome"> <resourceParams>
     <parameter> <name>factory</name>
     <value>org.globus.wsrf.jndi.BeanFactory</value>
     </parameter> <parameter>
     <name>resourceClass</name>
     <value>org.globus.wsrf.samples.counter.PersistentCounter</value>
     </parameter> <parameter>
     <name>resourceKeyName</name>
     <value>{http://counter.com}CounterKey</value>
     </parameter> <parameter>
     <name>resourceKeyType</name>
     <value>java.lang.Integer</value> </parameter>
     </resourceParams> </resource> </service>

Each service in WSDD should have a matching entry in the JNDI configuration file with the same name. Under each service entry in JNDI different resource objects or entries might be defined. Please see Section 1.3, “JNDI configuration and programming” for details. Each service entry in JNDI should have a resource defined called "home". That resource is the ResourceHome implementation for the service (as specified by the type attribute). Depending on the ResourceHome implementation different options can be configured for the ResourceHome. Currently we have two main base ResourceHome implementations: org.globus.wsrf.impl.ResourceHomeImpl and org.globus.wsrf.impl.ServiceResourceHome.

Note: All "home" resources must specify a factory parameter with org.globus.wsrf.jndi.BeanFactory value.

2.2.2.1. ResourceHomeImpl

The ResourceHomeImpl is a generic and reusable ResourceHome implementation. It supports persistent resources, resource caching, resource sweeper, etc.

Table 6. ResourceHomeImpl parameters

Name	Value	Description	Comments
resourceKeyName	<qname>	This parameter specifies a QName of the resource key. The namespace is specified in the `{}`. For example, this QName will be used to discover the SOAP header that contains the key of the resource in the request.	Required
resourceKeyType	<class>	This parameter specifies the type of the resource key as a Java class. The key XML element is deserialized into this Java type. The Java type can be for any simple Java type, Axis generated bean, or a class with a type mapping.	Optional. Defaults to `java.lang.String`
resourceClass	<class>	This parameter specifies the classname of the resource object. This is used to ensure that right type of resource object is added to resource home and to instantiate the right object if the resource supports persistence.	Required
sweeperDelay	<long>	This parameter specifies how often the resource sweeper runs in milliseconds.	Optional. Defaults to 1 minute
cacheLocation	<jndi path>	This parameter specifies the JNDI location of the resource cache for this resource home. Please see Configuring Resource Cache below for details.	Optional

2.2.2.1.1. Configuring Resource Cache

If ResourceHomeImpl is configured with resource class that implements the PersistenceCallback interface it will store the resource objects wrapped in Java SoftReference. That allows the JVM to automatically reclaim these resource objects, thus reducing the memory usage. Since the JVM can decide to reclaim these objects at any point, sometimes a resource object can be reclaimed between two subsequent invocations on the same resource. This for example can cause the state of the resource to be reloaded from disk on each call. To prevent the JVM from reclaiming the resource objects so quickly a cache can be setup up to hold direct references to these objects. A basic LRU (least recently used) cache implementation is provided. Other cache implementations can be used as long as they implement the org.globus.wsrf.utils.cache.Cache interface.

To configure a cache for ResourceHomeImpl first define a cache resource entry in JNDI, for example:

 <resource name="cache" type="org.globus.wsrf.utils.cache.LRUCache">
       <resourceParams> <parameter>
       <name>factory</name>
       <value>org.globus.wsrf.jndi.BeanFactory</value>
       </parameter> <parameter>
       <name>timeout</name>
       <value>120000</value> </parameter>
       <parameter> <name>maxSize</name>
       <value>1000</value> </parameter>
       </resourceParams> </resource>

The "timeout" parameter (in ms) is used to specify the idle time of the resource object before it is removed from the cache. Also, the "maxSize" parameter can be used to specify the maximum size of the cache. By default the cache is configured without any size limit and 5 minutes timeout.

Once the cache resource entry is defined add the "cacheLocation" parameter to the service home resource. The "cacheLocation" parameter value is the JNDI name of the cache resource:

 <service name="CounterService"> <resource name="home"
       type="..."> <resourceParams> ... <parameter>
        <name>cacheLocation</name>
        <value>java:comp/env/services/CounterService/cache</value>
        </parameter> ... </resourceParams>
       </resource> ... <resource name="cache"
       type="org.globus.wsrf.utils.cache.LRUCache"> ... </resource>
       </service>

Please note that once the object is removed from the cache it is still up to the JVM to actually reclaim the object. Also, the same cache resource can be reused in different services but usually one cache per service should be configured.

2.2.2.2. ServiceResourceHome

This implementation does not accept any special parameters.

2.3. Usage Statistics Configuration

Java WS Core container and other GT services are configured to send out usage statistics. Please see the Usage Statistics section in the Java WS Core Admin Guide for more information.

The targets to which the usage statistics are sent to are configured via the usageStatisticsTargets parameter defined in the <globalConfiguration> section of the $GLOBUS_LOCATION/etc/globus_wsrf_core/server-config.wsdd file. The usageStatisticsTargets parameter specifies a space separated list of targets to which the usage statistics of various components will be sent to. Each target is of form: host[:port] (port is optional, if not specified a default port will be assumed). By default usage statistics are sent to usage-stats.globus.org:4810.

To disable sending of the usage statistics remove this parameter, comment it out, or remove all of its values.

2.4. Configuration Profiles

Configuration profiles allow for the same Java WS Core installation to have multiple configurations. That is, the same installation can be used to run different containers each with different configuration.

When a .gar file is deployed, a -Dprofile option can be specified to deploy the configuration files under a specific profile name. If the profile name is specified, the deploy operation will drop the configuration file as $GLOBUS_LOCATION/etc/<gar.id>/<profile.name>-server-config.wsdd and/or $GLOBUS_LOCATION/etc/<gar.id>/<profile.name>-jndi-config.xml. The configuration profiles can also be created by hand simply by copying and/or renaming the configuration files appropriately. Each configuration profile should duplicate the contents of $GLOBUS_LOCATION/etc/globus_wsrf_core/server-config.wsdd and $GLOBUS_LOCATION/etc/globus_wsrf_core/jndir-config.xml in order to have the basic functionality work properly.

Once a configuration profile is created, the standalone container can be started with a -profile option to load configuration files in a specific profile.

3. Configuring an `/etc/init.d` entry for the standalone container

To create an /etc/init.d entry for the standalone container do the following steps:

As root create /etc/init.d/gt4container script with the following contents:

ACCOUNT=globus GLOBUS_LOCATION=<globusLocation>
     INIT=$GLOBUS_LOCATION/etc/init.d/globus-ws-java-container su $ACCOUNT -c "$INIT
     $*"

Set executable permissions on the /etc/init.d/gt4container script and register it with the init.d system:
```
$ chmod +x /etc/init.d/gt4container $ /sbin/chkconfig -a gt4container
```
After this step the container should start automatically after the next reboot. Make sure the container is configured with a global security descriptor that explicitly points to long term credentials.

To start the container by hand run:

$ /etc/init.d/gt4container start

To stop the container by hand run:

$ /etc/init.d/gt4container stop

Prev		Next
Services and WSDL	Home	Environment variable interface

Software Links

Getting Started

Reference

Manuals

Common Runtime

Security

Data Mgt

MDS4

Execution Mgt

Configuration interface

1. Configuration overview