Changes between Version 2 and Version 3 of PjotrAsync
- Timestamp:
- 2008/02/12 15:13:13 (16 years ago)
Legend:
- Unmodified
- Added
- Removed
- Modified
-
PjotrAsync
v2 v3 5 5 === Typical use case === 6 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.7 Typically 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 8 9 The webservice author will want a clean API which allows job submission and passing the feedback mechanism .9 The webservice author will want a clean API which allows job submission and passing the feedback mechanism in the simplest way possible. 10 10 11 11 === Minimal Specification === … … 39 39 40 40 * The jobmonitor has to be stateful as the server or node running the job may go down 41 * The jobmonitor is a little complicated as it has to allow for multiple types of (cluster) management tools 41 42 * Piping is an incredibly useful mechanism. The complication with webservices is the asynchronous nature (while the web protocol tends to by synchronous) - inspiration could be [http://www.aei.mpg.de/~peekas/modglue/ modglue] (a Plan9-inspired extension of the Unix pipe concept). What I would like to do is: 42 43 … … 52 53 acjob -t poll "dbfetch URI:gb -t fasta|clustalw"|acpoll -i 180|phyloanalyse > tree.ph 53 54 54 where acpoll polls the jobmonitor every 3 minutes for results .55 where acpoll polls the jobmonitor every 3 minutes for results (SOAP is one option). acpoll would also allow a later 'progress monitor' implementation. 55 56 57 The nice thing about these piping mechanisms is that it shows clearly the minimal requirement for an implementation. Things like distributing services (multiple pipes) get resolved by the tools that are called by acmonitor. I.e. it is not a functionality for the jobmonitor itself. 56 58 57 58 59 60 61 62 63 59 Pjotr Prins
