Foundations of ISA – Base paradigm – Scale ISA global
Iteration 2: Step into oo paradigm – identity axiom
What's identity ?
First, this post will certainly not cover the whole object Identity subject. It's ambition is only to unveil major aspects of this axiom in the perspective to examine its implications in ISA (and I hope not to forget some ones). So what are the subjects on identity ?
- addressing : Being able to locate, to address the object behind the identity.
- Unitarity: The Object is the fundamental unit of data and of treatment in the oo paradigm. The only way to access an atom (field or operation) is to pass thru the given individual object (at contrary of relational, functional or atomic worlds – Cf. Available paradigms overview).
- Uniqueness: An object is unique, in the sense that by definition the identity defines a single individual.
- Ubiquity (be in several space places at the same time):
- In a computing environment, a single object could be instanciated several times. This is particulary true in a distributed environment. But not only, because a process can instanciate several times the same “toto” string for example. This is a fortiori true between processes on a single execution node.
- In a distributed computing environment, a single object could reside in several places. This means being persisted on several nodes.
- Versioning (have several states over the time): This property is strongly related with the State axiom. So it will not be extensively studied in this post. However, when it applies to regular Objects, the states versioning is the main subject. But when applied to meta-objects, like class, Component, universe, etc. the versioning must be studied specifically because the deployment axis has to be considered.
I will now study more deeply each of these subjects.
addressing
addressing is the mean to access unambiguously an object. The usual and effective way to do that is thru a memory address (reference or pointer in RAM). However this way is limited to instantiated objects. But an object can be in several other situations : persisted or instanciated; resident on a single or on multiple nodes; current state or histories; complete or partial view; implements one or several classes / interfaces either permanently or evolutive; from some occurrences to several billions; access rights; object integrity.
ISA must supports all these addressing situations.
Waouuuhhh !How far are we of the usual addressing mechanism thru memory address. That's the irreplaceable vertu of the Ideal Software Architecture approach. We first examine the selected paradigm, the resulting concepts, then explore all the consequences and finally elaborate the solution with pragmaticism. That's just impossible in a foisonnant world, because of its erratic trajectory. |
Unitary
As pointed in previous posts, the identity axiom implies that an Object is always accessed in its whole : It is the unit of work of the oo axiomatic.
This implies 3 conceptual weaknesses of the oo paradigm:
- This limitation is at the root of the RDBMS resistance, while OO have penetrated the other programming territories. Accessing fields (columns) directly is more efficient.
- It is also at the root of resurging functional approaches. Working directly with functions is more flexible than have to deal with objects's methods.
- Finally, this is also the root of the poor supports of transversal features (inheritance of methods defined statically). The Aspect paradigm succeded for this reason.
This fine grained unit of work also penalizes the performance on large volumes and the scalability. All the situations where it is more efficient to work at a larger scale (per set of 100 objects for instance).
ISA must give a pertinent answer to these weaknesses, while remaining in conformity with the OO paradigm.
Uniqueness and Ubiquity
On one hand an object is unique, and on the other hand it can live in several locations. This implies that a clear distinction between Object and Instance has to be done.
Like a class and an Object are different concepts, an Object and an Instance are also distinct things. The relationships between these concepts are in both case “instantiation”.
Moreover, An Instance can be of different kinds: full or partial view of the Object, in memory or persisted, synchronized or simple snapshot, altered are committed.
ISA must work at the Instance level and ensure the consistency of the Object.
| In the OMG's Four Modeling Layers (MOF), the class is manipulated at layer M1, and the Object at layer M0. There is no distinction between the concepts of Object and of Instance. However, in a distributed architecture as ISA targets, these two concepts are distincts as we have just seen.
My first intention was to add a M-1 layer for Instances. |
Versioning
The versioning of regular objects will be treated together with the axiom 5.State. One can just say that an object has a single identity, unique by definition in a committed state.
The class object follows the above rule. But the versions of this Class must cohabitate in order to supports features like the human readability, migration or integrity of non-updated components that rely on a previous version of the Class. Therefore, the versioning of classes is different of the one of objects.
More generally, the versioning of meta-objects, like a Class, appears to be different because of their structural nature and of their deployability.
A Class defines one responsibility and the structure that implement it . The classes are designed, implemented, tested unitary, integrated, qualified, deployed, etc. That's the particular life cycles of that meta-object. This have to be taken into account in the axiom 5.State study.
ISA must provide a versioning mechanism.
This mechanism is enriched, in a user friendly manner, for the meta-objects to ensure the consistency of existing Objects.