In the past nine months the EaaSI development team worked hard to adapt and improve the EaaS code-base to cope with the challenges and requirements of truly distributed emulation service.

Sharing Environments with Network Nodes

The main goal of the EaaSI project is to make preserved software usable and accessible at scale. This entails, that at some point software is accessible as pre-installed and configured emulation environment, e.g. ready to be used with a user-provided digital object. Installation of software is not only time consuming, in some cases it requires operational knowledge about ancient computer systems. To avoid replication of laboursome tasks as well as to share expertise about obsolete software and computer systems, one goal of the EaaSI network is to connect different institutions (node hosts) and let them share such ready-made software environments.

Publication and Replication

As a first step, the EaaSI UI and backend distinguishes now between private, public and remote emulation environments. By default any environment is private, i.e. is only visible to the local EaaSI user. This is the playground for local experiments and for working with private collection items. Any private software environment can then be published, and thus, can be made available to other EaaSI network members. During this process a Handle.net URL is generated containing a reference to the actual disk image location.

Public environments are by definition read-only, i.e. all network participants can refer to a specific environments ID which represent a specific version of an emulated environment, for instance a Windows 98 operating system with Microsoft Office 97 installed. Still, EaaSI users have the option to adapt or develop a public environment further. Any modification of a public environment will result in newly created private environment, which then can be eventually published again.

In contrast, remote environments, represent published environments of other EaaSI nodes and are represented by default as metadata only. If a remote environment of interest should be available on the local EaaSI instance, the environment has to be explicitly replicated. A replication request, resolves the references to the disk images found in the metadata (currently Handle.net URLs) and replicates the environment to local storage. As a result the remote environment becomes a public (and published) environment of the local node and the original Handle.net record is updated with an additional location of the environments disk image.

Screenshot of EaaSI landing page featuring search results list of configured environments in the EaaSI Network
OAI-PMH Metadata Exchange

In order to distribute metadata about published environments throughout the EaaSI network, we added OAI-PMH endpoints both to harvest data from other nodes as well as to share metadata about published environments.

Screenshot of EaaSI interface featuring OAI-PMH endpoint for harvesting and sharing metadata within the EaaSI Network

Every EaaSI instance can add (currently manually) other EaaSI OAI-PMH data providers. Once a data providers endpoint is verified, remote metadata can be harvested (currently the harvesting process has to be initiated manually using the EaaSI UI). This way the remote environment list will be populated and/or updated.

Containerized Emulators

With the ability of sharing pre-configured environments, it is also important, that as part of the replication process the necessary (configured) emulator is available too. Otherwise the environment might not work at all or if run with a different emulator version might behave differently. To solve this, we have decoupled provisioning of emulators from the general EaaSI installation. Emulators are now “objects”, which we reference in the technical metadata of an environment. Hence, emulators have to be explicitly imported from a Docker registry to be configured and used in EaaSI. Even though we package emulators as Docker containers, the Docker technology is currently only used for packaging, referencing the exact version and transport. Once imported, the emulators are extracted and installed.

Screenshot of EaaSI interface featuring Emulator Import option. Configuration users can import emulators from a Docker container registry.

When replicating a remote environment, the EaaSI framework checks if the emulator version referenced in the technical metadata is available. If not, the emulator is imported from automatically.

Currently available (pre-packaged) emulators can be found here: https://gitlab.com/emulation-as-a-service/emulators

Technical details about packaging emulator to be imported in EaaSI will be described in a follow-up blog post.

Preferred citation:

Rechert, Klaus. (2019, March 29). EaaSI Software Development Update. Software Preservation Network. https://www.softwarepreservationnetwork.org/eaasi-software-development-update/