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

[Tom Oinn]

Martin Senger wrote:
>>> 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.
>>
>    Welcome on the board :-)
> 
>> 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.
>>
>    Not sure why this is a catch. This is an advantage: I can return much
> more detailed status if I want, and if I use a more specialized event
> object. But regarding the new API (if approved), all such event objects
> must inherit from the one defined in the API. As usual...

This sounds messy to me - I know I haven't been involved up to now and 
to be honest don't have time to now (I'm only sending this because I'm 
on holiday!). Isn't there a risk that you're getting properties of the 
service mechanism confused with those of the underlying service function?

When you describe a service as 'asynchronous' you really mean that a 
service invocation has persistent state on the server to which the 
client must reconnect, making more than one call at the low level to 
invoke the high level service, right?

Every time a 'magic' moby object type is used the client tooling becomes 
more complicated. Any invocation framework is going to have to have 
special catch clauses to handle this magic type, even if the client is 
otherwise entirely agnostic to the data returned from the service. This 
is a bad thing. I don't think this message belongs in the standard moby 
object space, it is a property of the service invocation semantics in 
the same way as the inherent moby wrapper is at one level and that the 
low level SOAP wrapper is at another, I would avoid mingling it with the 
data layer.

Just my two cents, I'd suggest a look at frameworks such as WSRF which 
handle state explicitly (WSRF being derived from the state model in 
Globus 2, loosely, but applied to web services), and at the least I'd 
like to see a document explaining why these relatively standard 
technologies aren't being applied here. If I were a reviewer on one of 
Mark's grants (hypothetically, they asked me but I had to reject on 
conflict of interest grounds) I'd want to see this comparison.

Cheers,

Tom