W672 Nucleic Acids Research, 2010, Vol. 38, Web Server issue extended capabilities of MOWServ are presented. The new functionality is related to web-services discovering, auto- matic support for data handling and standardization, and additional protocols to extend the BioMoby scope, and the MOWServ service quality, usability and robustness. NEW CHARACTERISTICS OF MOWServ Since the public release of MOWServ (18), the number of available services stands at around 600, and MOWServ invocations have also grown, managing more than 1 million in the last year. Since EMBRACE (19) is part of the Biocatalogue (http://www.biocatalogue.org) that has become the repository of reference for web-services in life Sciences, MOWServ web-services have also been regis- tered there, representing about 50% of the total web services in the registry. The increase of MOWServ capabilities has been possible due to the following improvements. New web-service registry Web-service registration policy at MOWServ is more re- strictive than for other BioMoby registries: new services should be registered at the development server (moby-dev, http://moby-dev.inab.org/MOWServ), where additional functional and technical information, as well as examples of input and output objects, has to be included. A form containing all mandatory information for MOWServ (but not in BioMoby standard) is required to be ﬁlled in. Only service owners can modify or remove their registration through the web interface or the BioMoby agent provided when they were registered at MOWServ. Service registry obliges service providers to test their service on the development server before ﬁnal validation regarding ontology localization and correct functioning in line with INB standards (e.g. information to generate help pages and the use of true XML objects as input and output data types). This procedure aims to guarantee the reliability of INB services. Validated services are then moved to the main server (http://www .inab.org/MOWServ) and its mirrors (like http://www .bitlab-es.com/MOWServ/) and are immediately made available to the world. As a matter of fact, users can make use of web services in the moby-dev server instead of the central one. However this is not recommended since moby-dev located services may not be completely func- tional or comply with INB rules. An additional way of guaranteeing service quality is the daily testing of service availability by the MOWServ. These checks can also be requested and performed on demand through the user interface. Ontology modiﬁcations The initial version of MOWServ (18) used the Canadian MOBY Central ontology, but the need for standardiza- tion soon became evident. The controlled protocol for registration of new services and data types implemented in MOWServ revealed a more coherent organization of resources while guaranteeing compatibility with MOBY Central. It classiﬁes web services into two main groups: basic services that simply manipulate objects (e.g. to create, to convert, to parse or to display them) are in the ‘Object Handling’ branch, and true bioinformatics algorithms are grouped in the ‘Bioinformatics’ branch of the ontology. The service name is intended to be self-explanatory and follows intuitive nomenclature rules (runClustalwFast, getNucleotideSequence, getBestHitsFromBlast). Likewise, additional metadata requested during the registration procedure allows MOWServ to provide detailed informative support in the form of tooltips or in the service interface (at parameter level). Apart from the well-known Blast, Fasta, ClustalW, Phylip, T-Coﬀee and EMBOSS applica- tions, the Bioinformatics branch includes the speciﬁc oﬀer of web services developed by the diﬀerent research nodes of the INB. Regarding the Object Handling branch, it includes a new node named ‘Displaying’ that gathers web services for image visualization. Datatypes ontology was also simpliﬁed while maintaining compatibility with Canada MOBY Central (17). Scheduler Due to geographic dispersion, possible multiple instances of the same service and the large number of clients that have access to the MOWServ, a mechanism to improve the reliability of service invocations (the execution of tasks), became necessary. The scheduler module in the MOWServ can be plugged with speciﬁc strategies in order to distrib- ute the computational load among the diﬀerent mirrors. Currently, the default option is to select the mirror in a round-robin fashion. The scheduler module in the MOWServ thereby enhances the robustness and fault tol- erance of service invocations. Asynchronism BioMoby uses HTTP as a transport protocol; however, this can lead to time-outs and breaks in client–server com- munication for long-running service invocations. The working solution has been to split the service invocation into several communications between client and service (asynchronous communication). Therefore, results must be temporarily stored locally by services until clients can retrieve them. This asynchronism protocol, which is now part of the BioMoby standard as a SOAP feature (17), is available to all users. Many of the available INB web services are able to communicate using this protocol, and MOWServ fully supports communication with asyn- chronous services. Error handling The initial BioMoby API approach to handling errors consisted of returning an empty package without any other information. Users and developers had no informa- tion when a service execution failed. The inclusion of a scheduler (see above) underscores this limitation since the source of error (mainly failed network communication and server down events) must be known in order to choose another mirror to execute pending tasks. Errors can be critical (no result produced) or a warning (an in- complete result can be produced), and can be