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

[Robert Buels]

Hi all,

I've been lurking on this list for a while, but I haven't said 
anything.  However, right now I'm looking at ways to implement a new 
BLAST service for SGN, where I work, so I'm watching this async thing 
developing with great interest, and I've got a few comments.

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.

2. As for Martin's concern with the dependency on LSID service metadata, 
this is mitigated by  the paragraph near the bottom of page 5 of Johan's 
proposal, which specifies that asynchronous services must also be able 
to be called synchronously.  So clients can always just plod ahead and 
call the service synchronously, but if they're smart and can check the 
metadata, they could discover that they can call asynchronously also.  I 
don't really understand the service categories he's talking about 
though, so I can't speak to that.

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.

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.
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.
d.) I agree we should more rigorously define in the RFC the exception 
codes to be used with async services.

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.


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.  :-)

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