next up previous contents
Next: The kill Service Method Up: Solving Problems Remotely with Previous: The getJobID Service Method   Contents


The knock Service Method

The OSSolverService terminates after executing the send method. Therefore, it is necessary to know when the job is completed on the remote server. One way is to include an email address in the <contact> element with the attribute transportType set to smtp. This was illustrated in Section 10.3.1. A second way to check on the status of a job is to use the knock service method. For example, assume a user wants to know if the job with JobID 123456abcd is complete. A user would make the request

./OSSolverService -config ../data/configFiles/testRemoteKnock.config
where the testRemoteKnock.config file is
-serviceLocation http://gsbkip.chicagogsb.edu/os/OSSolverService.jws
-osplInput ../data/osolFiles/demo.ospl
-osol ../data/osolFiles/retrieve.osol
-serviceMethod knock
the demo.ospl file is
<?xml version="1.0" encoding="UTF-8"?>
<ospl xmlns="os.optimizationservices.org">
<processHeader>
<request action="getAll"/>
</processHeader>
<processData/>
</ospl>
and the retrieve.osol file is
<?xml version="1.0" encoding="UTF-8"?>
<osol xmlns="os.optimizationservices.org">
 	<general>
 		<jobID>123456abcd</jobID>
	</general>
</osol>
The result of this request is again a string in OSpL format, with the data contained in its processData section. Part of the return format is illustrated below.
\begin{verbatimtab}[4]
<?xml version=''1.0'' encoding=''UTF-8''?>
<ospl xmlns=''...
...ation>
</job>
</jobs>
</statistics>
</processData>
</ospl>
\end{verbatimtab}
Notice that the <state> element in <job jobID="123456abcd"> indicates that the job is finished.

When making a knock request, the OSoL string can be empty. In this example, if the OSoL string had been empty the status of all jobs kept in the file ospl.xml is reported. In our default solver service implementation, there is a configuration file OSParameter that has a parameter MAXFJOBIDSFTOFKEEP . The current default setting is 100. In a large-scale or commercial implementation it might be wise to keep problem results and statistics in a database. Also, there are values other than getAll (i.e. get all process information related to the jobs) for the OSpL action attribute in the <request> tag. For example, the action can be set to a value of ping if the user just wants to check if the remote solver service is up and running. For details, check the OSpL schema.


next up previous contents
Next: The kill Service Method Up: Solving Problems Remotely with Previous: The getJobID Service Method   Contents
Kipp Martin 2008-01-16