Preface

I am a software developer from The Netherlands. In this document, I describe an architecture for interactive applications.

The open mainframe architecture (oma) recycles the idea of a reliable mainframe that serves stateless terminals. I am not suggesting we should dust off mainframes and terminals, but I will show mainframes and terminals are still relevant concepts. The word 'oma' means granny or grandmother in Dutch. This seems fitting for an architecture whose main concepts are decades old.

An open mainframe is a website. A web browser becomes a terminal when it visits an open mainframe. A terminal presents a user interface and it reports user interactions. A mainframe hosts applications that process user interactions for terminals. Mainframes and terminals are perfect metaphors for a strict separation between application and presentation concerns. This separation of concerns is the foundation on which oma is built.

The open mainframe architecture is released under the liberal MIT license. The reference implementation of oma complements this document with an executable prototype. Developers are encouraged to implement oma components in their favorite programming languages. Mixing and matching heterogenous components in an architecture for interactive applications is an important goal of oma. In memory of Douglas Adams, oma adopts the slogan of the Sirius Cybernetics Corporation. Share and enjoy!

Introduction

The open mainframe architecture revives old ideas. This chapter explores the history of application architectures.

Mainframes and terminals

Mainframes are the first commercial computers. They are mysterious machines in the 1960s, because electronics is still in its infancy. Mainframes have almost become extinct, but they remain renowned for their reliability.

IBM 704 mainframe (Wikimedia)

A terminal presents the user interface of a remote process that is running on a mainframe. The first terminals are teletypewriters. Later models introduce monochrome monitors. Despite a hefty price tag, a terminal is still relatively inexpensive compared to a mainframe. Terminals can be upgraded without additional investments in a mainframe.

DEC VT101 terminal (Wikimedia)

Mainframes and terminals respect a strict separation between application and presentation concerns. A mainframe runs processes for terminals. A process is a running instance of an application whose user interface is presented by a terminal. The terminal reports user interactions to the process, which computes the effects of the interactions on the user interface. These effects are communicated back to the terminal that refreshes the user interface accordingly.

Home computers and PCs

In the early 1980s, a new type of computer emerges. The home computer inspires enthusiasts to learn more about hardware and software. The computational power of a home computer is tiny, but creative minds manage to squeeze out every inch of the hardware to create impressive games and demos. User experience is an important criterion for applications on home computers. Users need convincing before they buy an application for their home computer.

Commodore 64 (Wikimedia)

The personal computer dominates after the home computer. The affordable PC introduces computers to a broad audience. The competitive PC market forces manufacturers to innovate. Ergonomics and usability studies are taken seriously. Technological advancements, e.g. mouse, color display and audio playback, pave the way for immersive user interfaces. For many people, the PC becomes a vital instrument that is switched on every day.

Laptop PC (Wikimedia)

Home computers and PCs shift attention from machines to humans. Software should keep users happy and productive on commodity hardware. Most users are not interested in hardware details. They only care for the applications they can run on the hardware.

Networking and the Internet

When businesses connect the PCs of employees to a network, they soon discover that distributed application management is a nightmare on a network with PCs. An upgrade of a service on the business network might demand an update of the client software on all PCs. Members of the IT department regularly hop from PC to PC in an office building, installing new software versions by hand.

Floppies for software installations (Wikimedia)

Internet technologies provide a solution with web applications on intranets. All PCs run web browsers that display HTML pages of a web application. The web application is hosted and maintained on a web server by the IT department. The first web applications are restricted to simple form-based tasks, but modern web applications offer a decent user experience for a wide range of tasks on PCs with mainstream browsers.

Netscape Navigator 1.22 (Wikimedia)

Although web browsers and terminals are both clients in a client/server solution, browsers are only superficially similar to terminals. A terminal presents a user interface whose state is completely controlled by the process on the mainframe. Browsers blur this separation between application and presentation concerns. A browser can respond to user interactions by executing JavaScript code that updates the HTML page, without informing the server. Web applications on servers cannot always reproduce the complete state of an HTML page that a browser is currently displaying.

Apps on mobile devices

