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!
The open mainframe architecture revives old ideas. This chapter explores the history of application architectures.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
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.
The history of application architectures shows an interesting tug of war between application management and user experience.
Application management is easy on mainframes, but the user experience on terminals is terrible.
PC applications offer a great user experience, but it is hard to manage applications in a network with PCs.
Web applications are easy to manage on network servers, but web browsers offer a poor user experience on mobile devices.
Native apps offer a rich user experience on mobile devices, but application management must be delegated to app stores.
This chapter explains how the major components of oma fit together. The open mainframe architecture promises easy application management and a decent user experience.
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.
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.
delta service
The delta service creates delta sessions. A delta session synchronizes a model that the client and server side of the session share. The JSON representation of the model is defined by datatypes. The client side sends a delta request with actions on the model. A delta action is either a mutation that modifies the model, or an event that signals an incident in the model. The server side replies with a delta response whose actions reflect the effects of processing the previous request. The sequential exchange of delta messages with model actions continues, until one of the sides closes the session.
Terminals, applications and processes manage their own delta sessions on open mainframes. The direction of a delta session determines the role of the HTTP client in the session. Process sessions are reverse sessions. Processes are HTTP clients, but they play the server role in delta sessions. Terminal and application sessions are forward sessions, because terminals and applications are HTTP clients that also fulfil the client role in delta sessions.
welcome service
This service establishes contact between a frontend terminal and a backend process. When a user navigates a web browser to an open mainframe, the browser becomes a terminal that requests the welcome service to launch an application. The service examines the welcome request to determine the application that the user intends to start.
When a user starts an application, a new terminal session in the frontend is paired with a new process session in the backend. A session pair synchronizes the same model in opposite directions. The forward terminal session controls the client side of the model and the reverse process session controls the server side. The only involvement of the open mainframe is to relay delta messages between the paired sides.
deploy service
An HTTP client posts a request to this service with a description of the application to deploy from the backend. Successful deployment results in a new application session that the HTTP client should manage. Once deployed, a user can start the application by navigating a web browser to an appropriate URL.
A delta action in the application session instructs the deployment to create a new process, when a terminal launches the application. The new process manages its own delta session that is paired with a terminal session.
library service
This service resembles a public library where any client can read books, known as bundles in oma terminology. A bundle publishes static assets in a directory on a web server. Bundles are distribution units for modules. When a client needs a module from a bundle, it fetches all modules of the bundle in one download.
If a bundle is like a book, a module is like a chapter in a book. A module is a logically cohesive set of assets with a well-defined purpose. A modular organization reduces complexity of asset management. The open mainframe architecture promotes the development of many small modules that specify their dependencies on other modules. Developers should not be bothered by the bundles in which modules are distributed.
telemetry service
The telemetry service offers a peek inside an open mainframe with metrics about performance and load. Telemetry clients monitor the health of an open mainframe. They should detect minor issues before these issues turn into major problems.
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.
A frontend developer writes presentation logic of user-interface components.
A backend developer writes application logic to control user interfaces.
A QA engineer verifies quality of application deployments before they go into production.
An infrastructure engineer builds the infrastructure of open mainframes for development, test and production purposes.
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.