[MOBY-dev] [moby] Moby services in Python

[Paul Gordon]

I have always been a champion of the multiple invocations requirement, 
and still am, for several reasons:

0. First we must acknowledge that people will want to run a bunch of 
data against a service.  I do already, and many Taverna workflows do to 
(implicit iterators).

1. Some services may use hardware accelerator, which can perform 100 
jobs as quick as 1 if they are submitted together.

2. If you have a cluster running the service, it is much easier to 
schedule 100 jobs efficiently than to receive 100 individual requests 
over the course of a few seconds.  i.e. division of labour is much 
easier when you know in advance how much there is to do!

3. If your server is running 1 CPU, you can decide to run the 100 jobs 
sequentially, at the pace you like (especially if you have many requests 
coming in from different users at the same time).  If the 100 jobs are 
submitted separately, it is the client (e.g. Taverna) that decides how 
much breathing room you have.  Encouraging 
multiple-invocations-in-one-envelope may reduce inadvertent 
denial-of-service attacks.

4. The network and computational overhead is much smaller for 1 large 
request than 100 small ones: 1 SOAP envelope vs. 100, 1 servlet 
invocation vs. 100, etc.

5. It's not hard to implement!  All you really need to do is add a for 
loop to the service code... MobyServlet 
(http://biomoby.open-bio.org/CVS_CONTENT/moby-live/Java/docs/deployingServices.html) 
supports multiple invocations implicitly, I don't even really tell the 
developer about it: their processRequest() method gets called for each 
mobyData block.

My CAD 0.02,

Paul
>> Is it mandatory for a service to implement the multiple invocations
>> funcionality?
>>     
>
>
> well.... It *may* be that the people working on the error-handling and
> error-codes have reserved an error code for providers who do not WANT to
> handle multiple invocations in a single message, but I don't think so...
>
> I think it is mandatory at the moment.
>
> M
>
>
>
>