| | 1 | = Asynchronous Web Service Invocation = |
| | 2 | |
| | 3 | Web service transactions can potentially be very long-running, exceeding the time-out thresholds of intermediate communication transports such as HTTP. To overcome this, it is necessary to use an asynchronous invocation model, where a single logical transaction is implemented as multiple, short-lived transport-level transactions. |
| | 4 | |
| | 5 | This group is investigating the requirements in the domain of bioinformatics services for asynchronous invocations, current solutions and current best practice. It will seek to propose what functionality a service claiming to support asynchronous invocation MUST expose, and will, where possible, describe language-specific bindings best-practice for clients to invoke logical transactions implemented asynchronously. |
| | 6 | |
| | 7 | == Guiding Principles == |
| | 8 | |
| | 9 | * We shall identify the scope of this recommendations. |
| | 10 | ** What kinds of applications |
| | 11 | ** The environment(s) within which servers are provided |
| | 12 | ** The environment(s) within which clients are provided |
| | 13 | * The recommendations produced SHOULD be as simple as possible. |
| | 14 | * The recommendations SHOULD re-use existing standards and language-bindings where possible. |
| | 15 | |
| | 16 | == Outcomes == |
| | 17 | |
| | 18 | We WILL produce a document describing the scope, requirements, and brief survey of asynchronous service interaction. It will additionally make recommendations about technologies and best-practice. We SHALL discuss with service providers how practical it is for them to adopt these recommendations. We SHALL ensure that these recommendations are practical and useful for those maintaining workflow/pipeline/orchestration applications. |
| | 19 | |
| | 20 | == Progress == |
| | 21 | |
| | 22 | * day 1 |
