Changes between Initial Version and Version 1 of PjotrAsync

Show
Ignore:
Timestamp:
2008/02/12 14:32:06 (11 years ago)
Author:
pjotr2007
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • PjotrAsync

    v1 v1  
     1== Aynchronous Communications == 
     2 
     3AC 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 
     7Typically, 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 
     9The webservice author will want a clean API which allows job submission and passing the feedback mechanism. 
     10 
     11=== Minimal Specification === 
     12 
     13A only job of the AC is to provide the messaging service between client and job.  
     14 
     15What 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 
     24What 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 
     30In 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