Changes between Version 2 and Version 3 of PjotrAsync

Show
Ignore:
Timestamp:
2008/02/12 15:13:13 (10 years ago)
Author:
pjotr2007
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • PjotrAsync

    v2 v3  
    55=== Typical use case === 
    66 
    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. 
     7Typically 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. 
    88 
    9 The webservice author will want a clean API which allows job submission and passing the feedback mechanism. 
     9The webservice author will want a clean API which allows job submission and passing the feedback mechanism in the simplest way possible. 
    1010 
    1111=== Minimal Specification === 
     
    3939 
    4040  * 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 
    4142  * 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: 
    4243 
     
    5253  acjob -t poll "dbfetch URI:gb -t fasta|clustalw"|acpoll -i 180|phyloanalyse > tree.ph 
    5354 
    54 where acpoll polls the jobmonitor every 3 minutes for results. 
     55where acpoll polls the jobmonitor every 3 minutes for results (SOAP is one option). acpoll would also allow a later 'progress monitor' implementation. 
    5556 
     57The 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. 
    5658 
    57  
    58  
    59  
    60  
    61  
    62  
    63  
     59Pjotr Prins