| | 38 | We prefer to stick with the [http://en.wikipedia.org/wiki/KISS_principle KISS principle (wikipedia)] (Keep It Sweet & Simple), and we believe it is also preferable for web services. |
| | 39 | |
| | 40 | Sophisticated semantics and ontology will probably work if ALL web services are annotated with that semantics, but we already know that it is not the case. Molecular Biology is obviously a rapidly advancing discipline of science, and even with the tremendous amount of efforts of the Bio* projects to make bioinformatics seamless throughout the numerous tools and databases, we still need many "glue codes" to connect the pipelines into usable workflows. |
| | 41 | |
| | 42 | If there is even a minimal amount of documentation and if that documentation is accessible, it is relatively easy for a user to figure out if one output of certain web service can be used as the input of another. Likewise, scientists can easily decipher wether given string is an amino acid sequence, nucleotide sequence, or NCBI gi (If he/she is not certain, he/she should not be using the service anyway). If the user can access the output of certain web service in a scripting language, it should also be simple for him/her to modify the variable to "glue" it to different service that take it as input in a little different format. |
| | 43 | |
| | 44 | In fact, majority of the BioMOBY ontology/namespace are defined for singletons, that are also mostly output formats. Input formats are rather limited, and therefore are simple. |
| | 45 | |
| | 46 | In light of the above facts, we have made the services easily discoverable, with the "help" command that is used to search G-language/BioPerl documentations. We have simply added a "-w" option which allows searching of web services, and when a specific service name is given, it shows the service description, with input/output types. All services can then be run with ws() function. When all procedures are done, users can simply use the "makelog" command of G-language Shell to output the session as a Perl script, which can be used as a "workflow". See [http://www.g-language.org/wiki/biomobyenglish here] for an example. |
| | 47 | |
| | 48 | SOAP was originally designed for RPC, and to transfer objects in an interoperable way. However, when connecting numerous web services in the form of workflows, data objects are usually too complicated to understand and to handle, so simpler data structures such as simple strings, arrays, or dictionaries (hashes) should be preferable. If a user wants to use one service just because there is no alternative, REST services that can be accessed with "curl" or "wget" command line utilities and with very simple (even raw and not marked up) output are most preferable. |
| | 49 | |
| | 50 | If a user wants to make use of MANY web services to create a workflow of services, WSDL file does not include service descriptions by nature, so it is very difficult for these services to be discoverable without some standards, such as BioMOBY. BioMOBY does a very good job for service discovery, so we hope that BioMOBY keeps its necessary description simple and short. |
| | 51 | |
| | 52 | Therefore, we believe SOAP is not simple enough, and it is neither sufficient in terms of service discovery. To make "gluing" easier, we believe that web services should be extremely simple to use (perhaps with REST?), and the clients should take care of the "gluing" with user interface and ease of scripting. |
| | 53 | |
