Web Services & Javascript: Difference between revisions
| Line 5: | Line 5: | ||
== Architectural Overview == | == Architectural Overview == | ||
The overall architecture is based on the flow of data through server side scripts in C at genome.ucsc.edu into Javascript-controlled web pages. The major objects in the system include (some of which have expressions both in the C and the Javascript side) include "user," "dataSource," "genomeAssembly," "track," "item," and "relationship." The user object handles passwords and other security, and the user interface settings. A dataSource represents a place that the system queries for live data. It may include a file or data base on the server, a remote SQL database or file set, a web site that the C scripts know how to query via a web-services interface of some sort, or the user's custom tracks. A genomeAssembly includes a particular genome assembly and a NCBI taxon number. A track is conceptually just a table that _may_ include genome position fields that are hooked to a genome assembly. Tracks may be implemented in a variety of ways, not necessarily as SQL tables. An item is conceptually a row in a track table. A relationship links together fields in the track/table rows. | |||
=== Abstract notion of a data track === | === Abstract notion of a data track === | ||
Revision as of 20:47, 24 February 2009
Introduction and Motivation
We're thinking of reworking the genome browser so that Javascript is responsible for the layout of the page at a high level rather than the C scripts on the server. As part of this we'll be moving the C scripts to more of a web-services oriented architecture, where they'll be returning information in JSON rather than in HTML and GIF images. For the near term at least they probably will return GIF images as well. The goal of this rearchitecting is to make it easier to be more interactive, and to take advantage of the good Javascript user-interface (UI) oriented libraries like jQuery.
As is often the case with software development, the demon is in the details. Nonetheless it is helpful to have a clear, simple high level design to start with - to keep at least the messy details in one location of the code from breeding and exponentially multiplying with messy details in other locations....
Architectural Overview
The overall architecture is based on the flow of data through server side scripts in C at genome.ucsc.edu into Javascript-controlled web pages. The major objects in the system include (some of which have expressions both in the C and the Javascript side) include "user," "dataSource," "genomeAssembly," "track," "item," and "relationship." The user object handles passwords and other security, and the user interface settings. A dataSource represents a place that the system queries for live data. It may include a file or data base on the server, a remote SQL database or file set, a web site that the C scripts know how to query via a web-services interface of some sort, or the user's custom tracks. A genomeAssembly includes a particular genome assembly and a NCBI taxon number. A track is conceptually just a table that _may_ include genome position fields that are hooked to a genome assembly. Tracks may be implemented in a variety of ways, not necessarily as SQL tables. An item is conceptually a row in a track table. A relationship links together fields in the track/table rows.
