The world is the totality of facts, not of things.
Ludwig Wittgenstein
As the so-called internet of things (IoT) seems to bring together people, systems and devices, the meaning of real-time activities may have to be reconsidered.
Things, Facts, Events
To begin with, as illustrated by marketed solutions like SIGFOX, the IoT can be described as a fast and stripped-down communication layer carrying not so much things than facts and associated raw (i.e non symbolic) events. That seems to cut across traditional understandings because the IoT is dedicated to non symbolic devices yet may include symbolic systems, and fast communication may or may not mean real-time. So, when applications network requirements are to be considered, the focus should be on the way events are meant to be registered and processed.
Business Environments Cannot be Frozen
Given that time-frames are set according primary events, real-time activities can be defined as exclusive ongoing events: their start initiates a proprietary time-frame perceived from the outside as being without duration, i.e as if nothing could happen until their completion, with activities targeting the same domain supposed to be frozen.
That principle can be understood as a generalization of the ACID (Atomicity, Consistency, Isolation, Durability) scheme used to guarantee that database transactions are processed reliably. Along that understanding a real-time business transaction would require that, whatever its actual duration, no change from other transactions would be accepted to its domain representation until the business transaction is completed and its associated outcomes duly committed. Yet, the hitch is that, contrary to systems transactions, there is no way to freeze actual business ones which will continue to be carried out notwithstanding suspended registrations.
In that case the problem is not so much one of locks on DB as one of dynamic alignment of managed representations with the changing state of affairs in their actual counterpart.
Yoking Systems & Environments
As Einstein famously said, “the only reason for time is so that everything doesn’t happen at once”. Along that reasoning coupling constraints for systems can be analyzed with regard to the way events are notified and registered:
- Input flows: what happens between changes in environment (aka facts) and their recording by applications (a).
- Processing: could the application be executed fully based on locally available information, or be contingent on some information managed by systems at domain level (b).
- Output flows: what happens between actions triggered by applications and the corresponding changes in the environment (c).
It’s important to remind that real-time activities are not defined in absolute time units: they can be measured in microsecond as well as in aeons, and carried out by light sensors or by snails.
A Simple Decision Routine
Deciding on real-time requirements can therefore follow a straightforward routine:
- Should changes in relevant external objects, processes, or expectations, be instantly detected at system’s boundaries ? (a)
- Could the interpretation and processing of associated events be carried out locally, or be contingent on information shared at domain level ? (b)
- Should subsequent actions on relevant external objects, processes, or expectations be carried out instantly ? (c)
Positive answers to the three questions entail real-time requirements, as will also be the case if access to shared information is necessary.
What about IoT ?
Strictly speaking, the internet of things is characterized by networked connections between non symbolic things. As it entails asynchronous communication and some symbolic mediation in between, one may assume that the IoT cannot support real-time activities. That assumption can be checked with some business cases given as examples.
Further Readings
- Events
- Time
- Real-time Activities
- Synchronization (objects)
- Synchronization (activities)
- From Processes to Services
Right, that distinction is critical.
https://caminao.wordpress.com/when-representations-are-to-be-used/real-time-activities/
You might find it useful to distinguish between real time and synchronized scenarios. The two guitars in a Les Paul recording were not played at the same time but were synchronized. In many applications a deferred time decision space is adequate so long as the factors therein are all adjusted for the time they occurred and that the delay from event time to data availability time is not too great.