| | 1 | = Objectives for the Web Service Hackathon = |
| | 2 | |
| | 3 | == Background == |
| | 4 | |
| | 5 | Databases in lifescience area have enormous amount of data, still |
| | 6 | growing and becoming more multi-faceted. To provide integrated services |
| | 7 | , the way just centralising these databases, like by mirroring each |
| | 8 | databases, is insufficient but also the way using directly over |
| | 9 | distributed environments is strongly needed to be constructed at really |
| | 10 | serviceable state. |
| | 11 | |
| | 12 | This situation brought on SOAP/WSDL web services to be launched at |
| | 13 | institutes around bioinformatics like NCBI and EBI abroad, and DDBJ XML, |
| | 14 | KEGG API, PDBj, CBRI in Japan, providing respective services handling |
| | 15 | many tools and databases. |
| | 16 | |
| | 17 | Also, by myGrid project and BioMOBY project, efforts has already been |
| | 18 | made to provide foundation to use those web services in an unified way, |
| | 19 | which brings situation very practical to implement integration by web services |
| | 20 | technology around this field. |
| | 21 | |
| | 22 | Main problems are, the variety of each specification and |
| | 23 | naming convention, and unstandardised data structure to be passed. |
| | 24 | Additionally, handling for cases like temporal service down or whatever error |
| | 25 | occured while executing a job just rely on each provided servers which |
| | 26 | tends to leave insufficient specification documentation. |
| | 27 | |
| | 28 | Existence of different usages among each services, or situation compelling |
| | 29 | user to exchange data types and to handle exceptions for their own |
| | 30 | is really inefficient. Furthermore, the number of serviced tools and |
| | 31 | databases providing web services are still few, which makes it quite |
| | 32 | severe to achieve constructions of workflows through these services for |
| | 33 | the moment. |
| | 34 | |
| | 35 | == Efforts in DBCLS == |
| | 36 | |
| | 37 | Thus we at DBCLS have planned to search usage of existing web services and |
| | 38 | of those data structures to construct proxy-like server, which aim to provide |
| | 39 | unifed and consistent naming conventions and usages. |
| | 40 | To make this, we would first consider; |
| | 41 | |
| | 42 | * Services be well documented. |
| | 43 | * Owe error handling at server side as much as possible. |
| | 44 | * Servers to be accessible by languages widely used like Perl, Ruby, Python, |
| | 45 | Java and more as many as possible. |
| | 46 | * Owe data exchange by server side to make communicate between many |
| | 47 | servers servicing web services. |
| | 48 | * Pipelines over several steps be done on server side to be effective enough. |
| | 49 | |
| | 50 | Although BioMOBY operates similar service working as web services |
| | 51 | repository, like secondary database "Refseq" was neeeded to primary |
| | 52 | database like GenBank, we think it's the time to generate secondary fine |
| | 53 | web service database after simply aggregating existing web service, for real utilization. |
| | 54 | |
| | 55 | By conducting our proposal, not just providing environments exeeded in |
| | 56 | usability to many researchers, it can act as an infrastructure for |
| | 57 | constructing workflows which accordingly provide each centers a dramatical |
| | 58 | increase of internet access counts. |
| | 59 | |
| | 60 | At the same time, consideration is needed over what categories of |
| | 61 | services to provide, those quantity and quality. Therefore it is |
| | 62 | desirable to parallelize working on providing service along with |
| | 63 | developments of integrated databases and tools at DBCLS. |
| | 64 | |
| | 65 | == Objectives of this Hackathon == |
| | 66 | |
| | 67 | To lead to a standardisation of; |
| | 68 | |
| | 69 | * naming convention of methods |
| | 70 | * data structure passed among services |
| | 71 | * job controlling |
| | 72 | |
| | 73 | which at present differ within each providers. |
| | 74 | |
| | 75 | Therefore, we are going to held developer's meeting in January or |
| | 76 | February of 2008. There, core developers and key members at home and |
| | 77 | abroad related to each web service providers, including BioMOBY, |
| | 78 | Open Bio*s (ie. like BioPerl), would be offered to attend |
| | 79 | this meeting, staying for about a week in Japan. |
| | 80 | |
| | 81 | So far, data type (class design) for bioinformatics has been defined for |
| | 82 | each project of Open-bio (like BioPerl, BioPython, BioJava, BioRuby) |
| | 83 | respectively. |
| | 84 | Though to benefit interoperability, it seems to be nice to define |
| | 85 | standard specification of objects based on web services' class, to |
| | 86 | comply with it. |
| | 87 | |
