If you want to use this for standard EUROGRID resource brokering or
GT2- or GT3-enabled resource brokering, follow the instructions for
version 1.4 of the broker.
GETTING THE RESOURCE BROKER WORKING AS A WEBSERVICE
===================================================
You need to set up two things:
An NJS containing the interface module
A WS hosting environment containing the broker core
YOU MUST GET THE COUPLING BETWEEN THESE TWO CORRECT OR NOTHING WILL
WORK AT ALL.
Setting Up the Interface Module
-------------------------------
You need to put the broker JAR file on the NJS's classpath, but you
also need a whole bunch of JARs from the Pallas webservice gateway.
I've never narrowed down which ones are critical; I just add them all.
Your BROKER section from the IDB should be something like this (a copy
of the configuration in use at Manchester):
BROKER org.uom.arcon.njs.broker.ws.BrokerNJSIfc [
/home/unicore/unicore/queuecheck
]
The self attribute says what we publish ourselves as as a Webservice,
which is required so the Broker can contact us back to get QoS data,
etc.
The provider attribute names the Broker webservice that is going to do
the bulk of the work.
The ttl attribute says how long (in milliseconds) delegated QoS and
Resource Checks have before they become uninteresting. Shorter values
reduce the bad effects of unresponsive brokers, but might cause offers
to be missed if a broker is just busy.
The qos element describes the script that gets QoS data from the TSI,
with the user attribute saying the default identity to use for the
task.
The service element's config attribute says where to load the
configuration file for the Pallas webservice gateway code. (Note that
we're not using the code to set up a gateway.) The contents of that
file are:
This starts the server on port 8085, doesn't use SSL to secure it (not
a great long-term choice, but good for demonstration purposes), sets
up the logging and a watchdog task, and configures the size of the
thread pool. I think.
Setting Up the Broker Webservice
--------------------------------
First, make sure you have Apache Tomcat (servlet container) and Apache
Axis (webservice engine). Make sure that Tomcat will start on the
correct port (in the demonstration configuration, that is port 8090)
by specifying the correct bit in Tomcat's server.xml (it is set in a
Connector element's port attribute.)
Then add uombroker.jar, ajo.jar and njs.jar to the axis lib directory
(no classpaths need modifying as the Axis engine picks this up
automatically). The lib directory is probably
CATALINA_HOME/webapps/axis/WEB-INF/lib (where CATALINA_HOME is the
place where Tomcat was installed.)
In the same directory as uombroker.jar, create a file called
Broker.config with contents something like this:
The master element has two attributes:
handle is a reference to the NJS interface module defined above
vsite is the name of the Vsite for which we generate offers; the
format is mostly self-explanatory (host and port describe the Usite,
the path fragment gives the name of the Vsite within the Usite.)
The offer element allows control (via the validityPeriod attribute,
which is in hours) over how long tickets are valid for.
The delegate element contains a collection of vsite elements, each of
which has a vsite attribute (formatted exactly like the vsite
attribute of the master element) to which this broker will delegate
requests. The above configuration does not delegate at all, as the
delegate element has empty content (the comment doesn't count.)
Now, you are ready to start Tomcat. (The start_tomcat shell script is
useful for this.) The first time you start Tomcat, you need to deploy
the broker into the Axis container. THIS ONLY NEEDS TO BE DONE ONCE.
To deploy the broker, you will need the following in a wsdd document:
Use your favourite Axis deployment technology to do this, as detailed
on the Axis website. I admit to having forgotten how to actually do
this though; as I said, it only needs doing once.