2. Technical Reference Model

Technical reference models (TRMs) are used to organize discussion of a technical architecture and serve to highlight the interfaces borne by services in an information system. They do not show physical components or connections, nor do they show software modules or aspects of software implementation.

In the UTA, TRM content is discussed in terms of application and service categories. Specific interfaces will not be described in this section, as they are addressed in the remainder of this document. This section will emphasize the USIGS view of components, or entities, their derivation, and their definition.

Rather than develop a TRM unique to USIGS, the USIGS extends an existing reference model, namely, the DoD TRM. The DoD TRM, as described in [JTA98], defines the current technical environment within which the USIGS must exist. This section highlights the ways in which this TRM has been extended for USIGS to address the specific needs of the Imagery & Geospatial Community (IGC). The extended reference model has two purposes. The first, more general, purpose is to provide a roadmap to guide USIGS from the legacy, procedurally-based systems of today to an object-oriented environment characterized by distributed services and standardized interfaces. The second, more specific, purpose is to organize subsequent discussion of the standards, conventions, and guidelines that are applicable to the USIGS and presented in Sections 3, Sections 4, and Sections 5 of the UTA.

2.1 Operational Context

Figure 2-1 shows the operational context for the UTA and the reference model. The USIGS Technical Architecture provides the means by which a functionality or process identified in the operational architecture is translated into services and APIs in the Technical Architecture.

Figure 2-1. The Technical Architecture Translates Business Processes into Services and Their APIs

Further refinement of each of the business processes will identify services necessary for the brokering and trading of MCG&I information. These services can be organized based upon existing and future capabilities of the USIGS System Architecture. The services and APIs are used in the system architecture for the definition of systems and the applications that make up those systems (Figure 2-2). In the context of USIGS, required services are used to construct applications (Mission Area Applications) analogous to the selection of tools from a toolbox. The Mission Area Applications are defined and organized to satisfy the USIGS mission. The services are derived from the functionality requirements defined in the Operational Architecture and are built or procured ONCE, then re-used as needed across the USIGS environment. Each service (COTS or GOTS) has an associated API or set of APIs which standardizes the interface to that service, thus promoting the "plug-n-play" concept envisioned for USIGS.

Figure 2-2. The System Architecture Uses Services and APIs Identified in the Technical Architecture in Defining Systems, Applications, and Facilities

2.2 DoD Technical Reference Model

The DoD Technical Reference Model (TRM) is defined in the TAFIM Version 3.0 [TAFIM96]. Version 2.0 of the JTA uses this TRM to establish a framework for its discussion of information technology (IT) standards. The DoD TRM defines 1) an Application Software Entity that includes both Mission Area and Common Support Applications; 2) an Application Platform Entity that contains the system support services and operating system services; 3) an External Environment; and 4) common interfaces for invoking these services and applications. The seven major service areas within the Application Platform Entity are: Software Engineering, User Interfaces, Data Management, Data Interchange, Graphics, Communications and Operating System Services. The DoD TRM is presented in Figure 2-3.

The JTA allows for the use of either the Distributed Computing Environment (DCE) standards or the Common Object Request Broker Architecture (CORBA) family of specifications for distributed computing services. This choice of distributed computing environments is based upon a choice between procedural computing or object-oriented computing. NIMA has determined that the preferable paradigm for future USIGS application interoperability is an object-oriented paradigm based on the CORBA specification. The "to-be" USIGS System Architecture is based upon the distributed object computing model. This is consistent with industry and technology trends toward modularized, component architectures. CORBA, which includes the object request broker (ORB) and a set of object services (CORBAservices), is the core of Object Management Group's (OMG's) Object Management Architecture (OMA). The OMA also includes additional services or common facilities called CORBAfacilities [CORBA97b] that belong in the Application Software Entity part of the TRM.

Figure 2-3. DoD Technical Reference Model

The unique functionality needs of the IGC are expressed in terms of USIGS Mission Area Application (MAA) categories and [geospatial] domain objects, collectively referred to as MCG&I services. In addition to the MAAs and domain objects, USIGS will make use of common facilities and object services to enable a distributed, object-oriented computing environment.

