The tool is generic. This means that it is supposed to work (and does work) 
with any WSDL. In the described use case, one of the operations/“generated 
tools" already serves as a polling tool: it takes a unique id and requests a 
result from the web service, then the web service either returns the results or 
returns a message indicating that the results are not ready. Conditionals/Loops 
would be a perfect way to solve this.

If we added a polling tool like you described, then that tool would need to Web 
service specific since not all web service adhere to the same naming 
conventions and level of asynchrony.  

Michael E. Cotterell

Ph.D. Student in Computer Science, University of Georgia
Instructor of Record, Graduate RA & TA, University of Georgia
Department Liaison, CS Graduate Student Association, University of Georgia ( ( (

On Thursday, March 6, 2014 at 9:17 AM, Peter Cock wrote:

> On Thu, Mar 6, 2014 at 2:12 PM, Michael E. Cotterell
> < (> wrote:
> > While I agree that would work, the tool I'm working with generates
> > tools for web operations in a generic fashion. That is, you provide
> > it a WDSL and a list of operations you want from that WSDL, and
> > then tool XML files are generated for each of those operations.
> So could your "WDSL Galaxy Tool Factory" also produce a wrapper
> script to go with the Galaxy Tool XML, where the wrapper script
> handles polling the service with the unique identifier assigned by
> the service?
> Peter  

Please keep all replies on the list by using "reply all"
in your mail client.  To manage your subscriptions to this
and other Galaxy lists, please use the interface at:

To search Galaxy mailing lists use the unified search at:

Reply via email to