Please see Section N.2.1, “Perform documents and requests”.

Please see Section 16.1.7, “Logging”.

ANT property files can be used to save having to provide arguments to OGSA-DAI ANT targets at the command line. If the command is of form:

$ ant myCommand -Darg1=value1 -Darg2=value2

Then you can create a property file (my.properties for example) with the contents:

arv1=value1
arg2=value2

And then run:

$ ant -propertyfile my.properties myCommand

Note that properties can still be provided to ANT via the command-line and these take precedence over the ones in the property file, so for example you could run:

$ ant -propertyfile my.properties -Dargv1=myValue
$ ant -propertyfile my.properties -Dargv1=myOtherValue

This can be done as follows:

$ export GLOBUS_LOCATION=/PATH/TO/GT
$ cd $GLOBUS_LOCATION
$ ./bin/wsrf-get-property -s  URL \ 
  -k {http://ogsadai.org.uk}ResourceID RESOURCE-ID \
  PROPERTY-NAME

For example:

$ ./bin/wsrf-get-property
     -s http://localhost:9060/wsrf/services/dai/DataResourceInformationService \
     -k {http://ogsadai.org.uk}ResourceID MySQLDataResource \
     {uk.org.ogsadai.resource.activities}SupportedActivities

Alternatively you can use a WS-EPR in a file as follows:

$ ./bin/wsrf-get-property -e WS-EPR-FILE PROPERTY-NAME

For example:

$ ./bin/wsrf-get-property -e dai-epr.xml \
     {uk.org.ogsadai.resource.activities}SupportedActivities

The OGSA-DAI example server client (see Section 15.3.3, “Server client”) is one way of getting WS-EPRs for OGSA-DAI services and resources.

OGSA-DAI property names map to Globus property names as follows:

For example in the above we used:

{uk.org.ogsadai.resource.activities}SupportedActivities

for

{uk.org.ogsadai.resource.activities}SupportedActivities

You can use Apache Axis WSDL2Java. This can be run as follows:

$ setenv.sh
$ java org.apache.axis.wsdl.WSDL2Java -W URL

Where URL is the URL of the OGSA-DAI service. Please note that the -W flag is vital. This ensures that any stubs conform to the document/literal rather than wrapped/literal encoding. Both Globus and ourselves recommend document/literal. Inter-operability problems can arise between clients using wrapped/literal and OGSA-DAI services otherwise.

For more information on WSDL2Java see http://ws.apache.org/axis/java/reference.html

Refer to Section 7.3, “ Targetting an SQL query at multiple data resources using a resource group ” which explains how to run a query across multiple databases using resource groups.

If manipulating large sets of data the Java Virtual Machine may run out of memory. This can be alleviated by increasing the maximum memory heap size for the virtual machine using the XMxSIZE flag. For example:

$ java -Xmx70M ...

specifies a heap size of 70M. A similar XMsSIZE flag sets the initial heap size.

If you get an unconnected pipe error when trying to submit a workflow created using the client toolkit this is likely because you have created your activity objects and connected their outputs but have not added one or more of the activities to the workflow object.

OGSA-DAI's default file-based resource persistence components assume that all files in the resource files configuration directory (see Section 17.2.4.1, “Resource files name and location”) are resource configuration files. If you have temporary files created by a text editor in this directory (e.g. someFile~ or #someFile#) then these too will be considered as resource configuration files even if they are not intended to be.

When this occurs you will typically see an error similar to the following in the server-side logs:

There is a problem with the content of persistence file 
/home/michaelj/tomcat/webapps/dai/WEB-INF/etc/dai/resources/FileResource~.

Note that such errors do not prevent OGSA-DAI from initialising but if concerned you should just remove the unwanted files from the directory.

If a resource has been configured incorrectly then clients may be informed by the OGSA-DAI server that the resource is unknown. The OGSA-DAI server logs will provide information about why the configuration is incorrect. For example if the creationTime has value zonk then the logs will display an error message similar to:

#1185803462588:5# There is a problem with the content of persistence file /home/michaelj/test/tomcatAxis14/webapps/dai/WEB-INF/etc/dai/resources/Zonk.
#1185803462588:5# zonk is an illegal value.
#1185803462588:5# java.lang.NumberFormatException: For input string: "aaa"

If the data resource class cannot be found then the logs will display an error message similar to:

#1185803652710:2# There was a problem creating resource Zonk of type uk.org.ogsadai.DATA_RESOURCE.
#1185803652710:2# uk.org.ogsadai.resource.dataresource.file.FileDataResourc is an illegal value.
#1185803652710:2# Cannot find Java class uk.org.ogsadai.resource.dataresource.file.FileDataResourceNonExistantClass

Alternatively errors in resource configuration may only be realised when a request is submitted that contains activities that use the resource. e.g. if a file data resource configuration omits the dai.data.resource.path required by file resources then the server-side logs will contain an error of form:

2007-07-30 15:11:04,918 WARN  event.LoggingActivityListener [pool-1-thread-2,warnExceptionAndChildren:?] #1185804664917:5# An unchecked exception was caught during activity processing.
2007-07-30 15:11:04,918 WARN  event.LoggingActivityListener [pool-1-thread-2,warnExceptionAndChildren:?] #1185804664917:5# Expected dai.data.resource.path but could not be found.

This will be manifested client-side in the request status e.g.:

A problem has occured...
[1185804665299:2] uk.org.ogsadai.client.toolkit.REQUEST_COMPLETED_WITH_ERROR : ogsadai-114177657b5

The actual request execution status will contain more information in the entry for the activity that tried to use the resource.

Problems with activity configurations are manifested at the client-side as follows. For example:

[1185805382056:3] uk.org.ogsadai.client.toolkit.REQUEST_ERROR : ogsadai-11417822efa
[1185805382057:4] uk.org.ogsadai.GENERAL_REQUEST_USER_EXCEPTION
[1185805382057:5] uk.org.ogsadai.GENERAL_ACTIVITY_USER_EXCEPTION
[1185805382057:6] uk.org.ogsadai.UNSUPPORTED_ACTIVITY : uk.org.ogsadai.ListDirectoryX, FileResource

On the server this is manifested in the logs as follows. For example:

#1185805381799:4# A user problem has occurred during request processing.
#1185805381799:4# A user problem has occured during activity processing.
#1185805381799:4# An activity named uk.org.ogsadai.ListDirectoryX is not supported by the resource FileResource

There are two possible causes for this.

This error may be manifested in the server logs as follows:

#1185805812851:2# A problem has occurred during request processing.
#1185805812851:2# There was a problem creating the activity instance (activity name uk.org.ogsadai.ListDirectory, instance name uk.org.ogsadai.ListDirectory-ogsadai-1141788bcad).
#1185805812851:2# java.lang.ClassNotFoundException: uk.org.ogsadai.activity.file.ListDirectoryActivityXXX

This means that the activity configuration specifies an activity class name that does not exist or cannot be found by the OGSA-DAI server.

This may be manifested client-side as follows:

[1185805813092:1] uk.org.ogsadai.client.toolkit.REQUEST_ERROR : ogsadai-1141788c349
[1185805813092:2] uk.org.ogsadai.SERVER_ERROR_WITH_HOST : 1185805812851:2, coal.epcc.ed.ac.uk

This means there is a problem on the OGSA-DAI server and you (or the OGSA-DAI server administrator) should check the OGSA-DAI server logs for the error with the given ID.

This might be evidenced as follows when when invoking operations on OGSA-DAI-specific operations on OGSA-DAI GT services:

 
{http://ogsadai.org.uk/namespaces/2007/04/service/execution}resourceUnknownFault:
<ns2:id xmlns:ns2="http://ogsadai.org.uk/namespaces/2007/04/service/faults">
  uk.org.ogsadai.RESOURCE_UNKNOWN_ERROR
</ns2:id>
<ns3:msg xmlns:ns3="http://ogsadai.org.uk/namespaces/2007/04/service/faults">
  [1179491427865:0] uk.org.ogsadai.RESOURCE_UNKNOWN_ERROR : null
</ns3:msg>
<ns4:parameter xmlns:ns4="http://ogsadai.org.uk/namespaces/2007/04/service/faults">
null
</ns4:parameter>

{http://xml.apache.org/axis/}stackTrace:java.rmi.RemoteException: Failed to acquire resource; nested exception is: org.globus.wsrf.InvalidResourceKeyException

The most common cause of this is not having the file client-config.wsdd in a directory that is in your client's CLASSPATH

If you get an error from your client or in your logs:

Exception in thread "main" java.lang.IllegalAccessError: tried to access
field org.apache.xpath.compiler.FunctionTable.m_functions from class
org.apache.xml.security.Init at ...

then this is probably due to an incompatibility between the version of the xalan.jar shipped with the Globus Toolkit and the particular version of Java you are using.

To find out the version of Java you are using, run:

$ java -version

ensuiring that you run the same Java version as referenced by your JAVA_HOME environment variable.

Some builds of Java version 1.4.2_05 are known to cause this error. Versions of the Java 1.4 up to and including 1.4.2_04 are known to be okay. It is believed that a change of a variable from public to private in Java versions since 1.4.2_05 has caused this problem.

To fix this problem, you can use a newer version of xalan.jar. See the information on the "Endorsed Standards Override Mechanism" explained in the Xalan FAQ: http://xml.apache.org/xalan-j/faq.html#faq-N100CC.

Essentially, you need to download the latest version of Xalan and copy the xalan.jar, xercesImpl.jar and xml-apis.jar files to a directory called JRE_HOME/lib/endorsed where JRE_HOME is the base directory of your JRE installation.

Alternatively, switching to an earlier Java version (1.4.2_05 and previous) should solve this problem.

For more information on this bug take a look at:

If using a Macintosh that has a built-in Java 1.4.2_09 release then you should use Xalan 2.6.0.

OGSA-DAI does not provide any specific registry services.

You need to have the following in your CLASSPATH:

If a synchronous request takes a long time then the client connection to the OGSA-DAI server (via the data request execution service) may time out. In such circumstances, the OGSA-DAI server will continue to execute the workflow submitted by the client. There is however no way for the client to access their data since there is no means of getting the ID of the request (as known to the server) back to the client. This is a further argument in favour of the use of asynchronous requests for workflows that may have long execution times.