Tasks

Parameterised Jobs

• Overview
• Limitations

Overview

The idea of a Task was introduced in Oddjob 1.5 as a way to get round the limitations of running jobs remotely with different properties set. Doing this locally has always been relatively simple with input but remotely required waiting for for a property to be set.

Here's the server side of such an arrangement:

<oddjob>
    <job>
        <sequential>
            <jobs>
                <jmx:server root="${server-jobs}" xmlns:jmx="http://rgordon.co.uk/oddjob/jmx"/>
                <repeat>
                    <job>
                        <sequential id="server-jobs">
                            <jobs>
                                <variables id="vars"/>
                                <wait id="wait" for="${vars.greeting}"/>
                                <echo id="echo">${vars.greeting}</echo>
                            </jobs>
                        </sequential>
                    </job>
                </repeat>
            </jobs>
        </sequential>
    </job>
</oddjob>

And here's the client side:

<oddjob>
    <job>
        <sequential name="Client Jobs" stateOperator="SERVICES">
            <jobs>
                <jmx:client id="client" connection="${server.address}" xmlns:jmx="http://rgordon.co.uk/oddjob/jmx"/>
                <input>
                    <requests>
                        <input-text prompt="Greeting" property="some.greeting"/>
                    </requests>
                </input>
                <set>
                    <values>
                        <value key="client/vars.greeting" value="${some.greeting}"/>
                    </values>
                </set>
            </jobs>
        </sequential>
    </job>
</oddjob>

The server waits for the greeting property to be set on the variables job and then echos the value.

The Client prompts the user for input and then sets this property remotely with the set job. Now this works, but it's ugly.

Heres the same problem with a task-service on the server:

<oddjob>
  <job>
    <sequential>
      <jobs>
        <jmx:server root="${server-jobs}" xmlns:jmx="http://rgordon.co.uk/oddjob/jmx"/>
        <sequential id="server-jobs" name="Server Jobs">
          <jobs>
            <task-service id="greeting-service">
              <requests>
                <input-text prompt="Name" property="some.greeting"/>
              </requests>
              <job>
                <echo id="echo">${some.greeting}</echo>
              </job>
            </task-service>
          </jobs>
        </sequential>
      </jobs>
    </sequential>
  </job>
</oddjob>

And here's the client:

<oddjob>
    <job>
        <sequential name="Client Jobs" stateOperator="SERVICES">
            <jobs>
                <jmx:client id="client" connection="${server.address}" xmlns:jmx="http://rgordon.co.uk/oddjob/jmx"/>
                <input id="input">
                    <requests>
                        <value value="${client/greeting-service.requests[0]}"/>
                    </requests>
                </input>
                <task-request taskExecutor="${client/greeting-service}">
                    <properties>
                        <value value="${input.properties}"/>
                    </properties>
                </task-request>
            </jobs>
        </sequential>
    </job>
</oddjob>

The client gets input from the user as before, but reads the request from the requests property of the service on the server. The task-request then requests the task executes the request on the service on the server.

Both the above examples above can be run by specifying a server.address property when running the client, and running the server with a JMX port as outlined in the server documentation. The client and server can also be run together in the same JVM with no connection property set on the client as they are for the tests.

When running either the client or server from explorer, if the service is selected the job menu contains an 'execute' option, which if selected will prompt for the properties of the task and then execute the task.

The web interface also supports executing jobs and produces pop-up form to prompt for properties before executing the task.

Limitations

The current task service only supports a single execution at a time. If another request occurs while the task is executing it will be ignored. A parallel version that supports concurrent executions will be developed at some point in the future.