Based on the foregoing discussion, Figure 2-4 shows an extension to the DoD TRM that highlights the addition of USIGS MAA categories, domain objects (MCG&I services), and common facilities (CORBAfacilities) to the Application Software Entity. The object services (CORBAservices) are part of the Distributed Computing Services in the Application Platform Entity. Domain objects and common facilities, while actually common "components" (applets, plug-ins, beans, etc.) rather than traditional "applications", are shown in the Support Applications category. Note that MAAs, domain objects, and common facilities are completely independent of the underlying platform.

Figure 2-4. The DoD TRM Extended for USIGS

Each service area of the extended reference model will now be discussed in turn.

2.2.1 Mission Area Applications

Each USIGS MAA category is a normalized set of applications, and the categories collectively represent, at a high level, the functionality required to achieve the USIGS mission. The MAA categories are not applications themselves, but represent broad functional areas that in turn may comprise one or several mission applications. Mission applications are, typically, custom-built computer programs or scripts with which the user interfaces, to perform specific tasks related to a specific mission. As a rule of thumb, mission applications in USIGS are typically client-side components that invoke other components to deliver the required services. This entity type is based upon the Defense Information Infrastructure (DII) Common Operating Environment (COE) view, wherein an application is considered to be mission specific if it:

• Is used to support a specific military mission (e.g., maritime, land, Joint/CINC/Coalition, air, intelligence), or
• Provides user services for "vertical markets" within the DoD (e.g., MCG&I information production)

The USIGS MAA categories were determined through careful examination of the NIMA Business Plan and co-referenced with the USIGS Operational Architecture. Each element of the NIMA Business Plan Model represents a combination of functionality that can be represented by one or more MAA categories. The categories are not limited to those defined below, but can evolve/mature over time as the "to-be" System Architecture takes shape.

NIMA has currently identified ten MAA categories, as shown in Figure 2-4. Table 2-1 provides a brief description of each category and identifies the applicable USIGS element for each category.

Non-mission-specific applications that deliver services that are of general use (e.g., word processing, spreadsheets, etc.) are another category in the application part of the extended reference model. These applications are also described as "cross-domain" because they provide general support across multiple mission areas. These types of applications relate to the DII COE concept of Common Support Applications (see Appendix B).

USIGS Element	MAA Category	Description
Management	Order Entry & Tracking	Applications to accept, process, track, and support delivery of information, products, and services
Management	USIGS Workflow Management	Applications that manage information production processes
Archive & Dissemination	Information Storage	Applications that provide for digital storage and retrieval of formatted products and seamless data
Archive & Dissemination	Information Delivery	Applications that accept, store, and execute information interest profiles to deliver required information
Archive & Dissemination	Information Discovery & Retrieval	Applications to navigate the USIGS to locate and retrieve information, products, and services
Archive & Dissemination	Information Reproduction & Replication	Applications that generate, reproduce, and replicate digital products
Exploitation & Production	Data Preparation	Applications that: - Open, view, and enhance MCG&I products and information - Assemble, evaluate, validate, and augment geospatial source material
Exploitation & Production	Data Exploitation	Applications that search, integrate, extract, analyze, and prepare multiple types of geospatial information
Exploitation & Production	Information Generation	Applications that: - Generate MCG&I information, services, and products - Perform information quality control
Exploitation & Production	Exploitation Support	Applications that: - Display/manipulate geospatial information - Control tasking and data flow - Collect/report status

2.2.2 Domain Objects

Some applications deliver services that are specific to an information domain (such as the MCG&I domain, logistics, telecommunications, etc.), yet are invokable by applications in multiple information domains. In the context of the extended reference model, these domain services are provided via "Domain Objects," which are software components that provide a necessary service (see Figure 2-5) into which the Geospatial Domain Services themselves are collected for ease of reference and discussion. Detailed definitions of the MCG&I services are provided in Appendix A.

In a component-based architecture, such as the USIGS, these business objects are based upon standardized interfaces and provide services that can be invoked in common by applications in multiple information domains. As USIGS moves toward a true object-oriented environment, the objects providing domain services will be more appropriately described as "components" ("beans," applets, plug-ins, etc.) rather than "applications." These components will be invoked by other components that reside on USIGS clients.

