Regarding using timeouts: I recommend using deadlines established at the initiation of a workflow instead of timeouts. This allows all collaborations to be co

Regarding using timeouts: I recommend using deadlines established at the initiation of a workflow instead of timeouts. This allows all collaborations to be constrained instead of having the additive effect of multiple discrete timeouts. For example, specifying: Customer login must complete within 10 seconds of initiation. Is preferable to: Read customer record within 5 seconds. Verify passphrase within 1 second. Update account access within 5 seconds. Generate response within 2 seconds. Note that the cumulative seconds in the second example exceed the 10 second threshold of the first. This is intentional as it exemplifies the very common situation of "this should never take longer than X" timeout specifications resulting in potentially violating the system response constraints. It is also indicative of developers having to pick what is considered reasonable maximums within a workflow due to not having context. By providing a deadline downstream, those components need only be concerned with the question "do I have any time left to do what I need to do?" For an example of both deadline and timeout types, see: http://www.scala-lang.org/api/current/#scala.concurrent.duration.Deadline http://www.scala-lang.org/api/current/#scala.concurrent.dura... http://www.scala-lang.org/api/current/#scala.concurrent.duration.Duration http://www.scala-lang.org/api/current/#scala.concurrent.dura...