This project is read-only.

Webservice Framework

Apr 23, 2014 at 6:12 PM
For those of you who have followed .NET Bio's development over the past few years, you may recall that one of the principal pieces of functionality was the web services framework - an easy to use way of adding connectors to webservices so that they could be simply and robustly called from any application written using .NET Bio, greatly increasing the range of functions available to the bioinformaticians using the Windows technology stack.

This was implemented, and ever since .NET Bio has shipped with an easy to extend framework and three sample webservice connections - which are I believe all connecting to different instances of BLAST. In retrospect, we should have shipped with more choices and this no doubt is partly responsible for a lack of interest in this feature - but also the framework is nowhere near as easy to use as it should be.

These are our motivations for revisiting the web service framework in the upcoming release - but here's my question to the community:

How much effort should we put into this? We will do an overhaul, but won't invest much time if this isn't a feature people are interested in using.

If you have a strong opinion, please post a response here - it will affect how we allocate resources.

Thanks,

Simon
Jun 16, 2014 at 11:39 PM
We made the decision to continue supporting a web framework, but it will ship as a separate Nuget package (NetBioWeb) with a dependency against the Core.

Since each service is so different in terms of the inputs and outputs, I don't think it makes a lot of sense to try to abstract commonality - there just isn't much there! So, we'll start with BLAST which is the old standard. We will be supporting the REST version of the NCBI model (we did SOAP before, but it's heavy, slow and not really that modern). Here's the new interface:
public interface IBlastWebHandler
{
   string EndPoint { get; set; }
   Action<string> LogOutput { get; set; }
   int TimeoutInSeconds { get; set; }
   
   Task<Stream> ExecuteAsync(BlastRequestParameters bp, CancellationToken token);
}
Notice it is asynchronous (returning a task), this allows you to use the new C# 5 async/await keywords to work with it, but still allow for high-performance and non-blocking operations. You can pass a CancellationToken in to cancel the task if you get tired of waiting. We will probably remove the explicit Timeout property since you can get the same effect with CancellationToken. The LogOutput property allows you to receive periodic text updates as the request is processed.

We'll use a similar approach for ClustalW and these will probably be the two models we support out of the box - but you can add more, of course.
Jun 19, 2014 at 3:05 PM
This seems a very sane compromise. Clustal omega is possibly the most obvious next example, but the grab genome from genbank and parse it sounds a good example and recipe. I have genomes on a local store and parse but the direct grab is popular in some environments.