Changes between Version 1 and Version 2 of PjotrAsync

Timestamp:

2008/02/12 15:06:46 (17 years ago)

Author:

pjotr2007

Comment:

--

PjotrAsync

@@ -1 @@
-== Aynchronous Communications ==
+== Aynchronous Communications (Pjotr) ==
 
 AC has many possible implementations and the main danger is to overcomplicate a solution (trying to facilitate all wishes and real user requirements).
@@ -15 +15 @@
 What it should do:
 
-* Receive info from web-service (jobreceiver)
-* Start remote job on cluster (jobmonitor)
-* Pipe input data to job (jobmonitor)
-* Monitor job status (on failure perhaps restart) 
-* Get output (jobmonitor)
-* Push output to client (jobsender)
+  * Receive info from web-service (jobreceiver)
+  * Start remote job on cluster (jobmonitor)
+  * Pipe input data to job (jobmonitor)
+  * Monitor job status (on failure perhaps restart) 
+  * Get output (jobmonitor)
+  * Push output to client (jobsender)
 
 What it should *not* do:
 
-* Authentication/authorisation (is responsibility of the webservice)
-* Filtering of data (modifying the stream) is responsibility of webservice)
-* Job control (handled by cluster tools)
+  * Authentication/authorisation (is responsibility of the webservice)
+  * Filtering of data (modifying the stream) is responsibility of webservice)
+  * Job control (handled by cluster tools)
 
-In its minimalistic fashio it does not even handle status reports (i.e. percentage of job executed).
+In its minimalistic fashion it does not even handle status reports (i.e. percentage of job executed).
 
 === API ===
 
-* jobreceiver may be able to receive jobs through SOAP, a pipe, or mail
-* jobmonitor may be able to give updates on percentage executed (SOAP, RPC)
-* jobsender may be able to return results through SOAP, pipe or mail
+  * jobreceiver may be able to receive jobs through SOAP, a pipe, or mail
+  * jobmonitor may be able to give updates on percentage executed (SOAP, RPC)
+  * jobsender may be able to return results through SOAP, pipe or mail
 
 === Notes ===
 
-* The jobmonitor has to be stateful as the server or node running the job may go down
-* 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).
+  * The jobmonitor has to be stateful as the server or node running the job may go down
+  * 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:
+
+  acjob -t pipe "dbfetch URI:gb -t fasta|clustalw"|phyloanalyse > tree.ph
+
+where dbfetch and clustalw run on the cluster and phyloanalyse locally - just as an example. Obviously with pipes you expect the client to keep running uninterrupted. The AC version could be (simplistically):
+
+  acjob -t email me@waste.com "dbfetch URI:gb -t fasta|clustalw"
+  cat email|phyloanalyse > tree.ph
+
+or:
+
+  acjob -t poll "dbfetch URI:gb -t fasta|clustalw"|acpoll -i 180|phyloanalyse > tree.ph
+
+where acpoll polls the jobmonitor every 3 minutes for results.
 
 
 
 
+
+
+
+
+