Soaplab is a set of Web Services. As with any Web services, their clients are programs, not just web pages waiting to be clicked on and filled in. This chapter will guide you through the clients provided with Soaplab, accessible from elsewhere, and it will show you how to code your own clients (in Java and in Perl).

The Soaplab and its documentation uses two similar but not the same entities (terms): an analysis and a service. An analysis is a program that has to be executed and controlled (such as Blast), while service is a Web Service that allows to execute and to control such analysis. Roughly speaking, a service is a SOAP-based wrapper around an analysis.

	Soaplab services at EBI

However, there would be no clients unless there are some services deployed. Therefore, most examples (and even some default pointers and values) below will use an existing set of Soaplab services running at The European Bioinformatics Institute (EBI). Of course, all the clients should work with your (and other) services as well (you will just need to specify their endpoint).

The Soaplab service collection at EBI runs on top of more than hundred bioinformatics analysis tools from the package EMBOSS. These services are accessible using the following endpoint (but not the WSDL files, for them see the next paragraph):

http://www.ebi.ac.uk/soaplab/services

For some time, the same or similar services may be running also at an experimental endpoint:

http://www.ebi.ac.uk/collab/mygrid/service4/soap/services

	WSDL for Soaplab services

Each Web Service, including Soaplab Web Services, has a description written in an XML-based WSDL language. Such description is complete but hardly human readable. However, there are tools allowing to generate various stubs from WSDL that make writing Web services clients easier.

There are two small issues with the WSDLs for Soaplab services (if you are not familiar with concepts behind WSDL you can skip this, you will not need it for most of the clients described below):

• The Soaplab API uses hash-tables for passing input data and retrieving results. Both inputs and outputs are named by names that are also accessible from the Soaplab API. But there is no place in WSDL for such names - a WSDL for a Soaplab service just declares that an operation carries (or returns) a hash-table, and that's it. Therefore, a WSDL itself is not enough to generate code for Soaplab clients.

  There is, however, a solution to this issue. If you need to rely on a WSDL (the clients described below, they don't), use derived Soaplab services instead. The WSDLs for derived services (the service names end with .derivedare also available (see below).

  Also, the Soaplab API can recognize sessions. For example, a client can start a job, keeping its identifier (a handler) and using it later in order to attach to the same job. This means that some methods make sense only if called in a particular order (first start a job, then ask for its status). Here again a WSDL does not help much - it does not have any provision for method ordering.

• Each WSDL can also contain a service address (endpoint), a URL where is the service accessible from. Be aware that, depending on the way how the WSDL was generated, this address may be harmed by an existing proxy server. This can happen when you get a WSDL by clicking on a link in a page generated by an endpoint (and if you are behind a proxy server).

  If you get such harmed WSDL, and if you wish to use it for feeding your tool, edit there the endpoint (it is usually located at the end of the WSDL). The better, of course, is to get the correct WSDLs in the first place (see the link below for the EBI's services).

The WSDL files for Soaplab services running at EBI were pre-generated and are available at http://www.ebi.ac.uk/soaplab/wsdl/.

If you see just a blank page your browser is not configured to display XML files - try to see the "Page source".

	Where to go next?

	Guide to ready-to-use Soaplab clients
	How to write your own client in Java