[MOBY-dev] RFC - Asynchronous Service Call Proposal

[Martin Senger]

RFC #1941 Asynchronous Service Call Proposal
============================================

I agree with Mark that it is a good proposal - we desperately need
it. I just hope that more people will join this discussion (please, do
so!). I suggest that we postpone the voting for about two more
weeks. Mainly because some of my comments (see below) would require
more details to be put in the document. And also to allow other people
to jump the board (please, do so!).

Before I start, let me express my main principle: we are going to
change the Biomoby API because of a need for async services. But we
are (sooner or later) going to add other new things to the API
(especially we need to address in the future the 'iterator' pattern -
sending data by chunks) - all these changes have the same common root
- they require some session management. So we should add them in a way
that is the least disruptive to the existing software, and in a
similar way. That's one of my reasons for my 'major' comments.

I have few smaller comments - but let me start with the significant
ones:

* Data returned by xxx_async and xxx_poll
-----------------------------------------

Why does the proposal treat them differently (comparing to normal
Biomoby data)? Why to introduced a new XML element 'mobyStatus' when
we can easily - and keeping many software untouched - send these data
in usual 'mobyData' element?

The Biomoby data types (objects) have two functions: they are used to
carry data and they are used in service discovery. Obviously the
second function is no use here but the first function still can be
used.

And we do not need any new XML element (now it is 'mobyStatus', later
we will need perhaps 'mobySession' or moreand more new tags).

What I am suggesting is this:

* To create several regular Biomoby data types (objects), such as:
  - PollingRequest
  - Event (with hierarchy and attributes taken from LSAE)
  (the contents would be the same as 'mobyStatus' proposed)

I am prepared to be more specific how these objects should look like,
and write it into a document (or even register them in Biomoby
registry) - but before doing it I need some confirmation from you that
it is the way to go.

These objects will probably never be used in the service registration
(but they can - see below). They should be treated in the similar way
as the primitive data types - so in any newly created biomoby registry
they should be registered by the installation script (or whatever is
done for primitive types now).

As a side effect, these data types *can* be used for normal services -
if a service have use for them.

Having these data types as regular biomoby objects also allows easier
to create WSDL for all these new methods (Mark, these new methods
should be generated in the WSDL by registry, for asynchronous
services; more about it later.)

* Dependency on LSID service metadata
-------------------------------------

I do not like it (the RDF predicate indicating that a service can be
asynchronous). Here is why:

For me, the divider between service data and service metadata was
always that metadata are good but are not crucial for a service
execution. But the flag "this service can be called asynchronously" is
very fundamental flag for a service, and it changes its behaviour and
the behaviour of its clients. Also, it must be known to a registry -
because registry is supposed to generate WSDL with xxx_async and
xxx-poll method included. So register should have it, anyway!

But in the same time, I agree with Mark that we should add changes to
the current API prudently. But still, this request qualifies for a
change of the Biomoby API (I think).

But perhaps the change does not need to be big: What about to use the
existing field 'category'. Because we are, in fact, talking about a
new type of service category. Why not to allow a new category, for
example, 'moby-async'?

* Do not allow the 'mixed' mode
-------------------------------

...where some mobyData can be returned before other mobyData (from the
same invocation). This would much complicate implementation - and for
what? I was told that the main reason for having more mobyData in an
invocation is mainly because some hardware can treat them more
efficiently. I wonder if such hardware would give you back partial
result, anyway.

So please consider the implementation, and make it easier for us,
developers.

So my suggestion would be: one request == one xxx_result.

* And here are my other, but smaller, comments
----------------------------------------------

a) Please whenever you talk about 'job', talk rather about 'session'
   because in jMoby we use the term 'job' for individual 'mobyData' -
   so the term would be too overloaded.

b) "Id unique to each... in a message". No, the Id must be unique to
   the whole service provider (at least to the invoked service). If
   the unique-ness is just in a message there would be problems when I
   invoke the same service several times before the first one
   finished.

c) How many times am I allowed to call xxx_result? I suggest just once
   - and any next invocation fails with an exception. This means that
   this call also serve as a cleaning call - the service
   implementation can clean the session.

c) More must be written about exception states: What (if any)
   exception to raise when a given session handler is
   invalid/expired. There may be other states to document by an
   exception code.



   I think that this is enough for now. Again, I thank very much INB
for the proposal, and please give us slightly more time to discuss and
make changes. Then we need a new document, and few days to read it
again.

   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)