Oddments

Odd Features not documented elsewhere.

• Overview
• Bean Bus
• Web

Tasks

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. Doing this locally has always been relatively simple with input but remotely required waiting 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.

Here's 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 when 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.

Bean Bus

Bean Bus provides data pipeline functionality within Oddjob. A bus generally consists of a Bus Driver that drives data down the pipeline to subsequent destinations.

Bean Bus is likely to be of most use to developers who wish to quickly get data from one place to another. A sister project of Oddjob, DIDO provides Bean Bus compatible components for moving data between Databases, CSV files, JSON files and Excel.

For more on bean bus, look at the bus: prefixed jobs in the reference, starting with bus:bus

Web

In addition to the Web UI Oddjob provides basic wrappers around Jetty to provide a web:server and web:client

The server exposes Jetty's pattern of pluggable handlers. Handlers provided out of the box with Oddjob are:

web:resource

Publishes files or resources. Use this to create a simple web server.

web:oddjob-rest

Provide a web service interface to Oddjob. Used to provide the UI in version 1.5 but has been replaced by the bespoke Http/Web Socket handler below in 1.6.

web:remote-handler

The Handler for Oddjob's web UI.