Design Overview
A Customizable Software System based on a
Balanced Software System Architecture and Design
(A More Human Friendly Approach)
Modern software techniques developed during a period of extremely expensive computer hardware. Practically the only criteria used to judge software were correctness and price performance. The telephone and electrical power industry deviated from this trend by adding features to achieve better reliability. Security, beyond a sign-on password or encrypted data, is mostly nonexistent. Computer to computer communication is available but without a multiple computer software system architecture.
Times have changed. Computer resources have become very powerful and cheap. Unfortunately, software architecture and practice are based on the past. Admittedly, attempts have been made such as CORBA and SOA to improve the situation, but with only modest success.
This paper presents a balanced software system architecture and design for from three to thousands of computers. It can be adapted to one computer or a hierarchy of software systems. A few key innovations are blended with existing ideas to define an architecture balancing reliability, security, scalability, performance, and cost. Resources are expended to be more friendly to designers, programmers, administrators, operators, and end users alike.
Data Representation
A universal data representation is needed that is human readable, computer manufacturer specific, and efficiently exchanged between computers. Such a data representation is an unattainable dream. The next best alternative is to use a text format similar to XML for human readability that is converted by a system to and from a computer friendly format. A system also converts a computer friendly format to and from an universal serial format. This alternative is made possible by an innovation that adds Meta data to each in memory data value that directs a system conversion between formats. A programmer uses a software language to specify this Meta data at initialization time. The in memory Meta data consumes space in addition to what is needed by a data value. Significant programmer time is saved since no programming is needed beyond Meta data initialization and what is provided by the system conversion methods. Islands of functionality created by specific hardware, OS, and language combinations are bridged by exchanging data content in a serial format and converting to or from the specific in memory format.
Software System
A multiple computer software system is created from computers, network elements, one or more computer operating systems, multiple software languages, and 3rd party software programs by a common infrastructure that executes on each computer within a system. The infrastructure can arrange computers and network elements into two independent and redundant hub and spoke networks. A hub computer accepts a connection from each spoke computer. A spoke computer connects to both independent hubs. The infrastructure on a spoke computer creates an environment for 3rd party software programs such that a message between programs can travel via two independent paths.
A hub enforces administrator configuration on which programs can talk via a point to point communication connection. A hub can securely know the identity of a spoke computer. Either a spoke is relied upon to securely identify a program or only one program is configured to execute on a spoke. A hub also enforces limits on what a publisher can publish and what a subscriber can receive. An event id is used to uniquely identify each published piece of information so that configured limits can be enforced.
The infrastructure uniquely identifies an OS program by a program name. A program with a configuration is defined as a program copy that is uniquely identified via a program copy id. A program copy is configured to execute as an instance on one or more computers within a system. One of the program copy instances is dynamically assigned as the active instance. An active instance is a single central decision maker for program copy functionality executing within a system.
An administrator configures a system as computers, programs, program copies, event ids, publishers, and subscribers. This information is created at one location and is labeled with a unique version id. Each system version has it's own persisted data files on a computer. Configuration information is distributed to all computers participating as a system. Each computer examines this information and extracts the configuration that directs it's work.
A configuration specification is defined by a data class that includes Meta data to direct data value conversion between data formats. A system administrator command uses a data class for a particular type of configuration specification to import or export the configuration content between text and serial format. This means an administrator sees configuration in an XML like text format while a computer persists configuration in a serial format. An application / server starts up by reading persisted configuration in serial format and converting it to in memory format.
A program copy instance within a system executes within the context of a system version. The infrastructure provides a method for each core function such as conversion of data content between data formats, file access with optional data conversion, obtaining configuration, and communicating to a program copy instance on a different computer within the same system version.
A system start command executes on each computer within a system. It looks for a new or removed system version. It starts or stops each program copy instance that executes on a computer for a system version.
A program copy instance can migrate persisted data from one system version to the next system version via computer files or Operating System IPC techniques. This is possible when two system versions execute their program copy instances at the same time on the same computer.
Message Communication within a Software System
Message communication between program copy instances is divided into the components Bus, localHub, mainHub, assigner, and recorder.
A Bus instance is part of each program copy instance. It supports creation of a point to point connection between two unique program copy instances on different computers. It supports publish and subscribe of information exchanged between program copy instances as an event message. A Bus connects to a localHub. A Bus sends and receives a message via a localHub.
A localHub instance executes on each spoke computer. It connects to each of the two mainHub instances. A message from a Bus is sent to each mainHub. A message from a mainHub is sent to a Bus. Any duplicate message from a mainHub is detected and discarded.
A mainHub instance executes on a central hub. One or more central hub computers are configured per independent network. A mainHub instance communicates with other central hub computers to choose one active mainHub instance per independent network. An active mainHub accepts a connection from a localHub.
Each connection between a mainHub and localHub as well as a localHub and program copy instance has a state of DOWN, CONNECTED, STANDBY, or ACTIVE. An event id is created for each connection so that the state is published to any interested subscriber.
The message communication components use both new and current message distribution techniques. For example, a sequence of messages are bundled together into a super message exchanged between a Bus and localHub or a localHub and mainHub. A super message is broken into individual messages that are forwarded to their destination. There are a configured number of preallocated super message buffers. A super message is sent when it would exceed the size of a buffer after adding the next in sequence message. It is also sent when it contains at least one message and there are no other super messages in transit between a Bus and localHub or a localHub and mainHub. This technique minimizes latency during moderate load while maximizing total messages that are exchanged during peak load.
Administration, event, and point to point messages are separated onto different TCP/IP connections between a mainHub and localHub or a localHub and Bus. This minimizes interference between different types of message communication and helps to minimize deadlock scenarios.
An event consists of a value, such as an integer or serial of a complex structure, along with quality codes and a time stamp converted to and from an in memory class that contains Meta data. An event is defined by a system event class or a user class based on a system event class. A primitive event is efficiently converted between its event class and serial format by algorithms embedded within the communication components. The size of the serial for a primitive event is about 25 bytes. A complex event is converted to and from serial by a system conversion algorithm. The serial for one complex event must be no larger than the configured size of a preallocated super message buffer.
A recorder remembers the last message published for each unique event id. The recorder has a privileged role as enforced by a localHub and mainHub. A recorder receives all published events. An active recorder can replay the last message published for each event id to another recorder or a subscriber as it is starting up.
An assigner decides which instance of a program copy is active. The assigner has a privileged role as enforced by a localHub and mainHub. The state of each connection is reported by a mainHub and localHub to an assigner.
Multiple assigner instances first decide which assigner instance is designated as active. The active assigner instance informs its localHub and each active mainHub as to the identity of the active assigner instance.
The active assigner instance has the functions:
- each connection state, as reported by a localHub or mainHub, is saved locally and published as an event.
- a request from a standby recorder for a message connection to an active recorder is processed by choosing an assignment and directing the end point localHubs and the active mainHubs to setup a connection.
- a standby recorder is made active when there is no current active recorder.
- a request from a program copy instance for a message connection to an active recorder is processed by choosing an assignment and directing the end point localHubs and the active mainHubs to setup a connection. A program copy instance makes itself standby at the end of synchronization with an active recorder.
- a standby program copy instance is made active when there is no current active instance.
- a request from a program copy instance for a message connection to an active instance of itself or parent is processed by choosing an assignment and directing the end point localHubs and the active mainHubs to setup a connection.
Each system version has its own instance of mainHub, localHub, and all other communication components. This isolates one system version from another system version. The message distribution algorithms take advantage of an unchanging and universally known configuration to efficiently and securely distribute messages.
Work Distribution
Work distribution combines a checkpoint and restore feature along with communication of work between 3rd party software executing on different computers. An infrastructure manager is a central point for checkpoint and recovery as well as a communication hub exchanging messages between a client session paired with a remote server session. An infrastructure executive provides an API for software to create a reliable client to server connection and exchange messages on that connection.
The infrastructure manager and executive execute as program copy instances within the software system. The executive starts 3rd party software that acts as a server, server with clients that use remote servers, or an application with clients that use remote servers.
A programmer designs and implements an application or server as a manager class and a server session class. A programmer also designs and implements a service as a service manager class and a service client session class with a directly callable service API. A message exchanged between a client and server is defined by a class with in memory Meta data to direct conversion of data content between data formats.
The infrastructure provides a base client session class and a base server session class. A server session extends a base server session. A client session extends a base client session. A client session to server session pair appears and works in a manner similar to a TCP/IP connection, even though it provides greater reliability and security.
A programmer defines optional restart information for a client session and a server session. Restart information is used by an identical server instance on a different computer to recover a session.
A server session is saved to an active infrastructure manager instance. A saved server session includes any client sessions being used by the server session. The manager forwards a saved server session to a standby manager instance. The manager extracts messages from a client session and forwards them to a connected server session. If a server session is connected to a using client session then the manager extracts messages from a server session and forwards them to a server containing the using client session.
There are types of server session that do not have a remote using client session. For example, an application session is a server session with no using client session. An application session (as defined and used by the following section) includes an external user session id that is used to establish an interface with an external user.
Note that a client session is only saved and restored as part of a server session being saved and restored. There is no method to save and restore a client session by itself.
A failed server session, along with client sessions used by the server session, is automatically reassigned by the manager and restarted by an identical server executing on a different computer. The server on the other side of a client to server session experiences normal operation except for the time needed to detect failure and perform a restart.
Messages and recovery information are converted to and from in memory format and serial format by using in memory Meta data. An infrastructure service manager only sees serial format. This allows a server to be written with one set of computer type, Operating System, and software language while a client can be any number of such sets.
Security is achieved by a server checking if a client is allowed to request a function. An administrator specifies client authority as checked by a server. This approach to security is difficult to defeat when a server is configured to reside on a different computer than a client.
External User Interface Server
The infrastructure includes an experimental user interface server that shows one approach for how an application / server can communicate with a local human user. It is a partial prototype at the time this paper was initially written. The design separates what an application / server knows from how information is presented to a human. Dynamic data content is exchanged with an application / server. Human interface details are specified via a configuration specification. This prototype approach can be adapted to support remote external human users with recoverable sessions.
Design Synergy
The system architecture is composed of layers built one on top of the other. The layers from the bottom up are: data representation; software system and message distribution; work distribution; user interface service; etc. The data representation layer bridges the different data formats of: text like XML; computer hardware specific data format; and serial data format. The software system and message distribution layer provides a near real time multiple computer event message distribution system along with multiple computer point to point message channels. The work distribution layer provides an environment for recoverable interactive functionality by combining a checkpoint and recovery feature with a message distribution feature. The user interface service layer provides local and remote end user interaction with services executing within the work distribution layer. One or more higher layers can be added to offer related services that provide a “cloud OS”.
Perhaps the most difficult aspect of software is that one can not see directly what is happening during execution. There are many indirect techniques to reveal some of what goes on. A source code print statement converts selected data values into human readable text. An interactive debugger allows the process to be frozen to permit display of various data values as text. A trace feature allows data values to be displayed as text within a trace entry of a trace file. A core dump displays the content of local memory as hexadecimal text. Each of these techniques has advantages and disadvantages.
A multiple computer system dramatically changes the usefulness of each of these techniques. For example, an interactive debugger is limited to a test situation where there is only one active user of a service (i.e. external user / application / server combination).
The use of in memory Meta data for a message, configuration specification, other run time class, etc. achieves an intended consequence. The main goal of such a data class might be to define and hold an inter-computer message but the data class can also be used to save the message content to a computer file as either serial or text. Similarly, a data class for a configuration specification can be used as a value embedded within a message. Furthermore, a data class with in memory Meta data can be inserted into an application / server text trace file with just one line of 3rd party source code.
An infrastructure class named gcErrorResult is the sole method used by the infrastructure to communicate error information. An application / server should use gcErrorResult for any error information. This class includes in memory Meta data so that it too can be embedded in a message, travel as serial between computers, or be saved as text.
The infrastructure contains two console commands. This is the minimum possible to configure and launch a multiple computer system. It is expected that this functionality will be moved into other forms such as an application using the infrastructure to provide remote system administration.
The design supports an envisioned future where a major software capability is bundled and exposed as a reusable remote service. A server is written in one software language using one operating system running on one type of computer. A client can be written in the same or different software language for any combination of operating system and computer type.
As more services become available, the time and effort needed to create an application / server should tend to diminish. It might become possible for a point and click utility to create a typical application.
Conclusion
This has been an overview of a balanced multiple computer software system. Reliability, security, and scalability are achieved at a reasonable cost. The infrastructure is a high quality building block for use with new software or existing software modified to use a client to server session pair.
The infrastructure is implemented within an available product line named ServiceFrame Infrastructure. Website softecosdk.com contains more information.
This paper presents a number of new and existing ideas that fit together to make a multiple computer software system. Thought experiments, experience, and common sense were used to devise this architecture and design. The ServiceFrame Infrastructure is a production quality product providing evidence that the architecture and design is beneficial in the real world. Formal proof is left to a theoretically minded reader.