# Presentation: 943875

## Latest Developments on theLive Access ServerSteve Hankin - NOAA/PMEL

| Jon Callahan
Kevin O’Brien | 
U. Washington/JISAO |
| --- | --- |
| Roland Schweitzer | Weathertop Consulting |
| Ansley Manke
Xiaoping Wang | NOAA/PMEL
MacroStaff, Inc. |
| Yonghua Wei
Joe McLean Joe SirottRichard Rogers
Jerry Davison | 
(past team members) |

- Funded by:
-  NOAA
-  NASA
-  US Navy
-  NSF
-  NOPP
- Ver. 1.0 – 1994

**(new)**

**Looking for another      Suggestions?**

**Notes:**
Credits ...
A tour through pictures

## I hate outlines

- Review
- What’s new
- What’s next

## Review

- Main Entry: **L·A·S**  Pronunciation: ‘el-ay-esFunction: *noun*
**1. **a configurable product serverfor 1 to 4Dgeo-science datasets
- Merriam-Webster Dictionary2005 Hankin edition

**Notes:**
Designed to handle hundreds of distributed datasets – thousands of variables

Here you see “By institution” on the NVODS server

## “Configurable”:
Information hierarchy
Variables and products
User Interface
Sister servers

Architecture basics

- Information hierarchy
- Variables and products
- User Interface
- Sister servers
- Architecture basics

- Review

## A science “home page”

- Informationaccess

- Parallel data   access

- Live Access Server

**Notes:**
Need flexible configuration – create a hierarchy that matches the Web page hierarchy, so that at any point along the way one can enter the data access hierarchy

## Information hierarchy:NVODS LASas an example

- Information hierarchy:NVODS LASas an example

**Notes:**
Showing snapshots of the NVODS LAS interface by way of illustration ...
Bi-directional integration – other datasets into OSMC, OSMC into NVODS ...

## A typical “main” window of the user interface

- basic constraints

- configurable options

**Notes:**
Note that Options on the main constraints page are a new feature in V6.5

## netCDF

**Notes:**
Range of output products is limited only by installer
... this slide shows some of the default outputs using Ferret as a backend

## Compare variables from different datasets

## Difference plot(regridding as required)

- Difference plot(regridding as required)

## Compute simple analyses

## Slide 12

## In-situobservations

*In-situ*observations

-  custom “constraints”

## LAS -- an “Information Product Server”

-  XML Metadata contains the “intelligence”
-  Back end applications do the real work
-  OPeNDAP provides remote data access

**Ferret,**
**CDAT**
**or other**

**Notes:**
How it works.  Very conventional.
LAS is a “traffic cop” -- Heart of LAS intelligence lies in the metadata
The metadata guides two quite independent servers (not even written in same language)

## The UI talks to LAS through an XML “web service”

**Notes:**
Because the user interface server and the product server are separate ...

## radical custom UIs:e.g.  for K-12 students(LAS v6.5 includes a JavaScript API)

**Notes:**
Created by Kevin

## Query available data sets:

Query variables in data set “model_1”:

Query space-time domain:

Request a subset of data as a file: (“asc” for ASCII format)

**Query variables in data set “model_1”:**
**Query space-time domain:**
**Request a subset of data as a file:**** (“asc” for ASCII format)**

- “Scripted” access to LAS

**>lasls http://cpu/LAS**

**>lasls http://cpu/LAS  model_1**

**>lasls http://cpu/LAS  model_1  sst**

**>lasget  -x 20:60  -y 20:60  -t 11-Dec-2000  -f asc ****       http://cpu/LAS  model_1 sst**

**Notes:**
Really just another user interface ...

## Custom-izedUIs:variations on familiar look and feel

## I hate outlines

- Review
- What’s new
- What’s next

## THematic Realtime Environmental Distributed Data Services(from Unidata)
-- an XML summary of a data collection --

LAS can generate a THREDDS catalog

LAS will auto-configure from a THREDDS catalog

- -- an XML summary of a data collection --
- LAS can generate a THREDDS catalog
- LAS will auto-configure from a THREDDS catalog

- LAS and THREDDS

**Notes:**
Really just another user interface ...

## THREDDS output

## LAS can generate a THREDDS catalog
LAS will auto-configure from a THREDDS catalog

      “addXML” == LAS utility to configure data sets

Point addXML at a THREDDS catalog and you get an LAS to access that catalog.   E.g. for
OPeNDAP servers
GDS and Unidata aggregation servers
Other LAS servers

- LAS will auto-configure from a THREDDS catalog
-       “addXML” == LAS utility to configure data sets
- Point addXML at a THREDDS catalog and you get an LAS to access that catalog.   E.g. for
- OPeNDAP servers
- GDS and Unidata aggregation servers
- Other LAS servers

**Notes:**
Really just another user interface ...

## LAS and OPeNDAP

- FDS = “Ferret Data Server”
- OPeNDAP output for LAS-served data
- Built on ‘Anagram’ Java framework(like “GDS” -- from C.O.L.A.)

**Notes:**
Analogous to “GDS”

## E.g. On-the-fly regriddingfrom curvilinearto rectilinearcoordinates

- FDS serves this rectilinear “view” through OPeNDAP

