[MOBY-dev] RFC #1941 Asynchronous Service Call Proposal

Tue Feb 7 13:25:02 UTC 2006

Hi all,

On 6-Feb-2006, at 8:32 PM, Robert Buels wrote:

> About Martin's main comments:
>
> 1. I agree with Martin that it's probably not necessary to introduce a
> new mobyStatus tag for asynchronous services.  I also think that new
> data types would serve just fine.

I agree too. But there is a catch. If we use "normal" BioMOBY objects  
to signal the status of a async queryID, it is more likely that  
people will start to invent other, new, maybe derived objects for  
similar things. Since anyone can register new objects, this makes the  
asynchronous service behaviour evolve faster, but it might also mean  
a less stable interface. Putting the additional info for asynchronous  
behaviour outside the mobyData blocks (hence in the proposed  
mobyStatus block) makes sure that it requires a well written RFC  
(many thanks for that to the INB people). Getting an RFC accepted  
takes much more time compared to registering a new object, but it  
also makes the interface more stable.

> 3.  I kind of think the 'mixed' mode should be allowed.  (Mark also
> referred to this in his comment number 4).  The way I see it,
> implementation of the service is going to have to be keeping separate
> state for each job (regardless of how they're divided among
> invocations), so I don't think it would make implementation easier to
> impose that the grouping of jobs into invocations always has to remain
> the same.

I agree again.

>
> About Martin's smaller comments:
> a.) isn't Johan also using the term 'job' to refer to a particular  
> block
> of mobyData input and the results that arise therefrom?  Maybe I'm
> missing something, but I don't understand Martin's distinction here.
> b.) I agree, the wording should be changed there.  Making the  
> identifier
> unique to the service provider is also critical for supporting  
> mixed mode.

Agree for both a and b.

> c.) "....can clean the session....":  This seems a little dangerous.
> What if there's some kind of interruption of network connectivity and
> the client fails to get the whole result, but the server thinks the
> whole result was sent?  That scenario could lead to total loss of the
> results if _result is a cleaning call.  I think a better way would  
> be to
> say that results are valid for X number of hours after the _async  
> call,
> and have a cron job or equivalent go through cleaning them up
> periodically on the server.  Until the job state is deleted, the  
> client
> should be able to call _result as many times as it wants.

I agree with Rob here. I think it is much better to have an  
additional xxx_clean or something similar. If a client wants to make  
sure his data is no longer on the server they can always call  
xxx_result and immediately after that a xxx_clean. It's just one  
additional line of code client-side. Server-side it is also not that  
much work to implement. Just move the cleaning code to an additional  
sub that translates into an additional SOAP method

> d.) I agree we should more rigorously define in the RFC the exception
> codes to be used with async services.

I agree.

> Now for some of my own comments:
>
> A.  I think it would be a bit cleaner, rather than defining 3 separate
> services with patterns to their names, to define asynchronicity in  
> terms
> of a single service that accepts the type of request you're making as
> part of its input XML.  Building on Martin's idea, perhaps we could  
> have
> a set of datatypes just for asynchronous services called, for example,
> AsyncJobID (ISA String), AsyncNewRequest, AsyncPollRequest (HASA
> AsyncJobID), and AsyncResultRequest (HASA AsyncJobID).  Upon  
> invocation,
> if no AsyncXXXRequest is present as a Primary article (inside a  
> Simple)
> in the inputs, then the request is treated as synchronous.  This  
> scheme
> would preserve backward compatibility for calling things in a
> synchronous style, while also doing away with the complexity of  
> having 4
> service names (1 for synchronous, 3 for asynchronous) for what is  
> really
> a single service.

Currently the object ontology lists only what goes into a service and  
what comes out of it. Details about where the service resides and how  
to access it currently go into the service ontology. Therefore it  
makes more sense to me to put the info about (a)synchronous behaviour  
in the service ontology.

>
> OK, end avalanche.  I'm really glad this asynchronous discussion is
> happening, because I was about to implement my own hacked-together
> asynchronous protocol.  Much better to have a real interoperable
> consensus.  :-)

I second that!

Pi

> What do you all think about my suggestion to choose synchronicity  
> based
> on what data is in the input?
>
> Rob
>
> -- 
> Robert Buels
> SGN Bioinformatics Analyst
> 252A Emerson Hall, Cornell University
> Ithaca, NY  14853
> Tel: 607-255-2360
> rmb32 at cornell.edu
> http://www.sgn.cornell.edu
>
>
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://biomoby.org/mailman/listinfo/moby-dev

Wageningen University and Research centre (WUR)
Laboratory of Bioinformatics
Transitorium (building 312) room 1034
Dreijenlaan 3
6703 HA Wageningen
The Netherlands
phone: 0317-483 060
fax: 0317-483 584
mobile: 06-143 66 783
pieter.neerincx at wur.nl