W22 Nucleic Acids Research, 2007, Vol. 35, Web Server issue Table 1. Brief description of web services API models, used on iHOP web services Web services API models REST SOAPþWSDL BioMOBY Description The Representational State Transfer paradigm is based on the HTTP protocol. It is an improvement over CGI sub-protocol, used by web browsers to send the data in the HTML formularies. The main diﬀerence is on the provided results: a REST service is usually restricted to answer with an XML document with all the information; a CGI service can return any document type (HTML, GIF, PDF, etc.). There are also diﬀerences between CGI and REST is the way to send the queries: a key-value model is used to send the query data to the CGI service; REST implementations send an XML document with the whole information. Some implementations following REST paradigm (e.g. DAS and iHOP CGI-XML), follow the CGI sub-protocol for the queries, and answer an XML document as the result. The Simple Object Access Protocol web services paradigm tries to isolate the used communications protocol from the message representation by using XML formatted messages and diﬀerent message exchange patterns. SOAP messages have an envelope and a body, so complex features and message exchange patterns can be implemented, nevertheless the used communications protocol. Although there are SOAP client and server libraries for FTP, SMTP, POP3 and other protocols, the most used communication protocol is HTTP. Web Services Description Language is a companion technology of SOAP services. WSDL documents are usually used to describe SOAP services: their inputs and outputs, their XML data types, the data encoding and the message patterns to use. Although any SOAP service can be used without the aid of a WSDL document which describes the service, they are a standard way to distribute that information. BioMOBY web services architecture has three main roles: MOBY Central, MOBY clients and MOBY services. MOBY Central is the repository of the ontologies used by the architecture: namespace ontology, which is used to label biological references so they can be unambiguously identiﬁed; object ontology, which deﬁnes the object types which can be consumed and produced by the services; service type ontology, which contains the classiﬁcation of service types used to label the diﬀerent services; and the service ontology, which contains the description of all the registered MOBY services. One of the features which distinguishes BioMOBY architecture from SOAP Protocol is that many queries can be clustered on a single message when they are sent to a service. Although BioMOBY architecture has its own message formats and query protocols, SOAP infrastructure is used to wrap MOBY messages. BioMOBY community is now discussing the need to drop SOAP (due its overhead) in favour of lighter REST paradigm. the valuable information that is already accessible through the iHOP user interface. For instance, annotated sentences are generated by getSymbolDeﬁnitions, getSymbol Interactions and getPubMed functionalities. Each sentence also provides information about the abstract, journal and the journal impact factor. Basic symbol information is provided by getSymbol Info, and it can also be found on getSymbol Deﬁnitions and getSymbolInteractions results. The designed XML Schema, along with its documenta- tion, is available at the iHOP web services site. Usually, gene symbol disambiguation is a hard task, made in the last term by the user, and its automation is an essential part in a useful workﬂow. Using speciﬁc heuristics for these web services, we have created an additional functionality called guessSymbolIdFrom SymbolText, which guesses the nearest unambiguous iHOP gene symbol id from free text input and an optional target organism. This concept is very similar to ‘I’m feeling lucky’ Google functionality, and the functionality speeds up workﬂow building. Workﬂow writers are not tied to this service and its heuristics, because anyone can create their own heuristics about symbol selection using getRelatedSymbols output. Under the REST (Representational State Transfer) paradigm there is a CGI-XML service available for all functionalities described earlier. Special return cases have been modelled using standard HTTP codes: when there is no answer for a query in a CGI-XML service, a 404 Not Found error is returned; if an internal error happens, a 500 Internal Server Error is used; if no input parameter is speciﬁed, a 400 Bad Request error is returned. For SOAP (Simple Object Access Protocol), we created for each functionality variations of the same web service, to simplify workﬂow building. SOAP services use the RPC/encoded WSDL style, so they can be used from Perl programs with any SOAP::Lite version. Critical errors (no input parameter, internal server error) are reported by the iHOP SOAP services using the standard SOAP fault mechanism. When there is no answer to return, the services return a speciﬁc XML structure (iHOPSOAPNotFound) designed for these SOAP services, instead of using SOAP fault mechanism. This is impor- tant, because some workﬂow enactment tools (like Taverna) stop the whole workﬂow when a SOAP service returns a SOAP fault, an undesirable eﬀect when a service invocation has not failed. In the design of BioMOBY services it was necessary to comply with the common object ontology on MOBY Central and the portfolio of services that are using this ontology. Although the main iHOP services take the same parameters as input and use the same XML schema as CGI-XML and SOAP for their outputs, the true power of iHOP MOBY service are the additional translation services. These services take as input iHOP XML structures generated by the iHOP services, and translate the content into a collection of usable MOBY objects. This way, other MOBY services which use the same ontology can be chained to this output. CGI-XML services were tested using both web browsers and command-line HTTP retrieval tools (like wget). We tested and cross validated the functionality of iHOP SOAP web services with unit tests based on the Perl SOAP::Lite library and in the context of Taverna (10,11), a workﬂow enactment tool extensively used by the bioinformatics community. We found that SOAP::Lite 0.60 had a better behaviour than former versions and some new intermediate ones (last version is 0.69).