Jython scripts

In Section 2.2.6, we described a xbook engine as an intermediary between the xbook client and the xbook. In this section, we describe the interface between the xbook jython engine and xbook.

When the jython engine is invoked by the xbook manager, it creates a jython interpreter. It then places the following object into the namespace (i.e., main):

xbook

is a instance of the class defined in Xbook.java from the package xbooks.server.engine. This object contains any meta-data about the xbook that needs to be passed into the xbook. Currently, this object is used to store the path of the xbook. The user can retrieve the path using the getPath() method. For example, path = xbook.getPath();. (Note: the xbook object should also be used to get the user's delegated proxy credentials once delegation is incorporated, e.g., a getProxy() method.)

The jython engine also retrieves information from the registry entry describing the xbook. It contains the following information:

• the name of the xbook script to interpret
• the name of the handler class defined in the xbook script

Then the jython engine first reads in the xbook handler script This xbook handler script is a jython module and must contain a handler class definition and may contain other class and function definitions; it should not contain a main. Next, the jython engine creates an instance of the xbook handler class. This handler class will contain methods that will be mapped to user requests coming from the client. The handler class must contain a initialize and finalize method and any number of doXXX methods where XXX is the name of a action variable defined in the user interface. The following describes their mapping:

__init__(self, workingDir)

The jython engine will create the instance of the handler using handler = <handler name>(xbookPath). Therefore, the user must define a constructor to handle this. This will communicate the location of the xbook path and can be used inside the xbook scripts as the "working directory".

initialize(self, out)

This function will be called when the user requests this xbook from the xbook client. Typically, initialize will return HTML to the java ByteArrayOutputStream, out. The HTML will typically contain a form definition with a number of input tags.

finalize(self, out)

This function will be called when the xbook session is complete. Section 3.2.3 describes how xbook completion is determined. Users may write cleanup messages to the java ByteArrayOutputStream, out.

doXXX(self, formValues, out)

When a form is submitted from the client, it contains a special input variable named xbooks.action. The value of this variable is the XXX of doXXX. Therefore, for each form output that is returned the client, there should be a corresponding doXXX routine to handle the results. The values from the form will be available in the hash table formValues. Since the input variables can contain multiple values, the values are stored as an array. Therefore, formValues is a hashtable of string arrays. The user can choose to output either plain HTML to out or another form (in which case, the will need to define another doXXX routine to handle that output).

(Restrictions on the output that can be returned from these functions is described in Section 5.1.2.)

It is expected that users will use write these methods to launch, monitor, and archive their specific Grid application jobs. But really, the user can place any functionality they want inside these methods; there are no restrictions.