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
Hello Hamish.
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.
Jim.
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.
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
WebServices - 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@jalview.org
http://www.compbio.dundee.ac.uk/mailman/listinfo/jalview-discuss
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/1.1: Header Field Definitions. 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/1.1: Protocol Parameters; 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
WebServices - 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@jalview.org
http://www.compbio.dundee.ac.uk/mailman/listinfo/jalview-discuss