Summary

This little series of blog postings tries to discuss the topic of

• A Common Layering of the Universe, or, in other words,
• An Order of Creation.

The following blog postings are currently available within this series:

• We are all Brothers and Sisters, an “Order of Creation” is bullshit
  see https://areasharpa.blog/2024/04/01/layers-planes-tiers-wtf/.
• A more scientific discussion about why we COULD or why we COULD NOT split the universe into layers
  see https://areasharpa.blog/2024/04/06/protocols-and-interfaces-wtf/.
• An idea, why the discovery (invention?) of abstraction layers in the Information Sciences of the 20th century could have incented the discussion about the Layers of the Universe, freshly
  Introduction: see https://areasharpa.blog/2024/04/07/layer-mania-wtf/,
  Protocols and Interfaces: see (THIS POSTING) https://areasharpa.blog/2024/04/14/software-protocols-and-interfaces/.
• A philosophic summary: see https://areasharpa.blog/2024/04/17/layer-mania-ii/.

Introduction

Please don’t be shocked. This posting will be about some philosophy.

This is not a blog posting about science of nature, nor about science of technology, it could even be interpreted as a religious posting.

Hence, this posting is a temporary contradiction (let’s say an exception according to Heisenberg) to my principle about keeping this blog an agnostic blog.

If you cannot accept this, then please ignore this posting 🙂 .

Dear Reader!

OK, when I talk about some INNER layers of each entity within the universe, then I mean this in a close relation to the terms of SOFTWARE INTERFACES and SOFTWARE PROTOCOLS.

Also, if you are an IT technician or an IS scientist, then all this will not be new at all.

You know it under the term of an

Abstraction Layer

Since the whole information technology relies on the exchange of electro-magnetic energy, hence any computer system could – theoretically – be described by Maxwell’s equations (https://en.wikipedia.org/wiki/Maxwell%27s_equations).

However, describing each and every software by the electromagnetic waves that are created by that software, would be a kind of “mission impossible”.

The electromagnetic waves that cross the integrated circuits of a computer system, back and forth, are not really an appropriate vehicle to describe the function of a computer system in a way that could be understood by a single human being.

Even the calculation of such a simple equation like 1 + 1 = 2 would involve hundreds, thousands of electro-magnetic waves that would have to be considered.

We need to reduce the complexity of our description (we want to explain it to managers 😉 ).

So we need a higher level of abstraction. We are trying to describe the potential exchange of information by “Software Protocols and Interfaces”.

All this will become easier to understand, when we meditate a

Simple Example

This example is an example of a simple network service that can be executed by simple client server computing.

This simple network service (drawn in red color in Figure 1) is executed by the transport of two network messages by the transport layer.

1. (the red “1.” in Figure 1) The transport layer transports a Request Message from the Client to the Server. This Request Message will trigger the Network Service via the Indication primitive
2. (the red “2.” in Figure 1) The transport layer transports a Response Message from the Server to the Client, after the Service (the red “bubble” in Figure 1) has processed the information from the Request Message

The set of rules that have to be applied, when creating, transporting an processing the Request Message and when creating, transporting and processing the Response Message have to be specified in an interface specification *).

This interface specification specifies the red Network Interface NI (see Figure 1) in ALL layers *).

Such an interface specification is needed, if one wants to implement clients and servers completely independent of each other. It is often required by economic boundary conditions to separate the vendors of clients from the vendors of servers, hence it is always good to have such interface specification *).

Such an interface specification is sometimes called a “Protocol”.

A “protocol” more or less collects all rules that must be obeyed for the access of the specified network services. When we connect it with the example it the blog posting https://areasharpa.blog/2024/04/06/protocols-and-interfaces-wtf/ (Figure 1 there), then our “Server” here is there the “provider” of the service and our “Client” here is there the “user” of the service.

*)

The “Protocol” specification of the “Network Interface” NI is necessary, if the implementors of the Client and of the Server need to be separated (e.g. for economic reasons), but it is not necessary for every developer to know the “Protocol” specification.

The concrete implementations of the transport layer will provide APIs, here called “SAP – Service Access Point”, which serve as abstraction layers for the transport layer and for the protocol.

If a developer wants – e.g. – to implement the appication software of the Client, then he/she just needs to know, how to handle the primitives of the SAP at the Client.

I.e. this developer needs only to know, how to call the SAP with a “Request” primitive, and how to handle the “Confirmation” primitive that is returned by the SAP.

If the SAPs are well defined, then the application programmers will not have to have a look to the “Protocol” specification.

Philosophic Evaluation of the Simple Example

This will follow next weekend.

Have a nice week,

Yours Christoph