Global Information Network Architecture
||This article may require copy editing for grammar, style, cohesion, tone, or spelling. (September 2012)|
The concept for the Global Information Network Architecture (GINA) evolved from a realization that the current technologies provided an unprecedented opportunity to create a useful Global Information Grid (GIG) that could transform the possibilities for Net-Centric Operations.
The Global Information Network Architecture (GINA) Team was created in 2004 to address this possibility. It was originally developed under a cooperative research and development agreement (CRADA) with the U.S. Naval Postgraduate School (NPS) in Monterey, California. The project's initial title was Network Aware Business Data Management System (NABDMS).
In late 2008, the United States Army Corps of Engineers' (USACE)and the Engineer Research and Development Center (ERDC) began the second phase of GINA's development. Current focus is on purposing GINA as a High Level Architecture (HLA) for System Fusion Networks (SFN), GINA is evolving and is being deployed globally to facilitate interoperability and a new form of computational design.
The Global Information Grid 
“The globally interconnected, end-to-end set of information capabilities, associated processes, and personnel for collecting, processing, storing, disseminating and managing information on demand to warfighters, policy makers, and support personnel. The Global Information Grid (GIG) includes all owned and leased communications and computing systems and services, software (including applications), data, security services, and other associated services necessary to achieve Information Superiority. It also includes National Security Systems as defined in section 5142 of the Clinger-Cohen Act of 1996. “
The United States Department of Defense (DoD) recognized in 1996 the need to have a GIG. We have struggled, largely unsuccessfully to bring a reasonable facsimile of a GIG forward. There have been numerous research projects directed at creating a GIG, but actually turning DoD networks into a functioning GIG has proved elusive. The GIG is a very hard problem that requires a rethinking of current approaches to interoperability.
Vector Relational Data Modeling (VRDM)... Modeling Models. 
The dictionary defines modeling as, “The representation, often mathematical, of a process, concept, or operation of a system.”
While software modeling languages such as Unified Modeling Language (UML) or Object Role Modeling (ORM) attempt to provide an iconic representation to articulate the structure or architecture of an application, they are not executable and have limited applicability beyond the software design environment.
The GINA Team created GINA to enable model-based software engineering, but we did so in such a way that the model, once-defined, represented a working application. By properly bounding the problem space to "Information Applications", i.e., non-algorithmically-intense applications with linear relationships representing the vast majority of software applications, the GINA team was able to create a configurable Component Based Object Model (CBOM) for information management where the configuration represented the instructions for assembling a working implementation of the model. Moreover, the GINA team made the decision early in its development to make GINA a GINA model. By doing so the configuration itself could be controlled by configuration. As will be illustrated later, that turned out to be an important decision. Enabling GINA’s deep configurability required the development and implementation of multiple models.
The Control Model assembles the components of the component model, according to the assembly instructions in the Application Model into the structures deﬁned in the Implementation Model to create GINA information objects.
The Application Model describes actual GINA applications. Both the description of applications and the GINA and Application Models themselves. These applications are described in terms of components in the Component Model. It represents the set of components that are assembled in order to create GINA information objects as speciﬁed in the application model.
Ultimately, we have to define GINA applications using a development model that is appropriate for developing GINA applications. And again, the GINA Development Model is itself described as a GINA application.
GINA, at a high level, is a model for modeling. Designed to facilitate a principle of development where relationships between objects can be objectified and wielded as objects in their own right, GINA itself is an executable model configured using VRDM.
VRDM is a core concept that is embodied by GINA. GINA could be looked at as an environment that turns collected data into a multi-dimensional object environment with each object being connected to other objects through vectors. This environment makes many of the information-centric tasks that a user might want to perform far easier than any other approach.
A key concept of VRDM is that relationships among information objects should themselves be defined as information objects, and be fully configurable.
Taking relationships and implementing them as GINA objects enables GINA to take conﬁgurations and assemble models that can perform most, if not all of the work done by typical hard-coded information applications, such as most enterprise systems, integrations, and information sharing systems.
As a result of VRDM, it is possible to specify an application through describing the required components as a series of objects and their relationships, or vectors. VRDM enables disparate data, from disparate sources to be invoked and configured to relate in a “System of Systems” model called a specification. The behavior of a specification can be the much same as a contemporary application. The difference, however, is that with VRDM, there is no programming. GINA is a true CBOM for Object Modeling, where the models are themselves executable.
Critical to this approach is the concept of obfuscation, i.e., the GINA model is described as a GINA model, that permits deep configurability. When one is using the interactive development environment used to create GINA applications, one is using a GINA application. More importantly, GINA assembles GINA applications according to a GINA model for GINA applications. Deeper still, the GINA model is itself an example of a GINA model. This deep configurability is the key to GINA’s power as interoperability and multi-level security ("MLS") engine.
As a combination of hardware and software-based components, which meets the requirements of a true GIG, GINA is configured as a universal virtual network of data of any type from any source in any location on collected physical networks. GINA is a product of several key concepts which collectively enable it to represent a complete, configurable interoperability environment. These key concepts are embodied in a series of layers and components which collectively allow GINA to perform the types of functions and provide the type of services it needs to be a fully functional interoperability environment.
Vector Relational Data Modeling Core Concepts 
Descriptive Programming 
Just as Assembler made machine language programming faster and more accurate, and descriptive languages for specifying procedures (“4GL”s like SQL) made procedural programming faster and more accurate, GINA’s VRDM brings a new level of speed and accuracy to object-oriented programming.
In the long run GINA’s encapsulation of the management of network-available data may be more important that even its speed and accuracy for large organizations.
Component Objects 
With VRDM, Data Agnostic Objects can be created to represent common relationships called Mechanisms. These Mechanisms can be reused and combined with others, new and existing, to create systems and subsystems. This facilitates rapid deployment and non-programmatic implementation.
Just as everything in the world is assembled from remarkably few elements, arbitrarily complex systems can be assembled from relatively few objects. The key in both cases is that objects have to be designed for interaction and assembly. GINA is designed in that way. Fundamentally, at the bottom level are very few objects, e.g., objects, or XTypes in VRDM, and relationships between XTypes, or Vectors in VRDM. These objects are the primitives on which the VRDM object management model is based. In turn, instances of these primitives are assembled into the basic building blocks of VRDM: fully defined objects representing XTypes and Vectors, as well as constraints and simple entities. These can then be assembled to fully describe the GINA environment, and to allow the administrator to create the data objects to support a Task Oriented User Interface (TOUI), or a specific application.
A central concept in GINA is that objects can be referenced in multiple WorldSpaces, depending on how a user gets to that object. A WorldSpace determines the applicability of an object’s vectors, e.g. attributes and relationships, when assembled for a particular event or usage. WorldSpaces are inherently hierarchical: as one more tightly defines the WorldSpace associated with an event or usage, the more tightly one must define, and the more granularly one needs to specify associated behaviors.
If we look back at the concepts associated with GINA, we could say that an object exists in a 3 dimensional data object space. Its location in that space is defined by its order of complexity, its usage and related components, and the user and WorldSpace in which it is being accessed. At any given time the behavior of a system is dictated by all of its objects locations in this 3-dimensional object- space. However, this behavior is not the same for every user, and is influenced by the characteristics of that user that effectively define hyperplanes in this object space. Thus, the appropriate object model is only summarized in three dimensions, with multiple user-based dimensions of behavior effectively being summarized on this graphic. In effect, at any given time an object exists as a point in 7+ dimensional object behavior space. Remarkably, GINA not only models this space effectively, but does so in an environment where most specifications are created through configuration, not programming.
Directory Sub System (DSS) 
GINA is implemented through a software-based, multi-layer, configurable data object management environment. Just as the entirety of GINA can be viewed as a series of well-structured layers, the data object management environment is also structured and layered, with multiple layers of the object management environment corresponding to each of the top three layers in the overall GINA. GINA’s “DSS” layer is actually composed of two separate implementation layers: a content server layer that consists of a collection of configurable objects that know how to navigate the network, acquire data, and present it in a consistent way; and an aggregation layer that homogenizes all incoming data, in both format and name, and presents itself as a universal object repository that insulates the information consumer from the complexities of managing the underlying data stores.
Data Access Layer (DAL) 
GINA collects data from aggregated systems using a collection of adaptors called Content Servers which structure the protocols, formats, and syntax of collected data into a common representation that then becomes the base data that can then be managed through the GINA model. Just as the providers of data to GINA operate on multiple protocols, formats, and syntaxes, the prospective consumers of GINA data may require information using their own protocols, formats, and syntax. GINA exposes itself using a standard "Data Access Layer" ("DAL") that can be—and has been—used to provide data to standardized or customized DALs such as SOAP Web Services, ODBC interfaces, etc.
Task Oriented User Interface (TOUI) 
Another model that has been built in GINA is called the Task-Oriented User Interface, or "TOUI". The current mainstream approach to user interfaces ("UIs") involves a process where a developer "paints", or in some other way creates a mark-up of the UI, and then deﬁnes the binding of components of that the UI to the underlying application using some standardized approach. The TOUI model takes a different approach: a UI is assembled at the time of request from components according to a set of vectors that take into the account model states and the user during the assembly process. As a result, the UI no longer represents the application that uses information, but rather becomes the external expression of the information model that represents the application. Moreover, because the deﬁnition of the UI is done as a set of metadata-deﬁned GINA components, the expression of those components can be done in any environment that has sufﬁciently strong semantics for representing applications, whether that is Java, .NET, Python, or even a 3-D visualization environment.interfaces, etc.
GINA Applications 
- Command and Control (C2)
- Intrinsic Multi-level network security
- Extensible executable enterprise solution
|This section is empty. You can help by adding to it. (September 2012)|
Tudor, R., Tinsley, D., Busalacchi, F., The Global Information Network Architecture (GINA) Technology Framework, Naval Postgraduate School, Monterey CA.
- United States Department of Defense, Department of Defense Information Assurance Certification and Accreditation Process (January 2009). "DIACAP Artifact B, Definitions" (Microsoft Word Document). United States Department of Defense. Retrieved 2010-01-15.