Modular Oriented Programming and Communications
I would describe Modular Oriented Programming as programming with the intent on having reusable and interchangeable compiled code. The term used to describe their design is “Loose Coupling”. Modules interacting with other modules is a communications problem. Its Machine-to-Machine communication.
Language allows us to communicate with complete strangers or people we’ve never met. The same situation exists with modules. Modules are meant to be designed by different developers. Hence, when working with modules, there will be a lot of foreign code. The term “foreign code” is a term I use to describe code that is completely outside of your control. Code that was given to you but you had no part in its design. This means that there needs to be a set of agreements that you can rely on, that allows you to use foreign code safely and efficiently. Such set of agreements is a language. People might use the term protocol or standard but I like to use the term language. This is code interacting with other code. The term language implies flexibility and interoperability. The terms protocol and standard imply rigidity, restrain or limitation.
Modules can be represented graphically. Exhibit A is a graphical representation of two modules. The tentacles and spikes coming out of them are called end-points. These are the inputs and outputs of a module. End-points used for input are receivers (abbreviated RX). End-points used for output are transmitters (abbreviated TX). Modules work with each other by connecting these end-points. Hence no programming is necessary. All an application developer needs to do is connect these end-points together.
To enable modules to work together we have to agree on the data that comes out of the transmitters. Lets look at exhibit B. We have two aspects of data that we have to look into. Data format and data semantics. Lets look at an integer. Data format would be the integer is 32bits or 64bits. Big endian or little endian. Data semantics is basically what does this integer represent. It could be temperature, length, age, strength, voltage, etc. Modules can be blindly connected together by matching data formats but matching data semantics is also necessary. Because this is where hacks and bugs come into play. Say that a receiver accepts an integer and expects it to represent temperature. There has to be an upper and lower limit. Its theoretically impossible to have temperatures lower then -273 degrees Celsius. But hackers will attempt to hack and try to send temperatures lower then -273 to the receiving module.
When you are in control of both the transmitters and receivers you don’t have to formally define data semantics because you know how your code will behave. If its behaviour is to your satisfaction then everything is fine. BUT when you are dealing with foreign code you will have to worry about data semantics. You will want a set of agreements and expectations about the nature of the data you are getting from foreign code.
Exhibit C. I propose that we start standardizing machine-to-machine vocabulary. Basically we need to develop a worldwide dictionary of data semantics. Hence when you publish your modules you can declare that they conform to specs such and such. And everyone who understands that spec can work with your modules. As a note: SavageGardens will concern itself with machine vocabulary.
Exhibit D just illustrates how modules easily allow for interception or a man-in-the-middle. Sure middlemen could be hackers but they could also be security. They can have a useful purpose such as auditing, filtering or sanitation of data. Useful for debugging or making sure data you are getting is safe. A blast door or firewall if you will. These blast doors can be opened or closed at run time depending on threat level. Call it adjustments between safety and performance.