[Biojava-l] Webservices clients in bio-java

[James Procter]

Hi Mark, and Scooter.

Mark Schreiber wrote:
> By high level API I mean anything not machine generated. That could be
> classes that use biojava objects or a more humanized or smarter
> interface to the boilerplate code.

ah. yes. that's what I thought. I'd really advocate keeping the Biojava
object adaptor glue for the autogenerated code separate from the core.
This is because (as I'm sure you know) there are no real object design
standards for bioinformatic services (apart from BioMOBY..) - so the
adaptor code is always going to be specific to the WSDL.

Scooter Willis wrote:
> I agree. I am planning on doing some testing of  a couple BLAST web
> services interfaces(assuming more than one exists) and see what they
> truly have in common and see how that would impact a BJ3 front end to
> multiple providers. My assumption is that they will be the same.
Of course, the actual functionality provided by all the servers will be
more or less the same (i.e. inputs and outputs), but servers will differ
in how they wrap the input and result data, how they support parameters,
and how they deal with polling and result retrieval (if they are at all
asynchronous).

 I
> noticed on the NCBI Blast implementations the user was required to pass
> their email address as part of the web service call. They are concerned
> with abuse from external processes and they only allow one sequence per
> request.
Yes. The NCBI has an automatic blacklisting system - too many requests
in a short space of time from a single IP will result in denial of
service for X (24?) hours. I'm not sure how something like Taverna
manages this kind of thing, but I expect this kind of user attribute
will have to be supported in the core web service model - that could
also provide authentication management support too (when users are using
secure or authenticated HTTP connections).


> From wikipedia the following are listed as BLAST resources where more
> than one may offer a web service interface. Should BioJava3 try and
> support more than one?
I would pick the two or three most popular/capable/geographically
widespread services to implement clients for, and then choose your
favourite one to start with (EBI,NCBI, and perhaps one in Japan - e.g.
http://xml.nig.ac.jp/wsdl/Blast.wsdl).

Implementing clients for two or three allows users a nice choice, and
should also capture most variation in the input/output and polling model
that is used. If any more need to be supported, then by then it should
be pretty clear how to go about implementing an API instance for a new WSDL.

You might also want to consider generalising the high-level interface to
non-Blast sequence search services, since they all take and return more
or less the same kind of data and results.

I suspect this discussion should move to the biojava-dev list!

Jim.