[Jalview-discuss] JalView and WSDbfetch

Hamish McWilliam hpm at ebi.ac.uk
Fri Jan 27 16:10:42 GMT 2012


Hi Jim,

> Thanks for your very clear observations concerning Jalview's rather aged
> client for the EBI's database services. Since Jalview 2.7 now requires a
> minimum of Java 6, the obvious thing would be to change the wsdbfetch
> client to one based on JAX-WS 2.0, in line with the other services
> Jalview uses. I've not prioritised this myself because the original
> service has performed so well.
>
> That being said - It very much sounds like you'd like to remove the
> legacy endpoint. If that is the case, can you provide an EOL timeline ?
> Deadlines are always nice to know about.

I would like to be able to remove the old-old endpoint, but at the 
moment there is no definite time-line for decommissioning this 
interface. This is mostly because we are not sure what/who is using it 
and we do not want to have users suddenly have fetches fail until there 
is a clear upgrade path for their client(s) or the number of users 
affected would be small. If I assume that the majority of the 
Axis/1.2RC2 requests I see are JalView, it would appear that JalView is 
the main user of this endpoint, but this is a big assumption...

> ps. Regarding the logging, I'll take a look at your documentation. My
> experience with custom user agent strings, however, has not been a happy
> one (read that as: I once spent several days trying to get custom agents
> to appear in google analytics and they never did), but I'm sure we can
> come to an agreement. Alternately, I am also happy to institute a
> 'tool=jalview' style usage indicator analogous to the approach that we
> use for the rest client for EnVision2 and Sequence Harmony.

Well Google Analytics shouldn't be an issue for JalView, unless you are 
fetching HTML pages and running the JavaScript :-).

For JAX-WS I set the User-Agent on a per-service basis, and since we 
don't do anything fancy with the User-Agent this can be set to anything 
with the limits specified in the RFC 
<http://www.w3.org/Protocols/rfc2616/rfc2616-sec14.html#sec14.43>. For 
REST it depends on the library, see our Java tutorials 
<http://www.ebi.ac.uk/Tools/webservices/tutorials/06_programming/java> 
for examples. In either case when setting the User-Agent I strongly 
recommend sticking to the product string specification from the RFC 
<http://www.w3.org/Protocols/rfc2616/rfc2616-sec3.html#sec3.8> to ensure 
anyone attempting to parse the User-Agent has a little trouble as possible.

At this point I'm reluctant to go down the route of introducing 
additional parameters for this, since this has consequences for both the 
REST and SOAP interfaces, as well as for our log processing. Especially 
since this is the purpose for which the User-Agent was intended.

All the best,

Hamish

> pps. If anyone would like to patch or otherwise regenerate the WSDbFetch
> client in Jalview before I get around to it, I'm happy to merge it with
> the codebase!
> Bug is open here: http://issues.jalview.org/browse/JAL-1048
>
>
> On 27/01/2012 13:53, Hamish McWilliam wrote:
>> Hi folks,
>>
>> A couple of observations from checking through our logs from WSDbfetch:
>>
>> * JalView is using Apache Axis 1.2RC2 as the SOAP library. The last
>> version of Apache Axis to support RPC/encoded SOAP services was 1.4 (see
>> http://ws.apache.org/axis/). Switching may involve some changes, but
>> does improve performance and fixes some bugs. Alternatively WSDbfetch
>> now provides a document/literal interface and thus can be used with more
>> recent libraries such as Axis2 and JAX-WS.
>>
>> * JalView is using the a legacy SOAP end-point for WSDbfetch (see
>> http://www.ebi.ac.uk/Tools/webservices/services/dbfetch), this has been
>> replaced by the end-points described in the current WSDL documents:
>> - http://www.ebi.ac.uk/ws/services/WSDbfetch?wsdl
>> - http://www.ebi.ac.uk/ws/services/WSDbfetchDoclit?wsdl
>> Note that, as well as supporting newer SOAP tool-kits (e.g. JAX-WS), the
>> document/literal SOAP service (WSDbfetchDoclit) contains additional
>> features not present in the RPC/encoded SOAP service (WSDbfetch) and is
>> the target for future updates to the SOAP service.
>>
>> * To allow us to determine how much usage of the service comes from
>> JalView it would be nice if it used a specific user-agent for these
>> requests (see the provided sample clients for an example of how to do
>> this). I suspect other providers of services for which JalView is a
>> possible client would also like this.
>>
>> All the best,
>>
>> Hamish
>>
>> _______________________________________________
>> Jalview-discuss mailing list
>> Jalview-discuss at jalview.org
>> http://www.compbio.dundee.ac.uk/mailman/listinfo/jalview-discuss
>



More information about the Jalview-discuss mailing list