Taverna 2

Loop layer: document pattern for asynchronous services

Details

  • Type: Story Story
  • Status: Reopened Reopened
  • Priority: Critical Critical
  • Resolution: Unresolved
  • Affects Version/s: 2.1 RC 1
  • Fix Version/s: Post 2.4.0
  • Component/s: Documentation - General
  • Labels:
    None
  • Familiarity:
    Similar

Description

Asynchronous services in T1 need to be polled using a nested workflow containing the 'fail if false' local worker in order to execute them. This will not work in T2, so we need to specify the despatch stack pattern to replicate this behaviour when translating T1 workflows or when creating new T2 workflows with asynchronous services

Solution:
Add documentation on how to use the Loop layer to use asynchronous services.

Test:
Test the documentation on a real user together with an asynchronous EBI service.

Issue Links

Duplicate

Activity

Ascending order - Click to sort in descending order
Hide
Permalink
Stian Soiland-Reyes added a comment - 2008-07-25 15:24

This can be done by doing a dispatch stack layer similar to "failover" that retries the 1st activity until the 2nd activity returns "true" on the "shouldContinue" output port or similar.

The 1st activity would then be a nested workflow to be repeated, the second a beanshell script or another nested workflow (that could invoke the services that checks if the job is finished).

However that would be a solution that is more suitable for "continue doing something until condition X" - for the issue described by this bug it's more a matter of just waiting and checking the status before returning by getting the results. Typically the:

submitJob() -> jobID
while(! checkStatus(jobID).equals("FINISHED")) { 
   Thread.sleep(500);
}
return getOutput(jobID);
  • but it would have to cope with other kind of states and outcomes as well - such as "Failed" or the whole thing just taking too long (timing out).
Show
Stian Soiland-Reyes added a comment - 2008-07-25 15:24 This can be done by doing a dispatch stack layer similar to "failover" that retries the 1st activity until the 2nd activity returns "true" on the "shouldContinue" output port or similar. The 1st activity would then be a nested workflow to be repeated, the second a beanshell script or another nested workflow (that could invoke the services that checks if the job is finished). However that would be a solution that is more suitable for "continue doing something until condition X" - for the issue described by this bug it's more a matter of just waiting and checking the status before returning by getting the results. Typically the: 
submitJob() -> jobID
while(! checkStatus(jobID).equals("FINISHED")) { 
   Thread.sleep(500);
}
return getOutput(jobID);
  • but it would have to cope with other kind of states and outcomes as well - such as "Failed" or the whole thing just taking too long (timing out).
Hide
Permalink
Stuart Owen added a comment - 2008-11-13 12:45

This workflow might be useful for testing http://www.myexperiment.org/workflows/148

Show
Stuart Owen added a comment - 2008-11-13 12:45 This workflow might be useful for testing http://www.myexperiment.org/workflows/148
Hide
Permalink
Stian Soiland-Reyes added a comment - 2009-02-17 09:09

Reopened, as this issue is about DOCUMENTING the pattern - not implementing it.

Show
Stian Soiland-Reyes added a comment - 2009-02-17 09:09 Reopened, as this issue is about DOCUMENTING the pattern - not implementing it.
Hide
Permalink
Alan Williams added a comment - 2009-09-11 15:04

Very important but not essential

Show
Alan Williams added a comment - 2009-09-11 15:04 Very important but not essential

People

Vote (0)
Watch (0)

Dates

  • Created:
    2008-04-14 16:23
    Updated:
    2010-09-10 17:59

Time Tracking

Estimated:
1w
Original Estimate - 1 week
Remaining:
1w
Remaining Estimate - 1 week
Logged:
Not Specified
Time Spent - Not Specified
Atlassian JIRA (v4.2.2-b589#589) | Report a problem
Powered by a free Atlassian JIRA open source license for myGrid. Try JIRA - bug tracking software for your team.