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. _______________________________________________ Biojava-l mailing list - [email protected] http://lists.open-bio.org/mailman/listinfo/biojava-l
