The CI integration strategy is based on two core principles: messaging and service-orientation. A high-performance message exchange provides a communication conduit with dynamic routing and interception capabilities for all interacting elements of the system-of-systems. The message interface is isolated from any implementation technologies, and provides scalability, reliability and fault-tolerance. Service-orientation is the key to managing and maintaining applications in a heterogeneous distributed system. All functional capabilities and resources represent themselves as services to the observatory network, with precisely defined service access protocols based on message exchange. Services are also defined independently of implementation technologies. The functional capabilities of the CI are provided by assembling and integrating proven technologies and tools using the integration infrastructure. The integration strategy is an application of the Rich Services pattern introduced in.

The CI deployment strategy is based on the concept of a capability container (Fig. 1) that provides all essential infrastructure elements and selected deployment-specific application support. Capability containers can be deployed wherever CI-integrated resources are required across the observatory network, and can be adapted to available resources and their environment. This includes (for example) platform controllers on remote, intermittently connected global moorings, compute units placed in the payload bay of AUVs and gliders and the full range of terrestrial CI deployments (Cyber Points of Presence or CyberPoPs).

Figure 1

The CI multi-facility strategy supports the collaboration of multiple independent domains of authority (Fig.2) bringing together their own resources, with no central governance and policy authority, based on agreements and contracts. This enables the sharing and use of observatory resources across the network, governed by consistent policy.

Figure 2

Figure 3 depicts a partial deployment scenario for the OOI CI. The primary structured elements represent the CI facilities operated within each of the domains of authority shown in Fig. 2. This includes RSN and CGSN marine operations with wet-side and shore-side components respectively, the integrated observatory facility operated by the CI IO, and further facilities that are connected on behalf of user organizations joining the integrated observatory network based on contractual agreements.

Figure 3

The rectangular shapes show physical deployment nodes within the integrated observatory running partial or full CI software stacks. The octagon shape within each of the deployment nodes indicates that there is an instance of the CI capability container (Fig. 1) deployed with selected infrastructure and application support capabilities, depending on resource availability. Full feature CyberPoPs are deployed on the shore side of each of the marine observatories and within the CI facility. In addition, the CGSN wet-side shows a deployment of a capability container hosting an instrument adapter specific to the instrument platform and their sensors. Capability containers may also be deployed on the RSN wet-side as standalone packages. Within the user facilities, instances of capability containers hosting execution engines for workflows and for executing numerical models are hosted.

All of the above capability containers are connected across the network, and in aggregate present themselves as the OOI integrated observatory. All resources are operated within their respective domains of authority, and policy specific to these facilities applies independent of on whose behalf the resource is used.

The CI applies virtualization of computation and storage in order to realize flexible deployment of capability containers across the OOI network. Implemented and integrated software components are bundled according to specific functional needs into deployable types. The CI manages a repository of such deployable types. In addition, it provides adapters for supported target execution environments. These adapters turn deployable types into deployable units that are specific to one supported target environment. These units can be provisioned as needed and will register themselves in the operational environment where they are deployed (contextualization). Through these steps, the CI achieves independence of software components from specific target environments. In addition, it can react dynamically to increased resource needs or failures, and bring up new instances (elastic computing).

The described deployment mechanism reaches its full power in combination with cloud computing, where virtualized compute and storage resources are provided over the Internet. The above described mechanisms of bundling software components, adapting these bundles to the target environment (e.g. Amazon’s EC2 cloud), provisioning such “images” as needed and contextualizing them within an operational context are applied and made available via the CEI. The CI will apply this as an overflow mechanism for user-requested computations. The CEI will then schedule computation and required storage as needed and provision cloud resources that can match user requests. The entire process occurs automatically according to policy defined by the OOI CI operators.