Figure 2-5. USIGS MCG&I Domain Services

The MCG&I services are described in Table 2-2.

MCG&I Service	DESCRIPTION
Feature Generalization Services	Services that modify the characteristics of a feature collection to increase the effectiveness of communication by counteracting the undesirable effects of data reduction
Geospatial Annotation Services	Services to add ancillary information to an image or a feature in a Feature Collection (e.g., by way of a label, a hot link, or an entry of a property for a feature into a database) that augments or provides a more complete description
Geospatial Coordinate Transformation Services	Services for converting geospatial coordinates from one reference system to another
Geospatial Display Services	Services that prepare and render one or more Feature Collections or Coverages to an output device. The output device may be a (temporary) electronic display or (permanent) hardcopy printer (e.g., printing a map or chart)
Geospatial Domain Access Services	A set of interfaces for locating, retrieving and disseminating selected geospatial products from a geographic information system (GIS) and for updating the contents of a GIS (by storing, deleting, or modifying geospatial products)
Geospatial Feature Analysis Services	Services that exploit information available in a Feature or Feature Collection to derive application-oriented quantitative results that are not available from the raw data itself
Geospatial Information Extraction Services	Services supporting the domain functional areas of imagery exploitation, mensuration and geo-positioning, and tactical terrain analysis
Geospatial Symbol Management Services	Services for management of symbol libraries
Imagery Exploitation Services	Services that support the photogrammetric analysis of remotely sensed and scanned imagery, and the generation of reports with respect to the results of the analysis
Image Geometry Model Services	Support using mathematical models of image geometries, that relate image positions to corresponding real-world (e.g., ground) positions
Imagery Manipulation Services	Services for manipulating images (resizing, changing color and contrast values, applying various filters, manipulating image resolution, etc.) and for conducting mathematical analyses of image characteristics (computing image histograms, convolutions, etc.)
Image Map Generation Services	Services for manipulating and combining images for use as image maps and other uses
Image Synthesis Services	Services for creating or transforming images using computer-based spatial models, perspective transformations, and manipulations of image characteristics to improve visibility, sharpen resolution, and/or reduce the effects of cloud cover or haze
Image Understanding Services	Services that provide automated image change detection, registered image differencing, significance-of-difference analysis and display, and area-based and model-based differencing

This list of MCG&I services is consistent with and based upon the Open GIS Services Architecture being developed by the Open GIS Consortium, Inc. (OGC). It represents a suggested taxonomy of functionality relevant to the broad MCG&I domain to include government and commercial industry alike. This government/industry synergy is being maintained in order to promote the commercialization of both products and APIs necessary to support the USIGS. This is consistent with the DoD emphasis on the use of Commercial Off-the-Shelf (COTS) products and open, interoperable systems. To the maximum extent possible, COTS products and open, non-proprietary interface specifications will be used to support the needs of the USIGS. Where unique functionality is required that is not supported by current vendor offerings, this functionality will be provided by Government Off-the-Shelf (GOTS) applications (e.g., MINT and RULER). Common interfaces (such as the current GIAS and GIXS) will be developed to support access to these GOTS services from anywhere across the distributed USIGS environment. NIMA will strive to support formal standardization processes for these interfaces through established standards bodies and the commercialization of such interfaces through consortia such as the OMG and the OGC. Note that some of the defined "services" such as annotation or display may stay tied to the client-side application and not be "broken-out" as individual, distributed services.

MCG&I services may be of two levels of applicability (Figure 2-6): producer-unique and general. Certain of the USIGS applications will apply only to producers. Correspondingly, certain MCG&I services will provide capability that will be shared among producer applications, but will have no applicability elsewhere (for example, certain intelligence oriented services). There will be a second level of MCG&I services that are generally available across the USIGS information domain and with applications in other information domains that require some MCG&I services. From the viewpoint of USIGS, there will also be business objects made available (to USIGS applications) from other information domains and general business objects that are non-domain specific.

Table 4-2 lists services from other domains (such as Healthcare and Finance) that are judged to be of use across USIGS.

2.2.3 Common Facilities

