Tutorial TOC

• Introduction
• Chapter 1
• Chapter 2
• Chapter 3
• Chapter 4
• Chapter 5
• Chapter 6
• Chapter 7
• Chapter 8
• Appendix

Install GT3 core

Get gt3-cvs-core.tar.gz from the instructors

GLOBUS_LOCATION is the variable that lets various scripts know where the install is located.

This variable is just for convenience. It will be used throughout this document.

This creates the operating system dependent scripts inside of bin\

Test GT3 core

This starts the GT3 container (if you see "The input line is too long." error message on the console see the note about it in the appendix) Control will not return to the prompt. Press Ctrl-C to stop. If port 8080 is in use, this will fail. Specify an alternate port with -p.

Please stay in %GLOBUS_LOCATION% for this command. We will be using relative paths in some of our deployment parameters, and we will assume that you were in %GLOBUS_LOCATION% when you started your container.

Build Fileshare

Get fileshare-tutorial.tar.gz from the instructors

This builds the fileshare service and installs it into your GT3 install

Test Fileshare

Start the container again. You need to start one after having deployed the service. This is why we stopped the container earlier. Be in %GT3_LOCATION%, not %GT3_LOCATION%\bin See that FileShareService is now listed. The container will be started in a separate window

This is *not* a production step. We are only doing this because our code is in "samples" If you see "The input line is too long." error message on the console see the note about it in the appendix)

This is to make sure you're not in %GT3_LOCATION% when you retrieve files.

FILENAME may be any file in %GLOBUS_LOCATION%, like LICENSE. Do not specify a full or relative path to the file, just the word "LICENSE". After running the command, you should get that file in "c:\tutorial\gt3-cvs-core\client" directory.

[If you had to use an alternate port, you may specify a port after the filename, for example:
java org.globus.ogsa.impl.samples.fileshare.client.GetFile FILENAME PORT]

• src\org\globus\ogsa\impl\samples\fileshare\client\GetFile.java

  Change client.chapter1() call to client.chapter2() in the main() function.

• schema\samples\fileshare\fileshare_port_type.gwsdl

  Uncomment gwsdl:serviceData entries at end of file Look for "Uncomment for Chapter 3"

• src\org\globus\ogsa\impl\samples\fileshare\FileShareImpl.java

  Uncomment Chapter 3 sections to add SDE functionality Look for "uncomment for Chapter 3". There will be five sections to uncomment.

Undeploy Fileshare

If undeploy fails please see the following note for help.

Make your changes.

Restart Container

This starts the container in a separate window.

Query servicedata

First argument is namespace-qualified SDE, second arg is GSH. Should see a return value like:

You should recognized the originator and attrs from your populateAttrs() function. The actual value here is "0". Also try querying for the filelist. Both should be initialized at startup by the postCreate call.

Try running GetFile a number of times. Query the servicedata again. It should update appropriately.

Try running the query against your neighbor's GSH. Get a file from them, then query the SDE again to see that it updated.

Extra exercise idea: Create new SDEs of your own

• fileshare-server-config.wsdd

  Uncomment operationProviders, registry, registry-lifetime, and registry-keepalive parameters. The instructors will provide the host:port for the registry. Make sure you change the registry parameter before deploying!

• schema\samples\fileshare\fileshare_port_type.gwsdl

  Add "ogsi:NotificationSource" to extends= line. It is space delimited, no commas required.

Clean up, modify code, redeploy

This starts the container in a separate window.

Query the Index

Verify that your service appears in the index:

The instructors will provide the GSH of the Index to register to.

Your IP address should appear in the (very long) results in an entry named "ogsi:handle" under a ogsi:memberServiceLocator entry:

<ogsi:memberServiceLocator xsi:type="ogsi:LocatorType">
<ogsi:handle xsi:type="ogsi:HandleType">http://140.221.57.104:8080/ ogsa/services/samples/fileshare/FileShareService</ogsi:handle>


Note that depending when your service gets registered, there may be many other entries already. It may be easier to save the output to a file, then search for your IP.

Query to find the lifetime of your subscription:

In the large amount of output, you should see lines like:

Check again after that time has passed:

The dates should be current again:

• Create %GLOBUS_LOCATION%\_your name_

• src\org\globus\ogsa\impl\samples\fileshare\client\GetFileIndex.java

  Inspect the code to find the XPath queries

Add a file and restart (no undeploy/redeploy required)

Be aware! While a Windows machine will not necessarily be case-sensitive about the filename, Unix machines will be. Make sure that you have the capitalization of your filename correct when you request it.

Now try retrieving a file from your neighbor by searching the Index for their name. After you retrieve the file, run the query again. You should see multiple sources for the file now.

Extra exercise idea: Construct more complicated XPath queries

• fileshare-server-config.wsdd

  Uncomment securityConfig parameter

• src\org\globus\ogsa\impl\samples\fileshare\client\GetFile.java
src\org\globus\ogsa\impl\samples\fileshare\client\GetFileIndex.java


  Uncomment security code

• %USERPROFILE%\.globus\cog.properties

  Add a line reading cacert=C\:\\tutorial\\fileshare-tutorial\\certificates
  You do not need to define %USERPROFILE%, Windows automatically defines it for you.

• src\org\globus\ogsa\impl\samples\fileshare\security-config.xml

  This adds authentication to the getFile operation, leaves other operations insecure

• %TUTORIAL_LOCATION%\certificates\usercert.pem

• %TUTORIAL_LOCATION%\certificates\userkey.pem

  These will be your user certificate and key.

Clean up, modify code, redeploy

Try different operations

You should see the normal output, because the findServiceData call has been left without security. Query your fileshare service directly, not the Index being run by the instructors.

Output should look like:

On the server side, you should see something like:

This is because you have not initialized your proxy to interact with secure operations.

Create a proxy

Expected output:

You may see a warning to check filesystem permissions. This is an expected Windows warning.

Extra exercise idea: Try adding gridmap authorization to the GetFile operation

• fileshare-server-config.wsdd

  Change the name of the service to FileShareFactoryService
  Uncomment the factory parameters
  

  Prefix the parameters of FileShareService with "instance-". Everything after the "ALL" comment, including the operationProviders and the securityConfig. Everything. Really. Including the Chapter 4 section.

• src\org\globus\ogsa\impl\samples\fileshare\FileShareFactoryCallback.java

  This is what the generic factory will call to create a FileShareImpl

• src\org\globus\ogsa\impl\samples\fileshare\client\CreateFileShare.java

  This is the client code to call the createService operation on the FileShareFactoryService. That operation is defined by the FactoryProvider. When createService is called, the FactoryProvider will invoke the createServiceObject operation on the factoryCallback specified in the .wsdd. That in turn will invoke the FactoryCallback listed previously.

Clean up, modify code, redeploy

Use the Factory

First argument is name of directory to share.

Expected output:

If it fails with "Error: org.gridforum.ogsi.NoSuchServiceFaultType: samples/fileshare/FileShareFactoryService", verify that you renamed the FileShareService to the FileShareFactoryService in the .wsdd.

Now get a file from the newly-created service:

Verify that the created service is also registering into the index:

>subst p: c:\tutorial\gt3-cvs-core 

>set GLOBUS_LOCATION=p: