[MOBY-dev] RFC #1941 Asynchronous Service Call Proposal
Tom Oinn
tmo at ebi.ac.uk
Tue Feb 7 14:05:42 UTC 2006
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
More information about the MOBY-dev
mailing list