The departments of Defense and the Navy have adopted a data sharing strategy that supports network-centric operations on the Global Information Grid (GIG). This strategy redefines interoperability from traditionally defined point-to-point interfaces between databases and applications, to a many-to-many data exchange where many users and applications may leverage the same data on the network.
This level of interoperability is generally made possible where data is made visible on the network, as well as discoverable and understandable through the addition of relevant metadata, for user accessibility. Such data management requires the collaborative efforts of communities of interested users who must exchange data.
The meteorological and oceanographic (METOC) community of interest (COI) has been actively addressing net-centric data management issues through the work of its Data Management Working Group.
The DMWG consists of data managers, subject matter experts and end-users from the Navy, Air Force, Army and Marine Corps; it operates under the governance of the Joint METOC Board. More recently, the National Weather Service and Federal Aviation Administration (FAA) joined the DMWG to address data interoperability issues between those federal agencies and the DoD.
The FAA, for example, has recently adopted the METOC COI data exchange standard, the Joint METOC Broker Language, as a key-enabling technology to exchange meteorological data with the National Oceanic and Atmospheric Administration (NOAA) and DoD for the Next Generation Air Transportation System.
Figure 1 outlines the DMWG's work toward net-centric operations. We began by developing the Joint METOC Conceptual Data Model (JMCDM). A conceptual data model generally describes significant concepts in a given domain and the relationships among them. Subject matter experts working with the DMWG developed JMCDM through collaborative sessions over the course of several years. The resulting model provides an organizational framework for a common understanding of METOC terminology and data attribution.
Once the JMCDM was complete, we began work on a physical data model. Unlike a conceptual model, a physical data model takes into account data organization within a database management system and may identify table structure, indexing, and other data organization elements.
We segmented the physical model by like data elements to provide data organization around high-level data types such as observations, climatology, forecasts and other categories. This resulted in 13 physical database segment models. Some service members of the community implement these physical models while others merely map their existing data stores to the models.
METOC production centers dynamically populate their data stores with perishable environmental data. This is a process in which they ingest, update, archive and delete data on a regular, real-time basis. The management of the data flow into and out of these data stores is performed by numerous data storage systems and data management applications in disparate locations and environments.
To avoid specific point-to-point interfaces for each of these data stores, we developed the data exchange standard interface known as the Joint METOC Broker Language.
JMBL is implemented in Extensible Markup Language (XML) and consists of a series of schema that define the structure of a request for METOC data and the structure of the associated response. JMBL allows each METOC data provider to offer a uniform interface for machine-to-machine access to METOC data on the GIG.
The JMBL schema are associated with a Web Service Definition Language (WSDL) file that lists the service provider's URL and available methods exposed through the service.
We designed JMBL sufficiently broad to be able to address the data needs of a broad range of users from the novice to trained METOC expert. For example, JMBL permits a user to define time and location relevant to needed data several different ways: five for time and four for location.
A METOC expert may require different combinations of these elements while the novice usually needs only one. Although this aspect of the design adds complexity to the interface, we have taken steps to make the complexity more manageable.
To assist the non-expert user, we have profiled the JMBL schema. Each profile provides a view of a subset of the larger JMBL schema and represents the minimum elements and attributes required to request each of the available METOC data types.
The limited choices in the profiles guide the novice to form a request for data. We have also documented the business rules for JMBL server implementations. The business rules help ensure that different servers provide consistent responses to requests that are similar in structure and content.
The DoD Chief Information Officer has established the DoD Metadata Registry (MDR) as a repository for structural metadata. We have registered JMBL, the WSDL file, JMCDM, and the physical data models in the Metadata Registry and have had JMBL admitted to the DoD Information Technology Standards Registry (DISR) as a mandated standard. The DISR mandates the minimum set of standards and guidelines for the acquisition of all DoD systems that produce, use or exchange information.
We have implemented JMBL data servers at the Naval Oceanographic Office (NAVO), Fleet Numerical Meteorology and Oceanography Center (FNMOC) and the Air Force Weather Agency. These implementations virtualize access to multiple data stores within each organization.
The METOC COI Service Bus (McSB) is currently under development and will further virtualize access to each data provider within the Navy METOC Enterprise, as shown in Figure 2. This single entry point will provide routing, orchestration, mediation and security services for data access from NAVO, FNMOC and other Navy data holder organizations.
If the user is authorized to receive the requested data, the server will split the user's request into fragments based on request content and provider rules. The server will forward each fragment to the appropriate data provider and then aggregate the separate provider responses before supplying a single response to the user.
This rules-based capability will deliver the warfighter's single, authoritative, accurate, timely and relevant METOC answer.
With our joint partners, we are defining the requirements for and design of a similar capability to support joint METOC operations. This is shown in Figure 1 as the Joint METOC Capabilities Access Point. JMCAP, together with Joint METOC domain authority rules and services definition, will virtualize access to multiple databases and data stores maintained by each of the services.
Our work on net-centric data management is not static but continues to evolve to address emerging requirements. We are currently evaluating how and when to integrate the Universal Core with JMBL.
UCore is gaining widespread attention as an information exchange specification and functional element of the "National Strategy for Information Sharing" (available at www.whitehouse.gov/nsc/infosharing/) that should prove useful in net-centric data management.
We have also begun a migration path to include Open Geospatial Consortium Web services standards and specifications. OGC WS is widely used for geospatial data access, and we believe that it will play a meaningful role in distribution of particular types of METOC data products.
The requirements we address often come from the varied communities with which we must exchange data. Our net-centric data management efforts continue to mature as we address the needs of each of these communities of interest.
Dr. Roy Ladner works for the Naval Meteorology and Oceanography Command, data architecture and administration (N62). He is a member of the METOC community of interest's Data Management Working Group.