Changes between Version 2 and Version 3 of Objectives

2007/11/29 08:13:12 (12 years ago)



  • Objectives

    v2 v3  
    33== Background == 
    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. 
     5As the databases in life science is keep growing and daily updated, integration of these databases by mirroring in one organization is not feasible. 
     6Instead, it is required to develop the way to utilize variety of databases directly over the distributed environments. 
    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. 
     8This situation brought on SOAP/WSDL web services to be launched at the major database centers around the world including NCBI and EBI. 
     9In the same way, DDBJ, KEGG, PDBj, and CBRC has been released relevant web services in Japan. 
    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. 
     11Several projects like BioMOBY and myGrid/Taverna projects have been started to utilize these services in an unified way, 
     12and it is strongly believed that this kind of integration should be accomplished by the SOAP/WSDL based web service technology in this field. 
    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. 
     14However, inconsistent specifications of the data structures and the naming conventions among these services prevent the interoperability. 
     15Besides, the insufficient documentation of each services is one of the bottle necks to popularize these services. 
     16Additionally, the web service is originally designed to be utilized by every programming languages which have support for SOAP/WSDL, 
     17but there are several services which can't be used with some languages. 
     18It is also hard to handle the cases like temporal service down or whatever error occurred while executing a job for end users. 
    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. 
     20To improve this circumstance, it is a key to standardize the data structures to be passed among existing web services and 
     21to increase the number of tools and databases accessible through the web service for creating practical bioinformatics workflows. 
    3523== Efforts in DBCLS == 
    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; 
     25Thus, we at DBCLS are planning to construct a proxy-like server, which aim to provide unified and consistent usages of the existing services. 
     26For this purpose, we would firstly consider: 
    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. 
     28 * provides sufficient documentation for the usage of each services 
     29 * ensures every operations to be accessible by the widely used languages like Perl, Ruby, Python and  Java. 
     30 * translates data structure exchanged among servers to create seamless workflows 
     31 * concatenates pipelines over several steps to be done on the server side in typical cases for the effecitivity 
     32 * handles various errors returned by external services at the server side as much as possible 
    50 By conducting our proposal, not just providing environments exeeded in 
    51 usability to many researchers, it can act as an infrastructure for 
    52 constructing workflows which accordingly provide each centers a dramatical 
    53 increase of internet access counts. 
    55 At the same time, consideration is  needed over what categories of 
    56 services to provide, those quantity and quality. Therefore it is 
    57 desirable to parallelize working on providing service along with  
    58 developments of integrated databases and tools at DBCLS. 
     34By conducting our proposal, not just providing user friendly environments to many researchers, 
     35the server can act as an infrastructure for constructing practical workflows effectively utilizing existing services. 
     36At the same time, we will also provide new web services for tools and databases to be developed at DBCLS.  
    6038== Objectives of this Hackathon == 
    62 To lead to a standardisation of; 
     40To discuss about a standardisation of: 
    64  * naming convention of methods 
    65  * data structure passed among services 
    66  * job controlling 
     42 * data structures exchanged among services 
     43 * naming convention of the methods (operations) 
     44 * technique of the job management for the time consuming query 
    6846which at present differ within each providers. 
    70 Therefore, we are going to held developer's meeting in January or 
    71 February of 2008. There, core developers and key members at home and 
    72 abroad related to each web service providers, including BioMOBY,  
    73 Open Bio*s (ie. like BioPerl), would be offered to attend  
    74 this meeting, staying for about a week in Japan. 
     48Therefore, we are going to held developer's meeting in February of 2008. 
     49There, key members related to each web service providers around the world 
     50and core developers from BioMOBY and Open Bio* (BioPerl, BioRuby, BioPython, and BioJava),  
     51would be offered to attend this meeting, staying for about a week in Japan. 
    76 So far, data type (class design) for bioinformatics has been defined for 
    77 each project of Open-bio (like BioPerl, BioPython, BioJava, BioRuby) 
    78 respectively. 
    79 Though to benefit interoperability, it seems to be nice to define 
    80 standard specification of objects based on web services' class, to  
    81 comply with it. 
     53Historically, the class design, which represents bioinformatics data types, 
     54has been defined by each Open Bio* project, independently. 
     55In this opportunity, to define the standard specification for the biological objects 
     56through the web service will also benefit interoperability among these libraries. 
     57Seamless integration of the remote (web services) and local (installed tools) environment is 
     58an another challenge for those projects.