# Presentation: 230501

## Architecture and Data Provider Roles

## 	Context

- Confusion of Influencing dynamics: Ocean.us, DMAC, IOOS PO, RAs, Local Missions
- Access to non-federal observations is critical to IOOS
- Scope: pursue in-situ physical and chemical measurements first.
- Simplest first.
- Foundational to the rest of the system (models & other information products).
- Demonstrates the capability to build/implement a system _~_ further investment.
- Will facilitate development of system components to handle dense grids
- We can make real progress in this area quickly thus supporting the idea for further development on the more difficult data types/structures.
- Where the DMAC and/or DIF documents provide a general architecture, this work will develop a refinement or specialization that will be appropriate for the regional and local arenas.
- DMAC standards process is not exclusive.
- The ideas/assertions put forth will be consistent with PO DIF, DMAC and have been educated by other meetings such as the St. Pete Meeting.
- Moving from local research/management stance to an operational stance.

## 	More Context

- We want to end up with real working transport of in-situ data.
- IOOS, DIF, and regional efforts may develop at different speeds.
- Local Data Providers are smaller and sometimes more agile
- Execution of these grants may precede the DIF design efforts.
- Regional and local efforts will likely do a little ice breaking for the DIF and will prove the validity and usefulness of an SOA.
- Currently, NDBC functions as a DAC.  With more time and resources, the federal level will expand the DAC functionality.
- Our efforts are intended to help develop architectural underpinnings that will help the DAC(s) flourish.

## 	and, a Little More Context

- Data transport is intended to support periodic updates to the aggregation facility. These should be discrete and periodic data requests, not, random requests of enormous size.
- A data provider is free to offer wider access according to their capacities and local needs.
- Serve only that data that you collected or have an explicit agreement to serve.
- Local Data Providers must be left to pursue their local missions.
- Workshop Flow of concepts:
- 	SOA->Architecture->Common Data Content->Semantic Interoperability (URN’s, Dictionaries, Vocabularies & Registries) ->
- 	Metadata/Discovery->
- 	Data Models and Frameworks->Schema and Encoding->
- 	Data Transport Mechanisms

## 	Architecture

- SOA based approach: data models, data transport, discovery....
- The system facilitates aggregation of a national (then global) view of the data.
- System requirements of the data provider are limited to the specification of the service layer.
- Service layer should be minimally invasive to data provider. The only requirement on the data provider’s IT architecture is that it is adequate to provide the specified service layer.

## 	Sequence 

- Local Observatory collects data following local missions
- Local Observatory either sends data to a common data provider or operates as a CDP.
- The term 'certified' is loaded due to history of RAs. We are using it in a generic sense.
- CDP implements regional data transport service requirements
- Establish a Registry of Services
- CDP registers with Registry
- Client requests list of available relevant services (w/in the RDT context). This is first for IOOS, then, if useful for other users/clients as the data provider sees fit.
- Client request data from each of the identified services.

## 	Registry of Services

- Registry is a registry of data services.
- Still undefined.
- Could be very concise:
- Organization Name
- Contact Information (email?)
- URL to service
- Possibly a list of available parameters
- Not unlike the ‘Observation Registry’ registry, like:

- <registrant>
-         <name>name of organization (CDP)</name>
-         <email>somebody[obfuscate email]some.server.edu</email>
-         <file_url>http://www.yourserver.edu/obsreg/obs.xml</file_url>
-         <regional_association>AOOS</regional_association>
- </registrant>

## 	Aggregation Center

- Provides access to historical holdings.
- Makes periodic small pulls of recent data to update aggregate holdings.
- Provides a broader view of data, geographic and/or parameter specific.
- Publishes data via a few standardized interfaces.

## 	Common Data Provider

- Fundamental to the architecture.
- There is not yet an authority to certify data providers .
- Provides data of ***defined*** ***quality and content*** via implementation of QARTOD QA/QC or similar.
- Publishes data via standardized service interface, schemata, and data types.
- Can be a local observatory and/or regional aggregation facility.
- Aggregates data from local observatories.
- Applies appropriate regional scale quality control to aggregate set.
- Develops and exposes metadata/documentation.
- Exposes data to local mission applications.

## Slide 11

## Flow : sensor=>  local observatory or certified data provider => aggregation facility =>       fed backbone

Early = sensor in the water to IT system on the hill.

Late = Certified Data Provider to aggregation facility or other user

- Early = sensor in the water to IT system on the hill.
- Late = Certified Data Provider to aggregation facility or other user

## 	IT Security 

- IT Security is implemented at every point in a service stack. Hardware, network architecture, operating system configuration and management, software server applications such as Web servers or servlet engines, applications that run in those environments. It is beyond the scope of this work to address specific applications except that a candidate technology should support the development and implementation of secure applications and that those applications developed must be the result of a deliberate examination of possible security issues.