The Architecture of a System
IT Systems are composed of Software and Hardware parts. The inter-working of these provides functionality to systems. Hardware and Software are, in turn, composed of many components. For these components to work together there must be some form of interface that allows a component to provide services to others. The set of interfaces that a component provides is what gives value to the component and this value is enhanced if the interfaces are both public and have a good supporting documentation.
A system architecture expresses the disposition of components in the system and their inter-working. A reasonable representation of a system architecture that is used in most IT systems is laid out in the following diagram.
There are three main interfaces in the system, the Hardware, the Kernel and the System Interface which is the interface used by applications to access system resources including the Hardware. There are a diverse set of standards that, at some level, allows developers to port applications to a given system. However, these standards are a mixture of proprietary, open or even some hybrid form where part of the interface API is public and some part is private, usually to give the provider of the platform some edge over the competition. This lack of a common and open system API makes it hard for developers to port applications between heterogeneous systems due to the technical complexity of creating and maintaining applications.
Drawbacks
Applications that access system services must either use an existing programming language or a framework that already provides an abstraction of the required services. However, there are some issues with the usage of an existing language or framework namely:
The selected application programming language or framework doesn’t provide support for the required system functionality.
The programming language or framework that provides support for the required system services is not the best option for the application and using such language or framework constrains the programming infrastructure.
The usage of some language or framework may impact the performance of the application.
The programming language or framework may not provide support to some Operating Systems.
Another possibility is, for developers, the implementation of their application on multiple platforms. Such endeavor requires among others:
Accessing heterogeneous platforms or Operating Systems forces developers to create an abstraction API which is specific to their requirements. Such an API tends to be less general and with more limited re-usability.
Every platform has a specific tool chain that is favored for building system applications. This implies that each application supported platform must use a different building infrastructure. While this can be mitigated to some point by reusing some components in the tool chain there is also an extra effort to such reusability.
Developing applications to support different platforms or systems requires a deep knowledge of the system mechanisms and idiocracies.
A less though problem in API design is the versioning of the API itself. Programming for a set of diverse systems implies also to think on the underlining API versioning which may require developers to provide not only different versions of their system API but also to provide support for different versions of the target platforms or Operating Systems.
A Common System API
Considering all the drawbacks, the limitations and effort involved, a better way of developing multi-platforms applications is require. The preferable solution would be to use a system API that is available in all platforms, that has a common versioning and that provides generic concepts reusable across systems. It is also important that such API can provide access to specific platform or OS mechanisms so that client applications can select, at runtime, the best mechanism for the platform.
What would be the end goals of such Common API? It must provide answers to the drawbacks of the current approach but would also enable new system interaction models and provide programming language with common idioms. See the “Purpose” of such API.