**Notes:**
As an example ...
Curvilinear is 122x122 ECMWF operational data used for testing
Output is Levitus 1x1 degree (360 x 180, but only about 1⁄4 of the latitudes are relevant)

## LAS browsing can be continued at the desktop

## Continuing at the desktop ...

- Open the remote dataset (“foo”) like any filename
*http://server/FDS/foo*
- FDS provides server-side analyses:(Z-average of “TEMP”)
*http://server/FDS/_expr_{foo}{Tave=TEMP[Z=@AVE]}*
- FDS employs “delayed analysis”
- the whole dataset appears to be transformed

## Collaborating “sister” servers

- Servers request regridded data from one another via FDS.

**Notes:**
In “sister serving” of data a single virtual site presents a user interface for all of the sisters.
If the UI has been customized (layout, custom constraints, options, etc. ...) those customizations will be presented as on the sister.
The client (browser) sends the requests for products to the sister that “owns” that data, so customized back ends and products are respected, too.

But each server has different data sources, different grids, ...  
What happens when the user requests a comparison (difference) between sites?

FDS performs the regridding – allows the coordinate systems to look uniform

## Demanding (large) products may be created in “batch” mode

## I hate outlines

- Review
- What’s new
- What’s next

## LAS&GIS

- ArcIMS “back-end”to LAS

## 
LAS to respond to OGC protocols
WMS and WCS (maybe WFS, too) 
LAS UIs in the style of a GIS

GIS-friendly output products
ASCII Grid 
GeoTIFF
ShapeFiles

- LAS to respond to OGC protocols
- WMS and WCS (maybe WFS, too)
- LAS UIs in the style of a GIS
- GIS-friendly output products
- ASCII Grid
- GeoTIFF
- ShapeFiles

- LAS & GIS

**Notes:**
Really just another user interface ...

## Component Design for LAS Product Server

- servers

- UIS

- PS

- LAS XML configuration metadata

- BES

**commands**

**products**

- Legacy BE

- BES

- BES

- Legacy BE

- UIS = User   Interface Server
- PS = Product Server
- BES = Backend Server

- SOAP

- Remote BE

- SOAP(*)

- (*) not in initial version

- Browser UI
- (java/script)

- = areas of design change

**Notes:**
Easy for a single LAS installation to use different legacy applications for different output products
New output products for existing legacy applications can be created by adding only the command script and configuration information
Easier to install
Faster and simpler – NO SQL database needed
Forms the basis for the (unfunded) changes to accommodate security

## Current Product Server (Perl) splits intotwo components (Java)

Product Server
Parses and completes incoming requests
Provides logic for caching, batch, security, ...
May request products from more than one Back-end Servers  (compound products) 
Back-end server
Produces products using legacy apps or Web services
Isolated from LAS logic and configuration

Back-end request protocol utilizes JavaBeans exchanged via SOAP

- Product Server
- Parses and completes incoming requests
- Provides logic for caching, batch, security, ...
- May request products from more than one Back-end Servers  (compound products)
- Back-end server
- Produces products using legacy apps or Web services
- Isolated from LAS logic and configuration
- Back-end request protocol utilizes JavaBeans exchanged via SOAP

## Implementation Details

- Java Servlet based on the Anagram framework from COLA.
- Similar redesign was already planned to accommodate component design for security models
- Singleton instances of PS and BES classes in Servlet container means low memory and fast response
- Jakarta Axis SOAP framework

## Conclusion: “Configurable”

- _Adaptable to input data_
-  Models, satellites, *in-situ*
-  Local, distributed

- _Adaptable to output products_
-  scientific graphics
-  extracted subsets
-  analysis and comparison

## to conclude:the ecological niche of LAS ...

- “a configurable product server for 1 to 4Dgeo-science datasets”

- to conclude:the ecological niche of LAS ...

- not necessarily ‘optimal’, but ...
-  very flexible
-  community-integrated
-  supported (by others)

**Notes:**
Designed to handle hundreds of distributed datasets – thousands of variables

Here you see “By institution” on the NVODS server

## Who is using LAS?

*Who is using LAS?*

- US Federal agencies
- NOAA (PMEL, CDC, GFDL, NCDC, NGDC, NODC, NMFS, ...)
- NASA (NSIIP, Goddard DAAC, JPL, ...)
- Navy (FNMOC/GODAE, NAVO)
- DOE (LLNL, Oak Ridge)

- Research Institutions
- NCAR
- MBARI
- WHOI
- RSMAS
- URI/GSO
- JISAO
- IPRC
- COLA

- International
- France (IFREMER, Mercator, CNRS,              Aviso, Mersea, IPSL)
- UK (UK Met Office, NERC(*))
- Germany (Alfred Wegner Instuitute)
- Canada (Halifax harbor moorings)
- Australia (CSIRO)
- India (Center for Modeling and Simulation )
- http://www.ferret.noaa.gov/LAS

## Current (major) LAS projectsat PMEL ...

- REASoN (“thematic servers”)
- GODAE (ocean model inter-comparison)
- HYCOM (HYbrid Coordinate Ocean Model)
- OSMC (Observing System Monitoring Center)
- GFDL data portal (model output dissemination)
- Ocean CO2 *in situ* data management

## Thank you