[moby] [MOBY-dev] Re: Problems with Biomoby services in Taverna 1.2

[Tom Oinn]

Heiko Schoof wrote:

> If I understand Tom correctly, the problem mainly appeared because the 
> BioMoby support was rapidly and effectively incorporated into Taverna 
> without proper integration, and what needs to happen is to define e.g. 
> the iteration strategy for BioMoby: Taverna so far doesn't use the 
> possibility to bundle multiple queries in a single BioMoby message, 
> which is not a problem, but the Collection issue could point to a need 
> for us BioMoby guys to look in more detail at Taverna data types and do 
> a sound mapping.
> Heiko

That's kind of true, meaning actually not. There are three cases 
involving collections (Taverna 1.1 behaviour) :

1) Consumer declares it consumes singles, Producer emits a collection. 
In this context Taverna iteratively calls the Consumer with each item 
from the collection. This is probably what you'd expect to happen, the 
result is that the Consumer effectively emits a collection of whatever 
it would emit normally.

2) Consumer declares it consumes a collection, Producer emits a 
collection. In this case Taverna will indeed split the output collection 
(because we always do) but it will be magically reassembled before being 
given to the Consumer.

3) Consumer declares it consumes a collection, Producer emits a single 
item. Taverna wraps the single item in a single element collection and 
gives it to the Consumer.

The intent is that as with the other plugin types Taverna guarantees 
that the service sees the inputs it has asked for. Our experience with 
other service types suggests that this is an extremely powerful 
mechanism as it allows interoperability between services that would 
otherwise mismatch - it's worth noting that our users expect these 
services to match, while a CS perspective regards ProteinSequence and 
ProteinSequence[] as completely different types most of our biologists 
don't! Taverna behaves the way _they_ expect it to, remember who your 
user are.

Taverna data types are pretty much trivial, they're opaque data blobs 
with the exception of collection structure which is exposed. We only 
expose the collection structure to ensure the above properties, other 
than that the framework is data agnostic (as it should be).

Tom