Common Facilities are components that are invoked by application programs in order to provide a specific service or set of services that are of general utility. In the USIGS extended reference model, common facilities are taken from the OMG OMA, because they are built on CORBA. Figure 2-7 lists those facilities currently identified by OMG. As the Interface Design Language (IDL) specification for each facility is completed and published, it will be thoroughly evaluated. Those that are found to meet the requirements for the USIGS will be adopted as USIGS components.

Figure 2-6. Common Support Application Applicability Layers

Figure 2-7. USIGS Common Facilities

A description of each CORBAfacility follows in Table 2-3.

CORBAfacility	Description
Common Management Facility	Provides a set of utility interfaces for system administration functions. These abstract basic functions such as control, monitoring, security management, configuration, and policies that are needed to perform systems management operations, such as adding new users, setting permissions, installing software, and so forth.
Compound Presentation and Interchange Facility	Enables the creation of cooperative component software that supports compound documents, that can be customized, that can be used collaboratively, and that is available across multiple platforms. Also provides for the storage and interchange of data objects, and roughly maps to the persistent storage subsystem of a compound document architecture.
Control and Management of Audio/Video Streams	The Control and Management of Audio/Video Streams specification addresses these issues: topologies for streams, multiple flows, stream description and typing, stream interface identification and reference, stream set-up and release, stream modification, stream termination, multiple protocols, quality of service, flow synchronization, interoperability, and security.
CORBA Component Model	This distributed component model will be based upon the OMA, and will be capable of inter-operating with other emerging component technologies, particularly the JavaBeans component model.
CORBA Scripting Language	Defines conventions and interfaces that allow access to the key functionality of an object from another object. The design goal of this facility is to support user visible objects that are larger grained than the typical ORB object. The typical object acted upon by this facility would be a document, a paragraph, a spreadsheet cell, and so forth. The emphasis of the facility is for objects to expose enough of their capabilities so they may be driven by scripts and macros.
Data Interchange Facility	Allows for the exchange of information across networks of heterogeneous computer systems by providing a common information model and a common way of encoding information within that model. Encoding must support not only character data, but other sorts of data as well, including imagery, graphics, multimedia documents, and electronic mail. Enables objects to interoperate through exchange of data, and can be used for many forms and kinds of data transfer, such as: bulk transfer; interchange of formatted data such as TIFF, GIF, EPS, NITF, etc.; structured data transfer such as ISO IDL specified data types; interchange of domain-specific object representations; and the data interchange between objects and encapsulated software (legacy applications).
Information Storage and Retrieval Facility	Comprises the higher level storage and retrieval specifications for distributed applications. These specifications will be applicable to a wide range of information services, including data base access and information highways.
Internationalization and Time Operations Facility	Enables developers to use an information system or application in their own language using their own cultural conventions. In addition, this technology will allow the developer to use a culture's numeric and currency conventions, and keep track of time zones.
Meta Object Facility	Defines the interfaces and sequencing semantics needed to create, store and manipulate object schemas that define the structure, meaning, and behavior of other objects within the OMG Object Management Architecture. These objects may be application objects, common business objects, objects representing analysis and design models of applications, or objects providing the functionality of Common Facilities and Common Services. The Meta Object Facility can be used in an information system (such as a repository) that enables an enterprise to specify and manage a wide variety of information assets with a common, integrated set of services. The use of a common Meta object facility for specifying the schemas of the information assets will play a key role in helping to achieve data and process integration by enabling tools and processes to share information and coordinate activities.
Mobile Agents Facility	Supports the need to create massively distributed information systems over Wide Area Networks. Agent technology efforts range from building these massively distributed systems to mobile information systems, intelligent workflow systems, and agile corporation information structures.
Printing Facility	One component of a coordinated set of facilities and standards needed to satisfy the printing requirements of the modern distributed office. Together, the capabilities provided must enable users to create and produce high-quality documents in a consistent and unambiguous manner within a distributed object environment. The Printing Facility should be able to meet a range of printing requirements from simple one document, one copy printing, all the way up to high volume production printing, which might involve several documents, several copies, several printers.
Rendering Management Facility	Provides facilities to present information for output on devices such as screens, printers, plotters and sound and speech output devices. It also handles user input from a variety of hardware devices such as a mouse, keyboard, scanner, speech recognition device, digital camera, and security devices. Rendering management includes support for window management, class libraries for user interface objects, user interface dialog objects, and abstractions of the many different input/output devices.
Security Administration Facility	Provides standard interfaces, as well as the necessary control mechanisms, to facilitate required security protections, including provisions for: - User registration, password maintenance, permissions maintenance - Access control, authentication, and audit trail maintenance - Resource registration - Security classification downgrading - Encryption key management - Discretionary and mandatory access control.
Stream-based Model Interchange	A stream-based model interchange format (SMIF) that includes a transfer format specification for file export/import of models, and a transfer format specification for unique identification of the version of the MOF meta-metamodel and any metamodels referenced but not included in an SMIF-compliant transfer.
System Management Facility	A profile of the Open Group's Systems Management Reference Model; consists of three basic components: Managers, which implement Management Tasks and other composite management functions; Managed Objects, which encapsulate resources; and Services, which provide the X/Open System Management (XSM) Support Environment.
Unified Modeling Language	A comprehensive modeling language whose semantics include these elements: Model management; Foundation (core, extension mechanisms, auxiliary elements, and data types); and Behavioral elements (use cases, state machines, collaborations, and common behavior). The specifications are packaged so that subsets of the Unified Modeling Language (UML) and facility can be implemented without breaking the integrity of the language.
Workflow Management Facility	Provides management and coordination of objects that are part of a work process (for example, purchase orders). This facility will provide support for production-based workflow in the form of structured, pre-defined processes that are governed by policies and procedures, as well as ad-hoc, or coordination-based workflows, including evolving workflows defined by one or more people to support the coordination of knowledge workers.

