| | 1 | == Aynchronous Communications == |
| | 2 | |
| | 3 | AC has many possible implementations and the main danger is to overcomplicate a solution (trying to facilitate all wishes and real user requirements). |
| | 4 | |
| | 5 | === Typical use case === |
| | 6 | |
| | 7 | Typically, now, a user creates a webservice (HTTP) and needs a way of executing a job that may take longer than the time a browser times out (think of BLAST). Potentially the job can take a month to run and both the client, server and network may be occasionaly down. Finally the user gets the output from the job - with output on success, error on failure. |
| | 8 | |
| | 9 | The webservice author will want a clean API which allows job submission and passing the feedback mechanism. |
| | 10 | |
| | 11 | === Minimal Specification === |
| | 12 | |
| | 13 | A only job of the AC is to provide the messaging service between client and job. |
| | 14 | |
| | 15 | What it should do: |
| | 16 | |
| | 17 | * Receive info from web-service (jobreceiver) |
| | 18 | * Start remote job on cluster (jobmonitor) |
| | 19 | * Pipe input data to job (jobmonitor) |
| | 20 | * Monitor job status (on failure perhaps restart) |
| | 21 | * Get output (jobmonitor) |
| | 22 | * Push output to client (jobsender) |
| | 23 | |
| | 24 | What it should *not* do: |
| | 25 | |
| | 26 | * Authentication/authorisation (is responsibility of the webservice) |
| | 27 | * Filtering of data (modifying the stream) is responsibility of webservice) |
| | 28 | * Job control (handled by cluster tools) |
| | 29 | |
| | 30 | In its minimalistic fashio it does not even handle status reports (i.e. percentage of job executed). |
| | 31 | |
| | 32 | === API === |
| | 33 | |
| | 34 | * jobreceiver may be able to receive jobs through SOAP, a pipe, or mail |
| | 35 | * jobmonitor may be able to give updates on percentage executed (SOAP, RPC) |
| | 36 | * jobsender may be able to return results through SOAP, pipe or mail |
| | 37 | |
| | 38 | === Notes === |
| | 39 | |
| | 40 | * The jobmonitor has to be stateful as the server or node running the job may go down |
| | 41 | * Piping is an incredible useful mechanism. The complication with webservices is the asynchronous nature (while the web protocol tends to by synchronous) - inspiration could be modglue (a Plan9-inspired extension of the Unix pipe concept). |
| | 42 | |
| | 43 | |
| | 44 | |
| | 45 | |
