4-Dimensional Weather Data Cube Web Coverage Service Reference Implementation (WCSRI) Architecture and Design

4-Dimensional Weather Data Cube Web Coverage Service Reference Implementation (WCSRI) Architecture and Design Version 2.0 01/15/2010 National Center for Atmospheric Research MIT Lincoln Laboratory National Oceanic and Atmospheric Administration/Global Systems Division DOCUMENT REVISION REGISTER Version Date 0.1 03/16/2009 Content Changes Preliminary draft Editors Contributors Rob Weingruber Aaron Braeckel 0.2 04/10/2009 Revised to support a system design template more closely tied to the WFSRI Design and Architecture Document Multiple other content refinements Aaron Braeckel 1.0 04/30/2009 Updated to be more similar in format and to include additional relevant content from WFSRI Design and Architecture Document v0.1 Incorporated comments from NNEW PO and labs Aaron Braeckel 1.1 12/8/2009 Initial draft of 2.0 document changes Updated to reflect design changes and experience gathered from implementing WCSRI 1.0, updated to reflect the current status of SWIM, and generally improved wording and content Aaron Braeckel 2.0 1/15/2010 Finalized revisions from 1.1 Aaron Braeckel Please direct comments or questions to: Rob Weingruber National Center for Atmospheric Research Research Applications Laboratory 3450 Mitchell Lane Boulder, CO 80301 weingrub@ucar.edu (303)497-2850 Aaron Braeckel National Center for Atmospheric Research Research Applications Laboratory 3450 Mitchell Lane Boulder, CO 80301 Rob Weingruber braeckel@ucar.edu (303)497-2806 Terms of Use – NNEW Documentation The following Terms of Use applies to the NNEW Documentation Use The User may use NNEW Documentation for any lawful purpose without any fee or cost Any modification, reproduction and redistribution may take place without further permission so long as proper copyright notices and acknowledgements are retained Acknowledgement The NNEW Documentation was developed through the sponsorship of the National Oceanic and Atmospheric Administration and the Federal Aviation Administration Copyright Any copyright notice contained in this Terms of Use, the NNEW Documentation, any software code, or any part of the website shall remain intact and unaltered and shall be affixed to any use, distribution or copy Except as specifically permitted herein, the user is not granted any express or implied right under any patents, copyrights, trademarks, or other intellectual property rights with respect to the NNEW Documentation No Endorsements The names, MIT, Lincoln Labs, UCAR and NCAR, may not be used in any advertising or publicity to endorse or promote any program, project, product or commercial entity Limitation of Liability The NNEW Documentation, including all content and materials, is provided "as is." There are no warranties of use, fitness for any purpose, service or goods, implied or direct, associated with the NNEW Documentation and MIT and UCAR expressly disclaim any warranties In no event shall MIT or UCAR be liable for any damages of any nature suffered by any user, or any third party resulting in whole or in part from use of the NNEW Documentation Table of Contents Part 1: Introduction PURPOSE DESIGN GOALS 11 Part 2: Proposed Software Architecture 13 ARCHITECTURE AND DESIGN OVERVIEW 3.1 14 SYSTEM ARCHITECTURE OVERVIEW 14 SUBSYSTEM DECOMPOSITION (MODULES) 16 4.1 WCSRI Tiers 16 4.1.1 Protocol Tier 16 4.1.2 Domain Tier 17 4.1.3 Data Source Tier .18 4.2 SUBSCRIBER MANAGEMENT 19 4.3 LOGGING .20 4.4 MONITORING 20 4.5 AUDITING 21 4.6 WCS PROTOCOL 22 4.6.1 4.7 GetCoverage “store” attribute .22 WCS PROTOCOL EXTENSIONS .22 4.7.1 Subscription-Specific Extensions 22 4.7.2 Extended Trajectory Operations 22 4.7.3 Coordinate Reference System Extensions .24 4.7.4 Units and Measures Extensions .25 4.7.5 Geographic Subsetting Extensions 26 HARDWARE/SOFTWARE MAPPING 4.8 27 SOFTWARE ENVIRONMENT 27 4.8.1 Programming Languages 27 4.8.2 Web Application Framework 27 4.8.3 Data Management 28 4.8.4 Build and Deployment 28 PERSISTENT DATA MANAGEMENT 29 5.1.1 Users/Roles .29 5.1.2 Coverages .29 5.1.3 Application Data .31 5.1.4 Lifecycle Data 31 ACCESS CONTROL AND SECURITY 6.1 33 ACCESS RESTRICTION 33 GLOBAL SOFTWARE CONTROL BOUNDARY CONDITIONS 35 34 APPENDIX A - ADDRESSED REQUIREMENTS APPENDIX B - ACRONYMS 40 APPENDIX C - DEFINITIONS AND TERMS 42 APPENDIX D - REFERENCES 43 36 Table of Figures Figure 4-D Wx Data Cube Components 10 Figure Overview of the WCSRI 3-tiered System 15 Figure Temporal Trajectory 23 Figure Temporal Trajectory CRS 24 Figure WCS Trajectory UML .24 Part 1: Introduction PURPOSE To satisfy the requirements of Next Generation Air Transportation System’s (NextGen) 4-Dimensional Weather Data Cube (4-D Wx Data Cube), it is envisioned that a number of components will comprise the physical solution The Next Generation Air Transportation System (NextGen) Network Enabled Weather (NNEW) Program has recommended the adoption of several standards to be used as part of that solution To provide a definitive interpretation of these standards, a production-quality implementation for operational parties, and a resource for operational data providers that choose to implement these standards differently, the NNEW Program will create reference implementations of key data distribution standards: the Web Feature Service and Web Coverage Service These reference implementations are developed and licensed in an open, standards-based fashion to allow broad usage High-level requirements for the 4-D Wx Data Cube have been established over the past several years by the Joint Program Development Office (JPDO) Documents describing these requirements include the “Concept of Operations for the Next Generation Air Transportation System [ i]" document, the “FourDimensional Weather Functional Requirements for NextGen Air Traffic Management [ ii]”, and others With these high-level requirements in mind, the lower level “NNEW IT CONOPS [ iii]” captured a set of 4-D Wx Data Cube requirements relevant to network-enabled weather The NNEW IT CONOPS document provides a representative set of use cases that are intended to aid system architects in understanding typical usages of the 4-D Wx Data Cube Though not exhaustive, the selection of use cases represents an attempt to ‘span the problem domain’, covering both functional and non-functional scenarios The NNEW Program also developed a WCSRI Requirements Document [Error: Reference source not found] that focuses more closely on implementation issues than the NNEW IT CONOPS document and includes further context and background This document describes the high-level interaction and design of the WCSRI based on requirements identified Requirements mentioned in this document that come from the WCSRI Requirements Document are shown in bold, similar to Requirement 1.2.3 These notes refer to the version of this Requirements Document indicated by [iv] This document describes the architectural aspects and design of the Web Coverage Service Reference Implementation (WCSRI), which is well suited for serving geographically filtered coverage data This document has two purposes: Describe the design of this phase of development in adequate detail to enable the development of the WCSRI This description will facilitate subsequent implementation and deployment phases of the 4-D Wx Data Cube Describe how the WCSRI technology will integrate with other technology components, such as the FAA System Wide Information Management Program (SWIM) and 4-D Wx Data Cube Web Feature Service Reference Implementation (WFSRI) Note: This document is intended to describe only high-level architectural and design concepts Implementation details are left to other forms of documentation Because the design and implementation of the WCSRI is iterative, this document addresses a subset of the total requirements of the WCSRI The initial design phase must precede implementation, but the design and implementation work may be considered to be on somewhat separate iterations after that point Therefore, the initial design work may enable several phases of implementation before further iteration is made on the design The requirements addressed by this document are listed in APPENDIX A ADDRESSED REQUIREMENTS Important Note: This document is not intended to describe the functionality included in any particular WCSRI release, merely the high-level design concepts that may be used as guidance in implementing the functionality once the appropriate WCSRI implementation phase is reached Additionally, this document describes architecture and design concepts for the WCSRI, but these concepts will almost certainly be adjusted as implementation progresses Apart from those included in the OGC WCS specification, some requirements are imposed on the WCSRI simply because it is intended to be a component within the 4-D Wx Data Cube This includes capabilities such as support for real-time data dissemination, flexible architectural configuration, infrastructure support for logging and monitoring, lifecycle management of data, and support for accident reconstruction In addition, the WCSRI must integrate with other 4-D Wx Data Cube components (see Figure 1) The 4-D Wx Data Cube’s WFSRI is intended to provide access to non-gridded data, and is relatively isolated from other 4-D Wx Data Cube components Therefore, it is not envisioned that integration between the WCSRI and WFSRI need occur However, the 4-D Wx Data Cube Registry/Repository will contain registry information about each WCSRI installation, such as coverage metadata and WCS service endpoints Therefore some level of integration must occur between the two, though no implication is made as to the specific direction of communication or dependency between the WCSRI installations and the Registry/Repository Figure 4-D Wx Data Cube Components The WCSRI will allow the Service Provider to configure the temporary file location, but the details of their management is likely to be hidden from Service Providers 5.1.2.1 Populating a Coverage’s Data Files The default backing store will consist of a single directory for each coverage that contains data for that coverage (the RUC model, for example) This directory will contain configuration information for the WCSRI behavior relating to that coverage (e.g., the WCSRI to WCSRI communication role or pattern), metadata relating to that coverage, and several nested directories with data file names that include information such as forecast generation time and valid time The information encoded in directory and file names will allow for the identification of each atomic coverage component The Service Provider will populate these directories with data files with the correct names, and these will be discovered by the WCSRI and made available to data consumers At some point an API may be provided to Service Providers for adding data to the WCSRI This approach to a backing store is efficient for ad-hoc subsetting requests that not cross many data files It is anticipated that the vast majority of requests will require only one file to be opened, which will allow fast lookups to satisfy requests Time series requests are examples of request types that are not quickly satisfied with this approach, but are almost certain to be less frequent than standard, filteredcoverage requests The implications of this approach are:  The Service Provider should not place files in the backing store with names recognized by the WCSRI until the files are completely written An example process to accommodate this would be: Service Provider receives a legacy data file, which is written to disk outside of the WCSRI’s root data directory Service Provider converts this file to a form that is readable by the WCSRI The converted file is placed in the appropriate coverage data directory, but with a name that is not recognized by the WCSRI as being part of the backing store (datafile.nc.tmp) Service Provider renames datafile.nc.tmp to datafile.nc, which is a valid file name that is recognized by the WCSRI This ensures that data availability is an atomic operation, and the WCSRI does not ever attempt to access a partially-written file WCSRI finds the new file and exposes it as part of the coverage  A single data “atom” is contained in a single file Data atoms are the smallest piece of data that is intended to be exposed by the WCSRI as it is received from upstream sources, which is highly dependent on how the data is naturally generated and/or distributed by these sources An atom in the case of forecast data might be a single forecast grid of a forecast run (a single forecast/valid time combination) The RUC forecast dataset includes many fields (air temperature, dewpoint, and others) which are all released as a single forecast An atom in this case would be a single file that contains all of these fields, since they are being distributed as a single forecast An atom in the case of radar data might be a single 360 degree scan volume These atoms are coverage- specific, and one source of radar data may require a different data atom than another If data quality information is generated or distributed with a grid, it may also be exposed as part of an atom Therefore, each Service Provider is responsible for populating the backing store with appropriately named and located data files Each coverage directory includes metadata, coverage-specific WCSRI configuration, and data files, and the WCSRI will monitor and change behavior appropriately when configuration files are modified 5.1.2.2 Temporary Files The WCSRI will temporarily write to a directory on disk to enable several subsetting cases and other operations While every operating system defines a temporary directory, this directory may or may not be sufficient or desirable to use as the WCSRI temporary directory because of data volumes, access restrictions, or Service Provider policies For example, the default OS temporary directory may be on a lower speed disk, or may be on a disk partition that is of insufficient size to support large gridded files Therefore, the central WCSRI configuration will include an option to specify a temporary directory 5.1.2.3 Data Formats The Java NetCDF API [vi] will be utilized to access files in the backing store The NetCDF API provides an abstraction layer above that of a particular file format, as well as implemented support for GRIB, NetCDF 3, NetCDF 4, and a number of other file formats Any data file that is readable through the Java NetCDF API as a grid feature type may be used as a data file in the backing store When responding to data requests, the WCSRI will return Climate and Forecast convention-compliant NetCDF files as the primary protocol/exchange format The WCSRI will also have support for GRIB 2, but the exact extent of this support has not yet been determined 5.1.3 Application Data For the WCSRI, the Application data represents the collection of coverage instances Each application or service provider can expose the desired coverages by adding a new directory to be scanned in the WCSRI configuration 5.1.4 Lifecycle Data The deletion of old data no longer useful to data consumers is an example of a lifecycle policy, and is commonly referred to as scrubbing Scrubbing policies are configurable on a per-coverage basis, and includes information such as:  Policy (Data Range, Action): This defines the range of the coverage instances as a function of time and the action to be performed on the data Every policy must have at least two stages, with a current stage defining the data that is to be considered current and a final stage which defines the data that is to be considered stale or old on which some end of life action can be performed Policies may define any number of interim stages Currently proposed actions include: NOP (do nothing), Archive (archive data), and Delete (remove data)  Execution Frequency: The frequency with which the lifecycle checking and conformance should be performed ACCESS CONTROL AND SECURITY There are two major categories of security concern: those that change with the security environment and those that are uniform for every environment An example of a concern that is uniform across all security environments is data validation This is logic that is very specific to a particular protocol and/or request type and must take place at least partially in protocol modules and the domain tier Data validation is a universal need, and this will not be configurable An example of a security concern that does need to adapt to a variety of security environments is authorization and authentication Different Service Providers have greatly varying needs for securing particular functions and coverages, and it is therefore desirable that access restriction be highly configurable This includes restricted access to particular coverages The WCSRI uses a layered authorization strategy, with coarse-grain authorization being handled by implementing role-based security mechanisms on top of standard FUSE role management technologies As central SWIM security mechanisms are put in place, they will be adopted Until this time, standard FUSE access mechanisms will be sufficient Fine-grained access to coverages will be handled at the database level wherein user privileges will be checked against the capability matrix stored as part of the User Database and set up by the Service Provider Given that the 4-D Wx Data Cube functionality requires both secured and unsecured communications for different classes of use, default “anonymous” users will be set up 6.1 ACCESS RESTRICTION Role-based access restriction will take place on several fronts: Coverage – determines which roles have access to any data from a coverage Maintenance – determines which roles have remote access to maintenance information, which includes monitoring information and web application control mechanisms (such as those provided by FUSE to start or stop services) This only includes remotely accessible maintenance information and updates Those that are accessible or handled through configuration files are assumed to be secured by standard operating system user management mechanisms Provider – determines which users have administrator privileges to allow them to manage the configuration of the WCSRI GLOBAL SOFTWARE CONTROL It is envisioned that all sub-systems of the WCSRI will run within the same process, using a threaded control flow paradigm to increase response time and throughput of the overall system BOUNDARY CONDITIONS This section outlines the administrator use cases that need to be considered and planned for These include:    Startup of the WCSRI Shutdown of the WCSRI Exception Cases: for handling failures APPENDIX A - ADDRESSED REQUIREMENTS This section lists the requirements from [Error: Reference source not found] that are at least partially addressed by this version of the document Requirement Number Requirement Description 4.1.1 The WCSRI shall provide the capability for the Service Provider to specify the available coverages or datasets that will be served by the WCSRI 4.1.2 The WCSRI shall provide the capability for the Service Provider to configure the following for each dataset offered by the WCSRI: A unique identifier for the coverage Name of the coverage The directory for the coverage data files Descriptive metadata for the dataset 4.1.3 The WCSRI shall provide the capability to serve virtually aggregated datasets 4.1.4 The WCSRI shall provide configuration capability for required information regarding the files that comprise an aggregated dataset, such as file storage directories, file names and geographic extents (in the case of tiling) The WCSRI shall provide a lifecycle management system that will delete data beyond a certain time period or archive data for a specified period of time 4.1.5 4.2.1 4.2.1.1 The WCSRI shall allow subsetting by zero or more fields (e.g., temperature, reflectivity) If no fields are indicated, all available fields shall be returned The WCSRI shall support geometric subsetting of coverage volumes, including the following:  3-D Volume For this case, a 3-Dimensional bounding box may be specified with dimensions defined by X, Y, Z value (such as longitude/latitude/altitude) ranges The result is a 3-Dimensional rectilinear volume  Horizontal 2-D Cross-section If a constant altitude level is specified, a horizontal (latitude/longitude) slice will be taken through the coverage volume  Vertical 2-D Cross-section For this case, a vertical slice is taken through a coverage volume The path for the cross-section is defined by a set of XY waypoints and a sample density  Sounding A coverage volume may be subsetted by requesting a vertical column of data whose location is specified by a latitude/longitude point  1-D Point A coverage volume may be subsetted by requesting a single point specified by X, Y, and Z values  Trajectory A coverage volume may be subsetted along a trajectory, or a 3-D path, by specifying the latitudes, longitudes, and altitudes of two or more ordered waypoints The returned coverage will be a “line” of data along a 3D path, where the geo-locations of the interpolated data points are determined with either Euclidean or Great Circle geometry  Corridor A coverage volume may be subsetted by extruding a rectangular area along a trajectory A rectangular cross-section, orthogonal to and along a trajectory can be extracted from the coverage volume by specifying the two or more ordered waypoints, the vertical range and the horizontal range This rectangular cross-section is a corridor In addition, this is a superset of the horizontal and vertical cross-sections, and may be used for cross-section subsetting 4.2.3.1 The WCSRI shall be capable of providing a list of valid times from datasets that are temporally aggregated 4.2.3.2 The WCSRI shall provide the capability to constrain coverages by requesting a single valid time 4.2.3.3 The WCSRI shall provide the capability to constrain coverages by requesting a range of valid times 4.3.2 The WCSRI shall expose CF-NetCDF4 as a file format at the interface level 5.1 The WCSRI shall support the WCS version 1.1 specification 5.2 The WCSRI shall be designed in a manner such that future WCS specification versions are supported through a pluggable protocol layer 5.3.1 The WCSRI shall support Key-Value Pair (KVP) encoding over http GET for the GetCapabilities operation 5.3.2 The WCSRI shall support Plain Old XML (POX) encoding over http POST for the GetCapabilities operation 5.3.3 The WCSRI shall support Simple Object Access Protocol (SOAP) encoding over http POST for the GetCapabilities operation 5.3.4 The WCSRI shall support the Sections and AcceptFormats parameters 5.4.1.1 The WCSRI shall provide a means for the Service Provider to statically configure metadata describing the server for the following GetCapabilities elements: ServiceIdentification, ServiceProvider, OperationsMetadata and Contents 5.4.3.1 The WCSRI shall provide a means for the Service Provider to configure the path for storing temporary files and scrubbing instructions (e.g., maximum file age) for stored request results and other temporary file purposes 5.4.4.1 The WCSRI shall provide the capability to determine the following, on a percoverage basis, either through programmatic means or Service Provider configuration: 5.4.4.2  Unique Coverage Identifier  World Geodetic System 1984 (WGS84) Bounding Box for the coverage  Supported coordinate reference systems (CRS), including geographic projections, vertical and compound  Native CRS The WCSRI shall support “application/x-NetCDF” as the value for the supportedFormat attribute This is the Multipurpose Internet Mail Extensions (MIME) type for CF-NetCDF4 binary coverage data 5.5.2 For the DescribeCoverage operation, the WCSRI shall support SOAP encoding over HTTP POST 5.7.2 For the GetCoverage operation, the WCSRI shall support SOAP encoding over HTTP POST 6.1 The WCSRI installation shall include, at a minimum, a description of the procedure for adding and removing offered coverage types, and updating the metadata for those coverage types 6.1.1 The WCSRI shall provide a low-latency means to distribute filtered data (such as geometric and temporal subsets) to interested data consumers The mechanism used here shall be consistent with what is used by other 4-D Wx Data Cube fundamental components, such as the WFSRI, to distribute filtered data 6.5.1 The WCSRI shall provide remotely accessible monitoring information relating to the configuration status, WCSRI service status, health of upstream and downstream WCSRI node interactions, dataset availability, data storage size, data availability, data scrubbing information, web service request counts, web service performance, and error tracking/reporting This capability shall be configurable to permit different levels of monitoring detail and will leverage the SWIM monitoring infrastructure 6.6.1 The WCSRI shall provide auditing capabilities that allows an authorized client to gather historical (i.e., 15 days minimum) information regarding system usage and health This information will include request/response details Note: These capabilities may leverage those provided by the SWIM infrastructure 6.7.1 The WCSRI shall provide the capability to configure the level of logging and specifics as to what is logged Note: This will be consistent with SWIM infrastructure and other 4-D Wx Data Cube components 6.8.1 The WCSRI shall perform stringent data validation for communications, including but not limited to requests for data and messages/notifications sent from upstream nodes 6.8.3 The WCSRI shall provide configurable role-based access to WCSRI web service endpoints Implementation of this requirement will leverage SWIM infrastructure security solutions 6.8.4 The WCSRI shall provide configurable role-based access to WCSRI-offered coverages and their data fields Implementation of this requirement will leverage SWIM infrastructure security solutions 7.1 The WCSRI shall implement infrastructure capabilities in a manner compliant with the SWIM service container, and shall leverage SWIM mechanisms wherever appropriate 7.2 The WCSRI installation shall include WSDL definitions of the web services that it provides 7.3 The WCSRI shall support the deployment and installation of the WCS operations (e.g., GetCapabilities, DescribeFeatureType, GetFeature into the SWIM service container, either through installation scripts or documentation for Service Providers 8.2 The WCSRI shall run on Linux and Windows platforms APPENDIX B - ACRONYMS API CITE CONOPS CF CRS DOD ESB FAA FTI FUSE GSD HTTP IOC ISO IT JMBL JPDO METOC MIME MIT NAS NextGen NCAR NNEW NOAA OGC OPeNDAP POX RAL RUC SAS SOAP SWIM TAF UOM URI URL URN WCS WCPS application programming interface Compliance & Interoperability Testing & Evaluation Concept of Operations Climate and Forecast coordinate reference system Department of Defense Enterprise Service Bus Federal Aviation Administration Federal Telecommunications Infrastructure An open source Enterprise Service Bus (ESB) The SWIM Container Global Systems Division Hypertext Transfer Protocol Initial Operating Capability International Organization for Standardization information technology Joint METOC Broker Language Joint Program Development Office Meteorological and Oceanographic Data Multipurpose Internet Mail Extensions Massachusetts Institute of Technology National Airspace System Next Generation Air Transportation System National Center for Atmospheric Research NextGen Network Enabled Weather National Oceanic and Atmospheric Administration Open GeoSpatial Consortium Network Data Access Protocol plain-old-XML Research Applications Laboratory Rapid Update Cycle Single Authoritative Source The technology formerly known as Simple Object Access Protocol System Wide Information Management Terminal Aerodrome Forecasts Unit(s) of measure Uniform Resource Identifiers Uniform Resource Locators Uniform Resource Names Web Coverage Service Web Coverage Processing Service WCSRI WGS84 XML Web Coverage Service Reference Implementation World Geodetic System 1984 Extensible Markup Language APPENDIX C - DEFINITIONS AND TERMS 4-Dimentional Weather Data Cube – A virtual entity comprised of a federation of distributed weather data sources, which provides a common source of weather information to all users of the NAS Coverage – A conceptual dataset representing a single gridded data product, which may be composed of several different data files and fields, and may pertain to a general time range A dataset Dataset – May be composed of several files or a time series of data, that comprise a single logical product Examples include RUC, Icing/CIP, GOES satellite imagery, etc This is equivalent to the ISO 19115 “Dataset series” terminology Initial Operating Capability – The 4-D Wx Data Cube Initial Operating Capability This includes an initial (not CONUS-wide) operational demonstration of capability Subsequently a full CONUS-wide deployment will take place Offered Coverage – A high level dataset/coverage offered by a particular WCSRI installation Open Geospatial Consortium – A standards organization that is leading the development of standards for geospatial and location based services Registry/Repository – The registry/repository reference implementation for the 4-D Wx Data Cube Service Provider – An entity (a person or organization) that hosts an installation of the WCSRI, and is the original provider of zero or more datasets United States National Airspace System – The national aviation system of the United States of America It is a large operational system, and as such includes strict operational requirements relating to security, quality of service, and related critical infrastructure Web Feature Service – A service standard developed by the Open Geospatial Consortium that encompasses a standard protocol for accessing feature-based (typically non-gridded) data APPENDIX D - REFERENCES i [] JPDO, “Concept of Operations for the Next Generation Air Transportation System”, Version 2.0, June 2007 ii [] JPDO, “Four-Dimensional Weather Functional Requirements for NextGen Air Traffic Management”, Version 0.1, January 2008 iii [] NNEW, “NextGen Network-Enabled Weather – IT CONOPS”, Version 3.2, August 20, 2008 iv[] NNEW, “4-Dimensional Weather Data Cube Web Coverage Service Reference Implementation Requirements”, Version 1.2, February 27, 2009 v [] Fowler, Martin et al Patterns of Enterprise Application Architecture, Addison-Wesley, 2002 vi [] The NetCDF Java Library Home http://www.unidata.ucar.edu/software/netcdf-java/ ... aspects and design of the Web Coverage Service Reference Implementation (WCSRI), which is well suited for serving geographically filtered coverage data This document has two purposes: Describe the design. .. Uniform Resource Locators Uniform Resource Names Web Coverage Service Web Coverage Processing Service WCSRI WGS84 XML Web Coverage Service Reference Implementation World Geodetic System 1984 Extensible... Program (SWIM) and 4-D Wx Data Cube Web Feature Service Reference Implementation (WFSRI) Note: This document is intended to describe only high-level architectural and design concepts Implementation