| 1 | = The Virtual Solar Observatory Overview = |
| 2 | |
| 3 | This document will explain the general structure of the Virtual Solar |
| 4 | Observatory's architecture, the goals and objectives that influenced |
| 5 | that architecture, and the terms and abbreviations used in this and |
| 6 | other supporting documentation. |
| 7 | |
| 8 | == Goals and Objectives == |
| 9 | |
| 10 | For a detailed explaination of the design influences for the VSO, |
| 11 | please see |
| 12 | [http://virtualsolar.org/docs/VSO_strawman_20021125.pdf The Virtual Solar Observatory Design Proposal, 2002 November]. |
| 13 | Relevent excerpts are contained below. |
| 14 | |
| 15 | === Principal Features === |
| 16 | |
| 17 | |
| 18 | * the ability to search all participating data sources with a common interface, |
| 19 | * the use of existing data query facilities at the current data sources, |
| 20 | * the use of industry-standard protocols such as eXtensible Markup Language (XML) in its internals, |
| 21 | * access through a Web browser interface to a remote VSO server, an Application Programming Interface (API), or via a VSO instance on a local computer, and |
| 22 | * extensibility to multiple additional features, including the registration of searches to enable other solar physicists to, for instance, attempt to reproduce the results of published literature. |
| 23 | |
| 24 | === Original Prototype === |
| 25 | |
| 26 | The original VSO prototype, which is occassionally refered to as |
| 27 | version 0.5, contained the following features: |
| 28 | |
| 29 | * virtualization of data search, data discovery, and query refinement, |
| 30 | * multiple interfaces (browsers, application programming interface), |
| 31 | * leveraging of existing data services (rather than creating e.g. new metadata standards), |
| 32 | * direct user access to data (without the VSO as an intermediary), and |
| 33 | * the ability to expand to several more data sources in the implementation and maintenance phases of the VSO (FY04 and beyond). |
| 34 | |
| 35 | The prototype specifically did not include the following: |
| 36 | |
| 37 | * a central catalog, |
| 38 | * grid computing |
| 39 | * any fetures that limit or restrict access to data or software (authentication). |
| 40 | |
| 41 | Planned features for later implementation included the following: |
| 42 | |
| 43 | * catalog caching (to speed queries), |
| 44 | * multiple instances of the VSO (to make the VSO truly virtual, it could run on local machines instead of on a small number of remote servers), and |
| 45 | * logging of searches (without identifyng the party who carried out the original search). |
| 46 | |
| 47 | This reference implementation imparted the following ideas into the |
| 48 | project: |
| 49 | |
| 50 | |
| 51 | First, it is not a monolitic server with a database that stores |
| 52 | metadata. Instead, it is an agile, lightweight application program |
| 53 | that accepts input (user queries) and provides output (data location |
| 54 | and access). We store XML descriptions of data providers as a data |
| 55 | structure (it can reside in memory) instead of static files or |
| 56 | records. |
| 57 | |
| 58 | Second, we treat each user input and query not only as a transaction |
| 59 | but as a real-time computation. By doing so, we are able to view VSOs |
| 60 | inner-parts as instantiated objects and perform operations or |
| 61 | manipulate them by applying methods. |
| 62 | |
| 63 | Finally, the deployment of VSO may be fully distributed with the |
| 64 | ability to have multiple, fully customizable VSOs running on user |
| 65 | desktops. |
| 66 | |
| 67 | === VSO 0.5 Architecture === |
| 68 | |
| 69 | {{{ |
| 70 | UI --> VSO --> WS --> DP |
| 71 | |
| 72 | UI : User Interface |
| 73 | VSO : VSO 'Core' Application |
| 74 | WS : Web Service |
| 75 | DP : Data Provider |
| 76 | }}} |
| 77 | |
| 78 | |
| 79 | == VSO 0.6 == |
| 80 | |
| 81 | With VSO 0.6, the inidividual objects were simplified and attempts |
| 82 | were made so that each one could function autonomously. The system |
| 83 | was modeled as additional objects, while still using the basic overall |
| 84 | concepts from 0.5: |
| 85 | |
| 86 | {{{ |
| 87 | Registry |
| 88 | ^ |
| 89 | | |
| 90 | UI --> UQI --> VSO --> DQI --> DP |
| 91 | |
| 92 | UQI : User Query Interface |
| 93 | DQI : Data Query Interface |
| 94 | }}} |
| 95 | |
| 96 | === Improvements in 0.6 === |
| 97 | |
| 98 | The changes from 0.5 to 0.6 were refinements of the VSO architecture |
| 99 | to assist with later maintenance of the VSO. In addition, the data |
| 100 | model signicantly changed with this revision. The following additional |
| 101 | objectives were realized: |
| 102 | |
| 103 | * the addition of new data providers should not require the modification of existing code, |
| 104 | * the modification of the VSO data model should not require significant changes to the VSO Core, and |
| 105 | * the modification of the VSO data model should not require immediate action by VSO Data Providers. |
| 106 | |
| 107 | To deal with the implications of these new objectives, there |
| 108 | were some minor changes |
| 109 | |
| 110 | |
| 111 | === VSO 0.7 === |
| 112 | |
| 113 | With VSO 0.7, we attempted to move specifics of individual Data Providers |
| 114 | out of the User Interface. To meet these goals, we did the |
| 115 | the following: |
| 116 | |
| 117 | * the ability to request the necessary data provider information to generate query forms, and |
| 118 | * the ability to determine the proper procedure to download data from a particular data provider. |
| 119 | |
| 120 | These changes have resulted in the need for an additional component, the |
| 121 | Central Server. The Central Server contains the authoritative records |
| 122 | for various information that the VSO Core instances and User Interfaces |
| 123 | may require to provide a consistent experience with the addition of new |
| 124 | data providers. To maintain the virtual aspects of the system, |
| 125 | provisions have been made for multiple Central Server mirrors, and for |
| 126 | the possibilty of no Central Servers being available. |
| 127 | |
| 128 | VSO 0.7 was never released to the public, due to flaws in the |
| 129 | logic for ordering data, specifically in the cases of a 'partial success' situation. |
| 130 | |
| 131 | |
| 132 | === VSO 0.8 === |
| 133 | |
| 134 | To solve the logic errors present in 0.7, modifications were made to the |
| 135 | ordering mechanims within VSO. The following changes were made: |
| 136 | |
| 137 | * Data Providers returned enough information for a User Interface to repeat the query, without having maintained records of what the original query was. |
| 138 | |
| 139 | === VSO 1.0 === |
| 140 | |
| 141 | The 1.0 release was a series of small, but subtle refinements to VSO, |
| 142 | to move it to the point where solar researchers could use it for regular |
| 143 | tasks. |
| 144 | |
| 145 | The following modifications were made: |
| 146 | |
| 147 | * Data Serialization was improved to support the possibility of communicating with components written in strictly-typed languages, and |
| 148 | * Mechanisms were added to permit Data Providers to extend the messages to send additional information. |
| 149 | |
| 150 | More obvious to the general public, however, was a revamping of the |
| 151 | default web-based User Interface, which included the following: |
| 152 | |
| 153 | * Customizable search form generation, |
| 154 | * improved searching by 'nicknames', |
| 155 | * thumbnail previews of data products when available, and |
| 156 | * improved data product ordering capabilities. |
| 157 | |
| 158 | === VSO 1.2 === |
| 159 | |
| 160 | The 1.2 release encorporated refinements suggested by the solar physics |
| 161 | community, and attempted to make the overall system easier to maintain. |
| 162 | |
| 163 | The following modifications were made: |
| 164 | |
| 165 | * Created a system to browse the VSO Registry, |
| 166 | * Populated additional information in the VSO Registry, including 'data layout', |
| 167 | * Provided a mechanism to allow a provider matching to work for providers with multiple web services, |
| 168 | * Improved handling of unit conversions in spectral ranges searches, and |
| 169 | |
| 170 | |
| 171 | Significant changes were made to the web-based User Interface, with |
| 172 | the result of removing all data provider specific code from the User |
| 173 | Interface. |
| 174 | |
| 175 | Modifications to the web-based User Interface included the following: |
| 176 | |
| 177 | * Introduced the 'catalog search' interface, to allow the time parameter to be derived from solar event catalogs, |
| 178 | * provided online help for search terms, |
| 179 | * added a 'drill down' interface as an alternative to select instruments, |
| 180 | * added a system to allow VSO Cart IDs to be used to reload the results saved from past searches, |
| 181 | * added a mechanism to turn the browse images for VSO data products into a slideshow, and |
| 182 | * provided a mechanism to pass arguments into the search form to pre-select items. |
| 183 | |
| 184 | |
| 185 | == What VSO isn't == |
| 186 | |
| 187 | VSO's primary goal is to discover and facilitate the retrieval of data |
| 188 | products. Although later VSO User Interfaces may automate the retrieval |
| 189 | process, or post processing of data products, this is outside of the |
| 190 | scope of VSO's primary objectives, and may not be present through all |
| 191 | VSO User Interfaces. |
| 192 | |
| 193 | VSO is a lightweight, virtualized system. It provides a framework for |
| 194 | finding data products, but does not maintain an itemized list of data |
| 195 | products available. The VSO Registry maintains generalized information |
| 196 | about the product offerings from each data provider, which may be made |
| 197 | more specific in the future to assist in optimization efforts. |
| 198 | |
| 199 | == Future Plans == |
| 200 | |
| 201 | The Virtual Solar Observatory project will work with other similar and |
| 202 | complementary projects to make data products and services more widely |
| 203 | available to the solar physics community. Data providers will be added |
| 204 | to provide additional data products. User interfaces will be added to |
| 205 | provide for both general and niche purposes. Features will be added and |
| 206 | refinements made to assist solar researchers in finding data products |
| 207 | that may be of interest. |