Appendix C. Reference Models
- C.1. Platform Oriented Architecture Reference Models
- C.2. Service Oriented Architecture Reference Models
- C.3. Network-Enabled Operations (NEO-RM)
- C.4. Information Systems Interoperability Reference Model (ISIOP-RM)
- C.5. Business Process Infrastructure Framework (BPIF)
- C.6. NNEC Profile
- C.7. Transition from Platform Oriented to Service Oriented Models
185. By definition, a reference model is an abstract framework for understanding the relationships among the entities within a specified environment. It enables the development of specific architectures using consistent standards or specifications supporting that environment.
186. A basic reference model will consists of the smallest set of unifying concepts, rules and relationships within a particular problem area, and is independent of specific standards, technologies, implementations, or other concrete details.
187. The relationship between the Reference Model and the implementation of a particular abstract concept is illustrated in Figure C.1.
188. Reference models are a standard definitive document or conceptual representation of a system or process. It provides a structure which allows the modules and interfaces of a system to be described in a consistent manner. In the context of near-future NATO environments, member nations could use these general models in designing architectures for net-enabled systems and platforms. These models represent the mid-term common framework that NATO nations can build to. A common framework is one of the keys to ensuring interoperability.
189. General reference models presented by industry do not take into account the typical Military or NATO unique situation. In the far-term, the NNEC approach will require us to establish a NATO Reference Model for services that tailored to complement the NATO mission.
190. Reference models are a standard definitive document or conceptual representation of a system or process. It provides a structure which allows the modules and interfaces of a system to be described in a consistent manner. In the context of future NATO environments, member nations can use these models in designing architectures for net-enabled systems and platforms.
191. Such assets can then participate in an NCO environment, by acting as interoperable nodes on a fixed or mobile ad hoc network. Once an element operates as a node, it can discover and register its needs and capabilities on a network, and use that network to communicate, interact and function with other nodes. The ultimate result is greater mission effectiveness.
C.1. Platform Oriented Architecture Reference Models
C.1.1. The NATO Technical Reference Model (NTRM)
C.1.1.1. Purpose
192. Within the context of information systems, a Technical Reference Model (TRM) is a generally accepted construct that provides a basic set of concepts and a conceptual framework for identifying and resolving standards issues.
193. The main purpose of the NATO TRM (NTRM) is to structure the standards listed in the NATO Interoperability Standards and Profiles (NISP). As such, it should be a stable model and modifications should be made very carefully.
C.1.1.2. Structure
194. The NTRM focuses on separating data from applications and applications from the computing platform. This is a key principle when striving to attain a true open system environment. The NTRM provides the definitions necessary for designing and defining architectures and related service components. It also identifies service areas (i.e., capabilities that have been grouped together by functions), as well as their interfaces.
195. As indicated above, the NTRM is designed to decouple the application and external environment from the platform. This allows for portability of the application and independence from the external devices (e.g., disk, mouse, keyboard, LAN). This is accomplished by defining the application program interface (API) and external environment interface (EEI) accordingly.
C.1.1.3. Basic Entities and Interfaces
196. The basic elements of the NTRM are those identified in the POSIX OSE Reference Model. This model includes 3 classes of entities and 2 types of interfaces as follows:
-
Application Software Entity
-
Application Program Interface (API)
-
Application Platform Entity
-
External Environment Interface (EEI)
-
External Environment Entity
Figure C.1. NTRM Services View
C.1.1.3.1. Application Software Entity
197. The Application Software Entity includes both mission area and support applications.
-
Mission-area or user applications implement specific user requirements (e.g., personnel, material, and management). This application software may be COTS, GOTS, custom developed, or consist of a combination thereof.
-
Support applications (e.g., email and word processing) can be used to develop mission area specific applications or could be made readily available to the user. There are six support application categories:
-
Multimedia,
-
Communications,
-
Business Processing,
-
Environment Management,
-
Database utilities,
-
Engineering support.
-
C.1.1.3.2. Application Platform Entity
198. The Application Platform Entity contains the system services and the physical environment services. It is the second layer of the NTRM and includes the services in which information processing functionality is built.
-
Service Areas are defined in Section C.1.1.4.
-
Physical Environment services address the requirements for establishing the data interchange interface between physical resources and enable bus or communications link boards to address their peers in another node or system. They may also enable links to address processors or enable processors to address memory registers.
C.1.1.3.3. External Environment Entity
199. The External Environment Entity consists of external services that interact with the physical environment services of the application platform entity. These services are classified into the general categories of user services (e. g., mouse, display), information exchange services (e.g., memory stick) and communications services (e.g., LAN, WAN).
C.1.1.3.4. Interfaces
200. The Interfaces include both Application Programming Interfaces (API) and External Environment Interfaces (EEI)):
-
The APIs are the interface between the application software entity and the application platform. They constitute a collection of standards-based interfaces,
-
The External Environment Interfaces (EEI) are defined as the interfaces between the application platform and the external environment across which services are available, primarily in support of system and application software interoperability. User and data portability are provided directly by the EEI and provide the interfaces between the application platform entity and the external environment.
201. A concept of internal interfaces (IIs), not included in the previous version of the model, complements the notions of APIs and EEIs:
202. IIs are the interfaces within the system entities, both between sub-entities at the same level and sub-entities at different levels where sub-entities at a higher level make use of services offered by a lower level one. (A direct communication between two sub-entities at the same level is only possible at the lowest level).
203. The interfaces are in principle supported or realized by commonly defined data models and structures (e.g., ACP 133 B Schema Information for Directory Services).
204. Users should assess their own requirements and create a listing of services, interfaces, and standards that satisfy their own mission-area needs in conjunction with the NTRM accordingly.
205. In addition, the NTRM can accommodate a wide variety of general- and special purpose systems. From the perspective of the application software entity, these services are provided by an application platform whether the particular services are provided from the local platform or from remote platforms that may comprise one or more nodes of a larger distributed system. The NTRM can also be applied in a distributed environment and networked environment.
206. The objective of the NTRM is to provide a complete, as well as extensive set of features and capabilities. The NTRM provides consistency for user applications from a broader community in order to address interoperability, open systems, acquisition, and management issues associated with commercial off-the-shelf (COTS) and Government off-the-shelf (GOTS) products.
C.1.1.4. Service Areas of the NTRM
207. The System Services of the Application Platform Entity are used to structure the standards listed in the NISP. The classes and sub- classes described in the NISP are to be considered part of the NTRM. The 12 System Services areas are:
-
User Interface Services. These services define how users may interact with an application. The term user interface in this context means a graphical user interface (GUI). Standards are not only required for setting up and managing graphical windows, but also for the toolkit and generic 'look and feel'.
-
Data Management Services. The management of data is central to most systems. To improve interoperability, data should be defined independently from the processes that create or use it, and should be maintained and shared among many processes.
-
Data Interchange Services. These services provide support for the interchange of data between applications. They are designed to handle data interchange between applications on the same or on heterogeneous platforms.
-
Graphics Services. These services provide functions required for creating and manipulating graphics.
-
Communication Services. These services provide distributed applications support for data access and applications interoperability in heterogeneous or homogeneous networked environments.
-
Operating System Services. These services are the core services needed to operate and administer the application platform and provide an interface between applications software and platform. Application programmers will use operating system services to obtain operating system functionality.
-
Internationalization Services. Within the context of the NTRM, internationalization provides a set of services and interfaces that allow a user to define, select, translate and switch between different culturally related application environments supported by the particular implementation. Character sets and data representation services include the capability to input, store, manipulate, retrieve, communicate, and present data independently of the coding scheme used. This includes the capability to maintain and access a central character set repository of all coded character sets used throughout the platform.
-
System Management Services. Information systems are composed of a wide variety of diverse resources that must be managed effectively to achieve the goals of an open system environment. While the individual resources (such as printers, software, users, processors) may differ widely, the abstraction of these resources as managed objects allows for their treatment in a uniform manner.
-
Security Services. Different groups of individuals within and across the various NATO applications need to work with specific sets of data elements. Access to these sets of data elements is to be restricted to authorized users. Satisfaction of this requirement has traditionally been accomplished by the implementation of separate information systems. Organizations cannot continue to afford to implement separate information systems to satisfy this requirement, nor is it effective to require the user to change interface components every time the need arises to operate with a different restricted data set. Significant benefit will accrue when an individual information system can effectively support the needs of different groups of users and data sets.
-
Distributed Computing Services. These services provide specialized support for applications that may be physically or logically dispersed among computer systems in a network, but yet wish to maintain a co-operative processing environment. The classical definition of a computer becomes blurred as the processes that contribute to information processing become distributed across a facility or a network. As with other cross-cutting services, the requisite components of distributed computing services typically exist within particular service areas.
-
Software Engineering Services. The procedural aspect of an application is embodied in the programming languages used to code it. Additionally, professional system developers require methods and tools appropriate to the development and maintenance of applications.
-
Common C2 Applications Services. These services provide the ability to view data (i.e., share) in a common way across the network. Common C2 Applications Services promote interoperability among diverse functional mission area domains and may be executed between both individual and multiple functional application domain areas.
C.1.2. NCOE Component Model (NCM)
208. The NTRM provides the structural basis for defining the NCOE (NATO Common Operating Environment) Component Model (NCM).
Figure C.2. The NCOE Component Model
209. The principal components of the NCM (see Figure C.2) include:
-
Kernel Services. The Kernel Services are that subset of the NCOE component segments, which are required for all compliant platforms. At a minimum, this sub-set would consist of the operating system, windowing software, security services, segment installation software and an executive manager.
-
Infrastructure Services. Infrastructure services are those services that directly support the flow of information across NATO systems. Infrastructure services provide a set of integrated capabilities that the applications will access to invoke NCOE services.
-
Common Support Application Services. Common Support Application Services provide services to process and view data in a common way (share data) across the network. The NCOE common support application services promote interoperability among various Mission Applications.
-
Network Services. The NCOE Network Services constitute the basic interface between the platform and the underlying networking infrastructure and include the Internet Sub-layer services.
-
Application Programming Interfaces . Applications are integrated into the NCOE through a common set of Application Programming Interfaces (APIs). The APIs are invoked by the applications and services as required [8].
-
Data Component Definition . The data component refers to the way in which data is taken into account in the NCOE and is related to the main components of the NCOE (Common Support Application Services, Infrastructure Services, Kernel Services) and even, out of NCOE components, in the strictest sense, to Mission Applications.
-
Support Services . The NCOE Support Services include Methods & Tools, Information Repository, Training Services, System Management and Security.
[8] The term API is to be understood in a local sense (e.g. APIs between components interfaced on a user desktop), as well as in a distributed sense (e.g. interfaces from legacy or external components using an Object Request Broker (ORB) through IDL interfaces).