Web applications are not popular on mobile devices, because native apps deliver a superior user experience. Web standards are still playing catch-up with mobile technologies. It's an unfortunate consequence of the standardization process. A rivalry with native apps is out of the question, if web applications have a hard time exploiting basic features on mobile devices, e.g. touch and orientation. The loss in user experience is unacceptable.

Smartphone (Wikimedia)

Apps on mobile devices resemble PC applications, because both execute on personal devices. Their distribution methods are however vastly different. A user installs a PC application from a storage medium. An app on a mobile device is distributed from a central app store. App stores give device vendors tight control over application distribution and maintenance. Most users on mobile devices have given up the freedom to install software as they please. They trust app stores to manage and to upgrade applications for them.

Summary

The history of application architectures shows an interesting tug of war between application management and user experience.

Overview

This chapter explains how the major components of oma fit together. The open mainframe architecture promises easy application management and a decent user experience.

Frontend and backend tier

The open mainframe architecture consists of a frontend and backend tier. The frontend tier is where terminals live. A terminal presents a user interface. The backend tier is where processes live. A process is a running instance of an application, which controls the state of a user interface. When a terminal reports user interactions, the process updates the user interface.

A traditional mainframe runs all processes for connected terminals. A traditional mainframe is the backend tier. An open mainframe is however a router between tiers, which does not execute application logic. All processes run autonomously in the backend tier. Terminals execute presentation logic in the frontend tier. The open mainframe in the middle supervises communication between frontend terminals and backend processes.

Applications are deployed from the backend tier. An application deployment is instructed to create a process, when a terminal launches the application. The new process computes the initial state of a user interface, which is communicated back to the terminal and presented to the user. Backend applications and processes are not too concerned with user-interface technologies. Frontend terminals don't care about application logic to process user interactions. The open mainframe architecture separates the same application from presentation concerns as traditional mainframes.

Web technologies

The open mainframe architecture leverages the success of web technologies. Terminals, applications and processes are HTTP clients that talk to web services on an open mainframe.

A web browser turns into a frontend terminal when a user navigates the browser to an open mainframe. Browsers are converging towards an impressive set of HTML standards and JavaScript APIs. CSS has also been steadily improving over the years, gaining evermore features to separate styling from content. The browser wars have ended in a clear victory for web standards.

Despite a problematic childhood, JavaScript has matured well. Every incarnation of oma ships with a Node.js implementation, developed in TypeScript, which transpiles down to JavaScript. The reference implementation provides an executable prototype of the architecture. I hope the prototype is an incentive for others to develop better implementations, in as many programming languages as possible. JavaScript is the obvious choice for a reference implementation, because web browsers must be programmed in JavaScript. There is no compelling reason to complicate the reference implementation with another programming language.

JSON is the preferred data format. The open mainframe architecture extends JSON with a type system to enforce more rigorous rules on data communication. JSON with datatypes is an essential ingredient that ties the components of oma together. The type system introduces a simple definition language to create datatypes, which specify how to marshal data values and how to unmarshal JSON representations.

An open mainframe implements the following web services for HTTP clients in frontend and backend networks.

Multidisciplinary teams

Application development is difficult in any architecture. It's a delicate sport that requires experts from different disciplines and backgrounds to cooperate effectively in a team. In my experience, it's very rare to find a team that operates without problems. These problems have diverse reasons, e.g. procedural, managerial, personal or technical. The open mainframe architecture balances the needs of all team disciplines that are involved in an application's lifecycle, but it can only assist disciplines on technical grounds. The nontechnical challenges of a development process are outside the scope of oma.

For the sake of simplicity, I assume there are four major disciplines in a development team.

The major disciplines can be further subdivided into minor disciplines. For example, frontend development involves both human-machine interaction and user interface design. Backend development needs experts in the business domain, but database expertise is often just as important. These intradisciplinary dependencies are also outside the scope of oma.

Frontend developers build components for backend developers. The goal is to separate presentation from application concerns, although this is not always a clear-cut boundary. For example, a backend developer should obviously not be concerned with the color of a label in the user interface, but a frontend developer can only assign the appropriate color if the backend provides the means to distinguish that particular 'application situation'. Frontend and backend development are not isolated islands. Developers from both sides have to agree on a shared model that gives frontend developers the freedom to tweak the user interface, while backend developers are not burdened with unnecessary presentation details.