# Introduction to Information Systems

> **Background & Citation:** This architecture is born from the research formalized in the PhD thesis: *Transactional REST Information System for Federated Research Infrastructures enabling Virtual Research Environments* (Frosini, L., 2019)[^frosini-2019].

## What is an Information System for a Federated Research Infrastructure?

In the context of modern Research Infrastructures (RIs), an **Information System (IS)** acts as the central nervous system of the entire federation. 

*(Architectural Clarification: The IS is **logically centralized** to act as the single source of truth for the infrastructure. It is designed to solve the complexities of federating diverse external resources, unifying their knowledge into a cohesive graph. However, it is not physically modeled as a peer-to-peer network of independent IS instances in each federated node exchanging global state. It operates as a unified, centralized registry serving the distributed infrastructure).*

Formally, the Information System is defined as the key service of a Hybrid Data Infrastructure (HDI). It acts as the registry of the infrastructure, and it offers (through query answering) both a global view (infrastructure level) and a partial view (VRE level) of:

*   its resources (e.g., computing, storage, services, software, datasets);
*   their current status (e.g., available, down, not responding);
*   their relationships with other resources;
*   the policies governing their exploitation.

A **Hybrid Data Infrastructure (HDI)** is an e-Infrastructure which leverages external systems (e.g., data, storage services, computational resources, grid and cloud computing infrastructures) by exposing them as a common unified space of resources. This serves diverse communities of researchers by providing them data, services, and sharing tools through dedicated, flexible, web-based, and on-demand environments called **Virtual Research Environments (VREs)**.

The work presented here contributes to address the issues of such complex environments and proposes solutions by designing an Information System capable to evolve with the evolving needs of the infrastructure.

## The System of Systems (SoS) Paradigm

An HDI does not exist in isolation; it federates multiple independent systems. This architecture can be formally classified as a **System of Systems (SoS)**. A System of Systems is defined as a "system composed of independent constituent systems, which act jointly towards a common goal through the synergism between them."

The IS must account for the eight dimensions characterising a SoS:
1.  **Autonomy of Constituents:** Each constituent system behaves according to its own rules.
2.  **Independence:** Each constituent system is capable of operating autonomously if detached from the others.
3.  **Distribution:** Constituent systems are geographically or logically dispersed, requiring connectivity to create synergy.
4.  **Evolution:** Each constituent system evolves independently over time.
5.  **Interoperability:** The ability of the SoS to incorporate different constituent systems.
6.  **Dynamic Reconfiguration:** The adaptability to support changes in the composition and structure of the constituent systems without planned interventions.
7.  **Emergence of Behavior:** The SoS provides higher functionality than the constituent systems simply as a result of the synergy between them.
8.  **Interdependence:** Constituent systems sacrifice degrees of independence to meet the requirements of joining the federation.

Because the IS manages the topology and relationships of all these moving parts, it must be inherently flexible, capable of modelling highly heterogeneous resources, and dynamic enough to support the constant evolution of its constituent systems.

## The Necessity of a Data Definition Language (DDL)

To handle the inherent diversity and evolution of an HDI, a rigid, hardcoded data model is insufficient. An Information System must support an open-ended set of resources, open-ended descriptive models, and the ability to adapt to the evolving needs of the infrastructure at zero cost to the client.

This requirement necessitates Type management, allowing the dynamic instantiation of the underlying theoretical IS-Model into concrete models (such as the gCube Model). To achieve this, the Information System must provide an explicit **Data Definition Language (DDL)**. 

In a RESTful architecture, adhering to the principle of *Manipulation Of Resources Through Representations*, the DDL serves as the specification of the representation of a Type. It enables the system to:
1.  Define new Types dynamically.
2.  Specify the schema (the structural blueprint) that any data instance of a Type must respect in terms of data fields, validation constraints, and topological connections with other instances.
3.  Validate these instances automatically against their registered schema upon creation or modification.

By externalizing the schema definition into a DDL, the Information System decouples the underlying graph database engine from the business logic, allowing administrators to evolve the infrastructure resource model without recompiling the core IS software.

## The Open-World Extensibility Paradigm

To truly satisfy the dynamic and evolving requirements of a System of Systems, the Information System operates under an overarching **Open-World Assumption**. In a federated environment, it is impossible to know all required configurations or metadata at design time. Therefore, the system enforces the philosophy: *"What is not explicitly constrained by the schema is dynamically permitted."*

As will be detailed in the [IS-Model core topology](03-is-model-core-topology.md) chapter, the ability to dynamically define new schemas via the DDL and the inherent support for polymorphism are foundational manifestations of this philosophy. Furthermore, the Open-World Assumption ensures that the system remains inherently extensible at runtime in the following ways:
- **Topological Extensibility:** By allowing **Resource** instances to attach arbitrary **Facet** instances beyond their initial schema blueprints.
- **Data Extensibility:** By permitting the injection of arbitrary custom fields directly into eligible property-bearing instances (such as **Facet** and **Relation** instances) or embedded **`Property`** values.
