Cross-roads in object histories and why single object histories are only part of the story
This post is addressing the observation that there are events—in the sense of the source—that
may involve multiple objects of possibly different types.[1]
Now, if we look at the desideratum that
and we have two or more objects o_1, o_2, ... interact with each other as part of a program, we would have to pack them up (temporally) into the sum \sum_i o_i of the previous objects o_1,o_2,... to give the execution of the program a place to be “located”, namely the sum object \sum_i o_i. E.g., for n=2, this would involve first deleting o_1 and o_2, then creating the sum (o_1 + o_2), running the program on the sum, and finally splitting the next version of (o_1 + o_2) into new objects o_1' and o_2'.
[☜ here is some background material concerning object history, object versions, and (im)mutability---click the triangle to unfold this material]
For the post, it may be helpful to recall that an
object can be thought of as a sequence of versions, the states that the object has assumed and will assume as the result of the computations that are applied to it. We will call this sequence the object history. It is a completely static picture of the object’s behavior. Since the entire object history is not known until the system has finished execution, this is clearly a logical concept, rather than something that has a counterpart in the real system. Nonetheless […], imagine that a program does execute in an environment where all the histories of all shared objects are known.[2]
The typical situation is a swap of assets, or concretely our typical kind of example.[3]
sequenceDiagram
participant Alice
participant John
Note over Alice,John: begin swap
par
Alice ->> John: have an apple
John ->> Alice: have an orange
end
Note over Alice,John: end swap
We can use plain flat transactions (potentially shielded) to achieve the above synchronization pattern for a pair of objects—to be precise, two potentially concurrent versions of objects. Moreover, as part of the desiderata, we have the begin transaction-end transaction-blocks, which seem to be exactly for this kind of interaction between objects—as illustrated above.
TL;DR
- some transactions (on a controller) commit the effect of program executions involving several appends to histories of several objects
- while each of the extended histories is consistent in the context of the respective object, only the extension of all the object histories is the intended state change of the transaction
A potential solution would be the (temporary) grouping of objects for some purpose. In fact, grouping of objects may be useful also for moving objects together.[4] This grouping is de facto necessary to collect all necessary data for creating the proofs of a (shielded) transaction.
How does it related to the title and what else?
Object histories naturally evolve jointly. Forcing several objects to become one is maybe too drastic, in particular if it is only in the context of a certain common “task,” which could be any of a session, transaction.[5] A notion of object group is not a new idea.[6]
Object-Centric Process Mining: An Introduction Wil M.P. van der Aalst ↩︎
page 64 of Naming and synchronization in a decentralized computer system. Massachusetts Institute of Technology, Cambridge, MA, USA, 1978, emphasis in the original ↩︎
Let us leave aside even the complications of objects that are controlled by different controllers. Image the single controller case and all relevant (resource represented) objects are controlled by a single controller. ↩︎
In fact, this idea is described in the context of Emerald. ↩︎
In short, not all interaction is naturally asynchronous in the following sense: The most general form of a rewrite rule for the modeling of object-oriented systems is the following:
↩︎
In fact, merging of rule sets and facts also makes sense in the context of a logical approach, e.g., in PROLOG. ↩︎
