View source for Database Interop Hackathon/Target Projects

{{HackHead}}
= Criteria to consider for target projects =

* successful outcome would enhance (or showcase) interoperability
* work involves 2 or more participants of hackathon
* project is reasonably expected to produce tangible outcomes (even if it falls short of some goals)
* project outcomes can be re-used by others for further interop improvements

= Suggested targets with no plan (yet) =

* The One Database that Rules them All (generate from [[PANDIT]], [[TreeBASE]], TreeFam, etc inputs)
* a NESCent portal that would provide a common interface to several different resources.
* a package for users to turn a set of NEXUS or nexml files into a browsable web resource (see [[mx]])
* a common provenance standard for identifying a data resource as the source of something (name, url, citation)
* [http://www.molevol.org/nexplorer Nexplorer]-like API for [[CDAO]] (web app for visualizing and manipulating character-data-and-trees)
* your idea here

= Suggested targets with a plan =

== Data retrieval, based on an identifier ==
This simple reference service returns phylogenetic data that is identifiable by some GUID, such as a [http://tolweb.org ToLWeb] accession number. The service is implemented following the [[PhyloWS/REST]] proposal, has a [[CDAO]] annotated service description and emits [[Future_Data_Exchange_Standard|NeXML]].

=== Describing the interface ===
The first step is to formally describe the interface. In general terms, PhyloWS/REST proposes that data retrieval services are exposed using a URL API like this: '''<code>/phylows/${dataType}/${nameSpace}:${identifier}</code>''', where '''<code>${dataType}</code>''' is something like "Tree", "Matrix", etc. '''<code>${nameSpace}</code>''' is a naming authority such as ToLWeb, and '''<code>${identifier}</code>''' is unique within '''<code>${nameSpace}</code>''' (and consequently globally unique). This implies URLs such as '''<code>/phylows/Tree/ToLWeb:16299</code>''', which, when accessed using the [http://en.wikipedia.org/wiki/Hypertext_Transfer_Protocol#Request_methods GET HTTP method] returns a representation of tree [http://tolweb.org/16299 16299].

A standard way to describe this behaviour is to express it in [http://en.wikipedia.org/wiki/Web_Services_Description_Language WSDL2.0] - there's a nifty example of wsdl generation and annotation [http://www.keith-chapman.org/2008/09/restfull-mashup-with-wsdl-20-wso2.html here]. At the time of writing, the best free editor for wsdl files comes with the WTP extension for [http://eclipse.org eclipse]. The end result is a file such as [http://nexml.org/nexml/phylows/tolweb?wsdl this one]
<div style="1px solid silver">
[[Image:Tolrest.jpg]]

''Graphical representation of [http://nexml.org/nexml/phylows/tolweb?wsdl this] service description.''
</div>

=== Implementing the service ===
A service for the interface described in the previous section can be implemented as an MVC-like application. The '''controller''' part of the service needs to find out what the requested Tree ID is. Depending on the implementation language (and whether some advanced web application programming framework is used) the Tree ID is either part of the '''<code>${PATH_INFO}</code>''' environment variable, or encapsulated in some kind of request object. However the Tree ID is retrieved from the request, the next step is to look up the record that the ID refers to. Typically this would be done in a database query. The goal here is to collect all information needed to populate a '''model''' object (in this case a tree) that can be serialized to the right return format. Assuming that the return format is NeXML, libraries for perl, python, java and c++ are available that supply model objects.

Once populated, the controller object creates a view using the model objects. In the simplest case, for web applications, this boils down to printing out the XML string representations of the model objects, preceded by the correct [http://en.wikipedia.org/wiki/List_of_HTTP_status_codes response code], e.g. <code>200 OK</code>, and [http://en.wikipedia.org/wiki/MIME mime-type], e.g. <code>application/xml</code>. In more complex web application architectures, the string representations of the model objects may be passed to a response object (which in turn is serialized and returned to the client), or the objects may be passed into a template (jsp, Template Toolkit, php) where they are stringified.
=== Outstanding issues ===
* Dearth of support for PHP
* How to deal with errors (e.g. response codes)
* Query interface
* CDAO integration

[[Category:DB Interop Hackathon]]