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

[Martin Senger]

Nice to have your answer. Thanks for helping this RFC!

> 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.
>
   That's good. Johan and Mark, would you in principle agree, so that I
can suggest the datatypes I was talking about (based on LSAE) and send it
here?

> 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
>
   Yes, that's correct. I have been thinking in the same line. But this
"go ahead and try" approach would work only for clients, not for registry
when a registry needs to create a WSDL with all methods, sometimes 
including xxx_async, somethimes not. For that, you cannot expect that a
registry will go and check LSID metadata.
   So I guess that using LSID metadata for that is simply not possible
(unless registry caches them  but then why not to keep them in a regular
way as any other other registered attributes; or unless gnerated WSDL is
crippled even more than it is now).

> 3.  I kind of think the 'mixed' mode should be allowed.
>
   I am afraid that I have not stressed enough how important is *not* to
use the mixed mode. Because if we do so, we cannot use xxx_result as a
cleaning method (see more about cleaning below), we would need to have
another method, such as xxx_clean.
   Also, why to make things complicated when they do not need to
be? Simply speaking, if a client is willing to get results one by one, it
can also call the service one by one (and not as a several jobs in one
request).
   Summary why I do not support mixed mode: Just making it simple as much
as possible, and not to need a special cleaning method.

> a.) isn't Johan also using the term 'job' to refer to a particular block 
> of mobyData input and the results that arise therefrom?
>
   No. Johan is using 'job' for one request (which can have more mobyData
parts). Once you call xxx_async, the whole such request is identified by a
'job identifier'. I would call it rather 'session' and 'session
identifier'. The reason I gave (that jMoby uses term 'job' for individual
'mobyData' parts) is minor. But if we accept to have normal moby data type
returning from xxx_async (and others used in xxx_poll) we will re-use
these data types also for other things (I mentioned iterator pattern for
sending/getting data in chunks) where is much better to talk about
sessions than job I think.

> c.) "....can clean the session....":  This seems a little dangerous.  
>
   I slightly disagree. Any good API/interface to a session management
(which in our case is represented by the async API we are trying to
establish) should have a way how to clean up, how to say "close the
session". Of course, an implementation cannot rely that clients will
always behave well and clean up - but the API should have this option (for
example for cases when client want to ask for the same service thousand
times in a short time).
   If the call to xxx_result fails, it fails, and you have nothing, and
you have to start again. This is the sa,e as now with sync services. If
you want to allow to get results several times, then we need to add
xxx_clean method. But allowing to get results several times adds new
features, beyond the simply async call. I thought that we wanted to kep it
simple, so why to introduce new features when nobody asks for them
explicitly? (Not that I do not see also advantages of allowing to call
xxx_result more than once: you can use it - for example and if the service
supports it - for getting partial result and display them to
clients.... But so far nobody asked for such feature. Do we want it?)

> 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.
>
   But that's exactly what the proposal is saying. It will be oly one
service, but it will have more than one method (and a 'method' in web
services speak is a 'type of request').

> 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).
>
   These are fine, except AsyncResultRequest...

> 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 would mean that a service behaviour is totally different
depending on input data. Also, how would you send the real input data?
   To be honest, I do not understand fully what you meant here...
   But I think that INB suggestion that the initial input and the
resulting output are exactly the same bothy for sync and async is very
good and valuable, and guarantees backaward compatibility. So I do not see
here any need to suggest anything else :-)

   Cheers,
   Martin

-- 
Martin Senger
   email: martin.senger at gmail.com
   skype: martinsenger
consulting for:
   International Rice Research Institute
   Biometrics and Bioinformatics Unit
   DAPO BOX 7777, Metro Manila
   Philippines, phone: +63-2-580-5600 (ext.2324)