2.2.4 Distributed Object Computing Services and Other Platform Services

Distributed Object Computing Services are capabilities that permit procedures and objects to be invoked on remote hosts as though they were local to the calling module. In addition to these basic capabilities, the distributed computing component is accompanied by a variety of enabling services, such as security, time, persistence, and naming; many of these services are required for the development of applications that are distributed. The choice of CORBA responds to the need for object services; APIs for such services have been defined by the OMG in its CORBAservices specification [CORBA97c]. In a CORBA environment the integral object request broker (ORB) acts as an intermediary between invoking and invoked objects. In essence, the ORB acts as a software backplane. Mission Applications invoke Common Support Applications, Common Facilities, and Object Services via the ORB. Common Support Applications and Common Facilities can invoke other Common Support Applications and Common Facilities, as well as Object Services, via the ORB. Figure 2-8 and Table 2-4 present not only the services identified in the CORBAservices specification, but also CORBA enhancements that have been identified as separate items to be specified.

In addition to the categories discussed above, the DoD TRM addresses a number of other Platform Services. Platform Services in the DoD TRM include the operating system and primitive-level services that provide fundamental functionality to the platform in general. While Platform Services are of great significance in the development of software using traditional structured procedural techniques, as the USIGS migrates to a fully component based architecture based on CORBA, the specifics of the Platform Services will take on less and less importance. When the USIGS is completely migrated to a component based architecture based on CORBA, the choice of platform and services will depend only on performance characteristics and the meeting of minimal standards for network services.

Figure 2-8. CORBAservices and Enhancements Supporting USIGS

The DoD TRM Platform Services are listed and described in Table 2-5.

The DoD TRM also defines "External Entities." External Entities are defined in the IEEE Draft Guide to the POSIX Open System Environment (IEEE P1003.0) and are of two types: Information Interchange Entities and Communications Entities. Information Interchange Entities are those hardware devices with which the platform services exchange information. These include information storage devices such as disk drives, tape drives, etc., and devices through which a user communicates with a system, such as keyboards, display devices, and mice. Communications entities are those hardware devices required to exchange information among platforms, basically the wires, switches, etc.

2.3 Summary of Reference Model Categories and Components

Table 2-6 identifies components in each of the extended reference model service categories. Mission Applications, Common Support Applications, Distributed Computing Services, and other Application Platform Services are identified. Each service category includes several services or components.