This page gathers my raw ideas as they appear in my brain. Therefore comments on this page is just something like as idea snapshot. It do not reveal anyhing on Ideal Software Architecture, but the way concepts comes into my conscience.
| Legend |
| The thoughts incorporated in ISA appear with this green box containing the location where this idea is taken into account. |
| The thoughts partly incorporated in ISA appear with this blue box containing the location where this idea is taken into account. |
| The thoughts rejected from ISA appear with this red box containing the location where this idea is rejected if any. |
| The thoughts not actually incorporated in ISA appear with this gray box containing the location where this idea is not taken into account. The purpose of this box is mainly for blog internal management. |
#
There is a philosophycal difference between SOA and OO.
SOA is about Service provided/to provide, about a Resource to be available. It is in line with a phisosophy where things and human are just here to be used, to be consummed.
OO consider the Object in its whole, in all its aspects, the interface of course but also its internals. It is a more human and nature friendly because at is heart is to consider individuals.
Definitly, even where it is very not expected: “technology is not neutral”.
#
`LL` – Call rythm: Synchronous/Asynchronous
In order to manage gracefully local and remote call, a Call always has an Argument Rythm (Synchronous (default) or Asynchronous) the caller can set.
In the first case the Results it is waited to be available to continue execution flow (in fact since all Object have a thread and that there is a final block of code rendez-vous the calls are always asynchronous).
In the second case, a nothing is returned (or an Exception throw if the call cannot be taken into account), and the caller Object is notifyied of the result thru the Observer DP mechanism.
To deal with local versus remote calls, having In/Out argument is not possible. On the other hand it is wanted to be able to have multiple results.
So a Call have Arguments that are its input and Results that are its output.
Syntax:
Real Rho, Real Teta: My complex number angular form: Angle unit: Radian, Precision: 3.
#
This doesn’t means that In/Out argument is not present in `LL`, because they increase widely performance in modifiying directly the argument object (sets for instance) – follow the mutability for efficienty principle -, but that they can only be used in local call, therefore they cannot be part of a remote View.
#
`LL` Syntax tip.
The : is the equivalent of both affectation operator (= in C) and of groupement start operator ( left parenthesis ( in C).
The ; is the groupement end operator ) right parenthesis ( in C) for the closest : being not filled.
The . is the end of instruction operator (; in C) therefore it close all openned groupement.
The , is the groupement element separator.
#
`LL` – Syntax
A/ Regular line of code:
1/ Variable creation.
Variable : Constructor.
Variable: Full name, String.2/ Value affectation.
Variable : Value.
x : 2.3/ Call.
Variable Call : Arguments.
Full name concatenate: current person first name, space, current person last name.B/ Condition.
1/ Condition: Nominal value generator, Nominal values executor.
a) Nominal value generator
– Nominal value or variable (true for instance).
– Boolean expression returning a Boolean value.
– Call returning a single Nominal value Result.
b) Nominal values executor
Indented list of couple Nominal value : Block of code.
Condition: x > 2,True:
s: Limit reached.
False:
s: In progress.
.
Condition constructor explicit call is optionnal, in this case the inference ponctuator ? could be used.
? b,True:
Console write: b is true!.
.
Simular Condition construct applies to Serie.
#
`LL`
The indentation discribe the execution path a level is executed only if its parent level is executed (aka is true).
#
`LL` Object “pseudo-keyword”
Condition, For all, For each, Call, Variable are Object of the LL language.
When LL is interpreted, the code execution just follows what these object express.
When LL is compiled, these object execution path are compiled and optimized. This means that the original exact execution structure is lost for a more efficient but equivalent form.
In Condition, For all, For each, etc. metaclasses, there is a $ member that has the current value of the expression or iteration. It also has a / member that referee the parent object (another embrasing For each for instance), and therefore a /$ variable that point to the current value of the execution path parent.
If a name is need for the current value instead of the regular $ sign, for readibility for instance, it is always posible to affect a variable with $.
#
`LL` Exception vision
The Exception construct has proven to be a very useful to control execution flow in case one problem occurs.
However, the general way programming language like C++, Java or even C# provide this feature seems not very adequate.
1/ All of these languages support Exception by a Class for each individual problem: That’s enormous in volume, in verbosity both at elaboration and at catch time.
Fondamentaly: Is each exception case a Class ? The question have to be stated.
1-bis/ These languages also merge the notion of Exception and of Error. This is abusive.
An Exception is some thing that introduce a rupture in the normal execution flow of instruction.
An Error is an abnormal situation. Exception is just a way to handle Errors.
2/ This way of supporting Exception Object drives to have Exception to be unitary. What’s about having several problems to signal to caller? You only communicate the first one? This driven developer to put the list of problems elsewhere: Not very nice.
3/ Distinction between RuntimeException and DesignTimeException put Java in a situtaion that you could declare Exceptions a method throw, but even if you don’t, RuntimeException can always be thrown: A bit contradictory.
At contrary, C# do not declare Exception, but in this case what are the Exception the caller is expecxted to manage… Confusing isn’t it ?
4/ In real life, the effective case you need to distinguish is about the Exception (Error in fact) nature, because the treatment sould often differ. There is in fact only 3 relevant natures:
– Technical (disk is full),
– Functionnal (you cannot validate while a given field is not filled is some circumstances),
– Business (you cannot perform debit of 100$ your account because there is only 5$ on it).
#
`LL` An Exception approach
Having an Exception class per exception case is an misuse of OO.
A class definition is:
A Class specifies a classification of objects,
and of the features that characterize the structure
and behavior of those objects.
But all Exceptions in C++, Java, etc. shares the same features in 99%. Therefore the precise problem case must not be supported thru classification.
On the other hand, Exception not only occurs in Error cases:
– It can be convenient to stop a treatment when the result is reached (for instance in nested loops)
– Some other case could be listed: continue, break and return keywords, yield return/break in C#
To handle errors an Error class having just an error code is much more appropriate.
This is an alternative approach:
– Have a single root Exception class that can be thrown. This class have an Action operation.
– Have 3 concrete Error classes for each nature Technical, Functionnal and Business because their structure may differ and in particular the Action method.
– Error(s) are injected at construction time in the Exception.
– The Exception precise case is supported by a Nominal that enumerates all possible cases: Error case.
– An Error can have several Error case.
TODO: Continue / Construction initialization with Exception cases and Error Message construction thru “Error case context variable” that are subNominal associated to Exception case via a Qualifier (UML qualifier).
#
The Exception have a Property named Circumstance, telling in wich circumstance the Exception was thrown:
Precondition
Body
Postcondition
Invariant
#
`LL`
When multiplicity maximum is greater than 1 ISA metamodel use plural for Field and singular for Role. This not consistant.
In this case the Plurar should be always used.
But, when acceding an individual member the english sentence (LL instruction) become incorrect:
Employe Luc : The employees at i.
I should prefer:
Employe Luc : The employee item at i.
To allow that, the best is to declare an alias, here The employee item
#
No another solution is to keep the plural and to have the compiler smart enough to not allow punctuation missing in evident cases like single parameter in operation.
Ex:
The Company class have and Employees array field.
Arrays have an Item operation to access an array cell by its index.
The regular access syntax is:
Variable my employee : My company employees number : 123.
Since the item operation only have 1 mandatory parameter, the last : is obvious and can be inferred by compiler.
The simplified syntax become :
Variable my employee : My company employees number 123.
This form is very similar to English (Cf. the Bing translation).
Variable my employee : in My company employees with registration number : 123.
Other possibility, the compiler ignore the conjonction like in, with, etc.
#
Managing Object replication
Have a look to conflict-free replicated data type (CRDT)
https://www.programmez.com/node/26763
https://www.programmez.com/node/26765
https://en.wikipedia.org/wiki/Conflict-free_replicated_data_type
#
The problem with this approach is that it do not address the concurrency of reading.
Suppose A and B viewing an object O with fields Ox and Oy.
A makes an update of Oy because Ox and Oy have a given value.
B update Ox before but A is not yet informed of that when it performs its update.
This class of problem cannot be solved by CRDT.
The only way is to be have transaction ordering and to reject update based on obsolete data.
#
The problem with the transactionnal approach is that even in cases the merge can be done (CRDT problem class), it is not and the update is rejected: This is not fluent !
Moreover, this case is in fact the most frequent 🙁
Making the transaction way both unconfortable and often slower.
On way to solve that could be to have a “Mergeable” property on transaction with default value true, given the better of both approach (both static and dynamic). Operations that results in non mergeable states will set Mergeable to false, and other operations will let it unchanged (in fact setting this property to true must be prohibited).
#
`LL` metamodel
Consider suppress Tree DP at the root of LL to not enforce a too abstract relationship that needs Invariant (contraints) when becoming more contrete (like in UML with so many obscure constraints). It is a principle somewhere in the requirements.
Moreover this drive to problems like an Assembly that is an Element (a leaf): but it is not !
#
Upadate to perform in OO and SOA paradigm
– OO approach in ISA where every thing is an Object, implies that the whole Architecture conforms to the UAP: Uniform Access Principle.
– At contrary, SOA do not promote UAP in any way. First because there is not strong correlation between the way data are exposed and how they are stored. Second, because of the variety of SOA “standards” and way of implementing the “standards”. Third because every thing is not SOA even in a SOA oriented organization (the O.S. at least).
UAP alignment at this broad level do not promote silo. At contrary UAP nonalignment very very often implies silo IT. This encourage to have project that implements the so heretic Data Centric architecture.
ISA do not need that at all. All Objects are available anywhere if you have access rights on it!
#
O.S. Processes are usefull to manage resources and in particular memory in order to avoid unauthorized access. In fact a Process act as a kind of cage in which the objects are enclosed.
An O.O. architecture freed of Process O.S. should address that unauthorized access issue.
Software solutions are known to be subject to failure, those based on hardware too, as have shown the recent Meltdown and Spectre threats.
The microkernel O.S. based on a type safe system appears much more secure by construction, and in particular the O.O. oriented ones. It is the case, among others, of the Microsoft Research Singularity Cf. The Singularity System.
In Singularity however the Process concept remain present.
In ISA, to be freed of Process and to completly rely on the unique concept of Object, some additional properties to Singularity principles have to be enforced at the microkernel level:
1/ Only authorize low level language (ASM, C) execution on a small set of certified Assemblies. The best will be to only have the core O.S. to be in this case.
2/ The only available language is LL that is a type safe system managing the memory and its access in a type safe manner.
#
The only remaining problem for O.S. and more generaly code execution safety is the deadlock problem if each Object has its own thread.
Exemple of possible deadlock call stack:
A1.a -> B1.b1 -> C1.c1
D1.d -> C1.c2 -> B1.c2
If we are simultenaously in the second step of these 2 call stacks, a deadlock occurs.
The common solutions are be single threaded (GUI main thread, Process), and/or use locks (mutex), or other like channels. All these solutions either lost the multiprocessing capabilities or require to explicitly manage it.
The 1 Object / 1 Thread approach is here to avoid both of theses problems. So how to resolve the deadlock issue ?
One solution could be to never be engaged in situation where deadlock could occurs. The exemple above clearly show a circular dependency between B and C. If having circular dependency is prohibited, therefore deadlock can never occurs.
The solution is here. Any Assembly that result in introducing a circular dependency cannot be compiled.
Is that possible ?
In most situation yes, and it is moreover a sign of good design.
But not in all situations.
1/ The most basics foundations of ISA cannot be in this situation. For instance, the LL bootstrap Assemblies Model, Metamodel and Elements are stongly coupled.
2/ Complex Assemblies often have classes that are circularly dependent.
So the circular dependency prohibition rule should be mitigated like this:
– Assemblies can have internal circular dependencies. This means between artefacts it contains (Class, not deliverable Assembly). This encapsulated the circular dependency scope.
– Deliverable assemblies cannot depends circularly between them.
Well. This mostly solve our problem.
But the problem remain unsolved for deliverable Assemblies incoprorating circular dependencies!
Here the solution is following: Staticaly analyse dependencies at compile time, identify the possible deadlock execution path, and at runtime froze executions of paths that are potentiely deadlock generator with another on going execution path.
In our exemple:
A1.a -> B1.b1 -> C1.c1
D1.d -> C1.c2 -> B1.c2
B and C classes are cross dependent, but not A and D.
– Before A1.a calls B1.b1, the compiler introduce a lock to acquire the B dependency grappe. Therefore it locks all running Objects of B and of C Classes when they will all become available (this can take a significant amount of time).
– A1 Object has now the lock on B1 and C1 (and also on all running Bi and Cj).
– Before D1.d calls C1.c2, it tries to lock all B and C. They are locked, so it has to wait.
– The A1.a path is the only path among dependent execution path that can run. So the -> B1.b1 -> C1.c1 is played.
– After A1.a, the locks on all B and C is released (the compiler have incorporated that unlock call on the O.S.).
– Waiters are notified of this release.
– One will win the locks, say it is D1. Then the D1.d -> C1.c2 -> B1.c2 can be played.
#
This Assembly internal circular dependency resolution mechanism works, but it can results in execution stall. So it is also strongly recommended to always avoid circular dependencies even within an Assembly.
The usage of the Mediator Design Pattern could be a great help to that.
And better the multi-layer Mediator.
Ex:
Command orchestrator (Shop desk)
-> Store -> Stock -> Item
-> Command -> Command line
-> Expedition
-> Preparator
-> Pack
-> Send
#
Remain the question of the self dependency. When an operation of a class A depends of another instance of A. When A1 Object depend
s of A2 Object (compare operation for instance).
Following our pattern all other instance of A should be lock when say A1 has control, even A2. This could be tricky to manage to let A2 be unlock only in the scope of A1.
Worst. All Objects, all Type in fact, are in this situation because of the equality comparison operator. There all descendant of Object must be locked when doing something. This off course works, because it just means that you are monothreaded!
This approach is definitly not viable.
#
Therefore it appears unavoidable to manage manualy by code to eliminates deadlocks and race conditions.
The most common way it to use lock (mutex).
In LL, it could be possible to simplify that management by declaring a method to be thread safe.
In this case, the Objects involved in this method that are not owned by the class (fields) or the method (local variables) are locked before the methods begins. Unfortunatly the set of objects can be complex to determine and may vary during the method execution.
Thread safe method must have a particular form:
(a) A query part that populate a set S of objects to lock (only queries are allowed in this part).
(b) A command part where the alterations of states are performed.
The execution is as follow:
– (a) => S1
– lock S1
– (a) => S2
– If S1 = S2 then (b), unlock S1
– Else unlock S1, restart
The S set could not to be explicit, while it could be deducted of the analysis of (b) by the compiler.
#
Therefore it appears unavoidable to manage manualy by code to eliminates deadlocks and race conditions.
The most common way it to use lock (mutex).
In LL, it could be possible to simplify that management by declaring a method to be thread safe.
In this case, the Objects involved in this method that are not owned by the class (fields) or the method (local variables) are locked before the methods begins. Unfortunatly the set of objects can be complex to determine and may vary during the method execution.
Thread safe method must have a particular form:
(a) A query part that populate a set S of objects to lock (only queries are allowed in this part).
(b) A command part where the alterations of states are performed.
The execution is as follow:
– (a) => S1
– lock S1
– (a) => S2
– If S1 = S2 then (b), unlock S1
– Else unlock S1, restart
The S set could not to be explicit, while it could be deducted of the analysis of (b) by the compiler. If the compiler cannot lock all accuratly all objects, this can be detected at run time during tests by making operations on not locked objects.
#
Simplicity is the key word of success
Why PC was successful? Because the make possible to make documents to any people.
Why the Web was, why CMS are ? Because displaying a page is simple without knowing about computing (windows management, image, etc.).
SOA is also in this case: Not the wide, well done, governed one; but the day by day one where services are every where.
However the simplicity approach is obviously limited. We have seen in these blog that the best way to follow from a computing point of view is to be Object Oriented.
So ISA must reconciliate the two approach. Cf. ISA Wish N°5 – Simple and freed of experts
So being able to simply display an hypertext document with low computing knowledge is very very important.
#
How to achieve that simplicity and OO target ?
1/ The Use Case is our normal entry point. But is is a quite complex computing concept. So basic use cases to display a document must be basicaly provided, like those provided by the O.S. to substituate command line console.
2/ Document is an Object known of ISA.
It is at the hearth of the merging approach simplicity + OO.
Composed of Section giving the underlying space (2D, 3D, Euclidien or other, Width, Height (possibly infinite), Page, etc.)
3/ Rich character set (64 bits) that include presentation is also known of ISA (See Text and Glyphe classes).
4/ This rich text must have Object linking and embedding incorporated. Cf. Brainstorming comment of 8-Sep-2017 (09:57) http://isa-blog.azurewebsites.net/brain-stroming/comment-page-5/#comment-1544
5/ Common Objects like Place holder (similar to HTML div), Table, Image, etc. must also be provided.
#
About table object
To be simple to use and also powerful, a table object could have 2 variants.
Tabular table:
The table is composed of a fixed set of columns and of lines where are located cells. A Cell is a display object where to display a Type (Element or Object).
Free table:
The table is composed of Cell. The cells are freely located on a 3D gird, where x -> column, y -> row, z -> layer. The cell can have an extend of several column and row.
#
One problem I encountered several time in my professional life is about mass integration.
Typically Progiciel (firmware) do not address the problem in a right way, taking into account only the technical point of view.
This is the case on the following projet I was architect: Helios, with Oracle; RGCU, with Marklogic; GED Covéa, with FileNET.
The main problems are first:
– granularity : the integration completely succed or fail. In real world we want to manage partial success that is the most common situation. It is needed to work at the item grain.
– functionnality : the integration must take into account functionnal checks that determine if an item must be rejected or not (and why), or even, if the whole mass message must be rejected. It is needed to supports global failure and also local failure and warning.
This situation drives to many many custom developments.
In the existing IT world there is no global solution to that because any one can do and represents data as it want.
The situation drasticaly change in ISA because we rely an a common OO paradigm.
One way to solve the mass integration problem is to have an Integrator interface like that:
Integrate: Input: Context : Object, Items : Relationship; Output: Result.
The typical use is for instance:
Result My result : My Integrator integrate: Context: Batch of documents, Batch of documents documents.
Result having a set of Anomalies. An Anomaly having a set of Errors (either Business, Functionnal or Technical; with a Code and a Description) and also a Severity field. Where Severity is an Enumeration having the domain: Local warning, Local failure, Global failure.
Note that Integrator can be nested in another one.
Then by injecting an Integrator to a Software, it is possible be open to mass integration.
#
1 thread / core per object
As pointed in a previous comment, having one 1 thread or CPU core per Object if very efficient and solve many usual multiprocessing management problem because an Object work on its own set of data. This approach also open a wide progression field for hardware architecture by breaking the actual walls (limited number of powerful CPU and frequency roof).
However, if an Object have its own ALU and Register set, it also needs to access the memory to deal with its fields, relationships, strings (50% of the used types), etc. Then, the address bus become the bottleneck for all Objects.
To avoid that, a Core for Object must also its data and instructions near of it. Then the access to the address bus is limited to external memory access (large strings for instance), to Object swapping for the Core and to Operation calls.
This last access, Operation calls, can be segregated of the other access if it is implemented thru message passing (similar to Rust language do). Then a dedicated memory zone in the addressing space can be dedicated to message passing. A new bus (pair of bus?) is added to the processor: the messaging bus.
This messaging bus decrease the contention on the address/data buses.
Back to Core for Object.
A Core have a simple ALU, some basic registers (Instruction, Accumulators, Index, Status, …), an Object data memory and an Instruction cache. The Object data memory contains fields (80% of Object have less that 20 fields), Relationships (most Object have around 3), regular multi-sbyte Element instances (String for instance, but not Text that are typically wider).
Fields are typically sbyte wide -> Element or Reference: 20 sbytes
String are generaly less that 12 characters -> 3 sbyte x (50% of 20 fields) = 30 sbytes.
Relationships: say they have a cursor of 10 rooms and 3 fields = 3 x 13 sbyte = 39
1 sbyte for Object status.
An Object typically uses 90 sbytes
With an 1 kbyte memory per core, we have 128 available sbytes => Remain 38 sbytes for the instruction cache.
If an Object have many fields (>20), the dedicated memory of an other Core is reaffected to the current Core.
Well, 1kb per Core. Usualy an actual microprocessor have 2 Mb of Lx cache. Then, it is realistic to say that a processor with 2000 Core for Object is feasible. All of them running in parallel!
Remark:
The CPU can have an hardware implemented statistic feature to tell witch Core is the less used in order to optimize scheduling.
#
For communication beween 2 Objects that are running on 2 Cores of the same CPU, it is possible to shortcut the Messaging bus within the CPU.
This make this mechanisum, internal to CPU, outperforms from at least a magnitude the actual calls performed thru the thread stack that is done in memory.
Messaging bus that can be otherwise a bit slower that a call performed thru the thread stack because it works on the “heap” (even if the notion of heap here is different because it is the heap for the Messages).
#
Metamodel corections:
– Error exception have a Throw method overiding the Exception one to add log in the O.S. The base doesn’t log.
– Error is not a Codification, but has a Codification member. There is another class that list error codes: Error codification.
– Having operator that are Commands give a strange syntax => Modifiy to reserve Operators to Query and modifiy operator based commands to their verbs version.
#
LL
Microsoft Research Singularity Cf. The Singularity System. experience shows that having a bit field type to interact with hardware and in particular to developp device driver is important. It was underlined as one of the most important issue of this project.
#
This bit field feature is provided thru the ISA\LL\Elementary\Sbyte type.
#
LL
Consider adding a Type factory, in particular for Identifier for insatnce.
In LL ? In the O.S. ?
#
See the Function point number used in Software measurement cannot be assimilated to the notion of Feature of a Class. And therefore the number limitation will apply directly.
See https://en.wikiversity.org/wiki/Software_metrics_and_measurement#Function_Points
#
Invariant replace generjcity
Some invariant are LL expression the compiler understand.
Immutable: Make the unupdatable (techically 1 bit in the status 64 field of the object memory space).
Genericity: Name Type = A type.
All field, attribute, property or argument with this Name must be of type A type.
All classes are generic not only those prepared for that.
#
Genericity is static bh nature.
Add an Immutable to Élémentary.
Compiler try first to interprète LL: on this, as condition on this, as text.
#
Binary representation : String versus Sbytes
If the data are binary; as encrypted, zipped, images; the right format is Sbytes. The string representation is only to handle them in text editor without having strange characters displayed. This enforce using inefficient data representation like base 64.
Using the right type at the right place and also knowing the type (as it is allways the case in ISA) enforce the editor to distinguish 1/ text edition from 2/ binary edition.
So editor have to be powerful enough to handle that.
#
The binary edition can for instance be done thru a symbol having 8 zones to represents an octet: 1 for each bit. This is more understandable that base XX (2, 16, 64,…).
Bit set to 1 are filled while 0 are not.
The top most, left most zone is 8th bit and the bottom most right most zone the 1st bit.
Examples:
██
█▄
██
▄█
means 11101101
#
Historisable and Archivable are classes of the LL model that can be inherited statically or dynamically.
Archivable has a boolean property Archive (this object must be or is archived).
Historisable has a boolean property Current.
An truth table have to be done for impact of Historisable on relationships (with take into account navigability).
Also see comment below.
#
Return a value is done like in Basic function by affecting the name of the property, attribute or operation.
Example:
Archive:Archive : true.
.
For optional the ! punctuation give the default value.
Example:
Here with a Current field with multiplicity [0..1]
Current:Current (property) : Current (field) ! OS:Is current object version:this.
.
The ! pontuation marks the default value in case of missing value.
#
Dynamic inheritance
..Command..
Add classification(Added classification: Constructor call)
Remove classification(Removed classification: Abstract data type)
#
Document sharing
Document sharing with tools like SharePoint may be tricky in sharing in particular with synchronization thru tools like One Drive and Web Browser (Extraction, versioning, etc.).
In ISA, a Document being an Object that contains Objects and Elements, the sharing and synchronization follow the general OO policy (locking at each Object level , notificatrion, replication)
#
ISA is to computing what the ISO Model is to networking
#
Events
Event class :
The metaclass is a Classifier that is to Event what Class is to Object.
It inherits from Class because an Event is also an Object, but an Object having a Creation time stamp and being immutable by essence.
It may have specific features by inheritance.
It is composed of Event type.
By inheritance, Event class may provides event sub-typing.
Event type:
A metaclass that instanciate the metametaclass Nominal like the metaclass Nominal.
But that a) that is a component of an Event class; b) that have names in unlimited numbers; c) where names or in fact Event kind expressed thru a Key (because as possibly very numerous, humans need a human readable codification to handle complexity); d) an invariant enforce an Event of a given Event class to be of a kind contained in one of the linked Event types.
Errors are example of Event. Payment or Scan are also Events.
Event can be put in Message. But Message are not limited to send Event, they can also vehiculates Request/Response.
#
Is an Event an Object or not ?
Yes:
+ An Event can be used everywhere an Object can be
+ Everything (almost) is an Object
+ Event follows the 5 OO axioms, even if the state is fixed at construction
– An Event can occur on an Event
– Historization make no sens
– Dynamic inheritance make no sense
– Event is an unmutable Object by essence
– Event is a point in time, while Object are more durable
No:
+ Everything is a Type
– Everything (almost) is NOT an Object
Comparison with the real world: Are event objects ? No.
Because real world objects live in the 4D space, while events live in the 1D space of the time dimension.
Another linked difference is that object have a life cycle : creation, state change, dead.
An event at contrary have no life cycle it is created and since this time never changes is state nor died. It has occurred and nothing can change that, for ever. At most, we (externally) discard it if we don’t think the event is useful.
#
Event questins:
1/ What’s about Event Identity ?
2/ How to handle both close Event class / Kind like basic Errors
and open ones like custom Errors
#
The Object must be FREED
Objects are prisonner of Service, Database, DTO, Applications, Process, etc.
ISA MUST MAKE THE OBJECTS FREE
To break the walls driving to succedanée like Big Data architecture for instance.
We must ALWAYS interact with Object directly, or at worse by View on them.
#
Message processing and system manageability
One of the key point for the Unix vs Windows be considered stable is that it do not rely on Message processing but on Process treatment only.
It is important for ISA to be aware about that. This is particularly crucial because there is no Process and that Objects are exchanging extensively and intensively.
One solution will be to have a Message sas per Object of 1 room (1 Sbyte). This is pertinent because a very large majority of Objects will only have one Message at a time. In this case the Message processing is decentralized and do not request to the Operating System. If the sas is occupied, the O.S. is solicited to store the Message and deliver it. This central queuing can be managed by administrator, in particular policies may be defined to keep the System on good shape.
In case of undeliverability, an Exception is thrown to the caller for it to perform the appropriate things.
#
Event class instance must have a constructor with the associated Event kind instance property
#
Iterator, For each, For all, concurrency properties and methods.
A For each is supposed to call synchronously, in sequence, the items because the result of each call may alter the rest of the loop.
An Iterator is perfect here.
A For all is supposed to call in parallel all the items. The call in it self is made in the caller so in its thread so an Iterator is also pertinent.
The call here can result in synchronous access or asynchronous one. Asynchronous for methods, because they are supposed to be costly. Synchronous on Properties and Attribute read if there is no command in progress on the item. Asynchronous on Attribute set because it alter the state of the item.
#
Call polymorphism
The following code should accepted to avoid switch on the type.
In the Notify(Event: Event) command
Variable: My vent, Event class 1, Event class 2, Event class 3.
My event : Event.
Proceed event(My event).
With 3 overload for the Proceed event one for each class.
#
In “how to manage memoy” we have seen that Object are freed of the Process. Freing Objects from the Node (1 computer) is also a goal to reach.
This particulary apply to Use case objects for instance, because that will enable user to freely go to one to another node in continuating they use, this greatly increse the user experience.
View are also artefact to handle this free of Node target. Multi-master object distribution also.
This point have to be worked…
#
What are the axis to consider when trying to be Node aware/not aware ?
We have to classify the followings:
➡️ Mono Node (by essence),
➡️ Single Node (by choose),
➡️ Single master (with or without Replica – With or without transfers of the Master role to one Replica within a Group of Node this mode can be called shifting master),
➡️ Multi master (any master can be updated in the same period – also moreover possibly concurrently, with or without consolidation), other ?
#
The view on Assembly in the metamodel is a good idea but have to refined of how it is instanciated. Some examples will help.
For settings in particular, see also how to get settings set and updated locally, on a node, for a group, an organization, a deployment.
#
The integration problem – Software Bus (ESB)
A Mediator Assembly must be added to the Model. It plays the role of the Bus: Route and transform the Messages.
The Message Element have to be added in the Containment Assembly. It should support both local and distributed messaging.
#
Local message:
– Source: Caller object (address).
– Arguments: Set of Argument (metaclass).
– Target: Called Object (address) and Operation (name).
Remote message:
– Source: Caller object (Identifier) + Node (Identifier)
– Arguments: Set of Argument (metaclass) as initializer
– Target: To be determined.
– Properties: Set of Pair of free properties ? + Fixed properties ?
– Message identifier: SByte.
#
Assembly loading.
Have a look to OSGI loading capabilities , as Java package bundle: See “Organic thoughts” vladimirvivien.com/blogs/ot/
#
Also consider the OSGI bundle activator life cycle events to subscribe on.
#
Supports the Memento DP together with historiation to manage the Undo/Redo but also the Rollback, the Back button on Use Case.
And just by Configuration property on the Class/Use case.
#
Link character exists
🔗
https://unicode-table.com/fr/search/?q=1f517
#
The padding problem in business ids.
In company the employee number is on say 4 positions. But at a time, the number of employees exceed 1000, then the number of position is set to 6. Then what happens to an employe having the number 1234 ? It become “001234” or ” 1234″ or “1234 ” or remain just “1234” or any other possibilies.
This is of course a business decision. But often it is an IT problem to solve. So having a common rule for that could be a good thing in ISA.
My first thought : Never use padding. If you want to render a data with leading character, do that in the renderer and do not alter the data.
#
A Business ID (BID) is different in nature of a computing one in a sense that it may contains some semantic in order to facilitate its usage.
ATA 100 or business identification numbering systems are examples among many ones of that. At contrary, in particular in an OO world, a computing ID should not provide any semantic support. It is not rare that a BID have a fixed size.
That’s why the padding problem is only relevant for business IDs.
BID can be numeric or alphabetic or alphanumeric.
The event making the padding foreseeable can be :
• A business ID policy change (the BID may completely change following or not a transformation policy).
• An overflow of the capacity either by not enough rooms or because of collision (increase of the number of position to represents the BID Quid of existing BID).
• A generalization or a specialization change (adding ID characters on the left or on the right with or without a separator).
Rule:
If the rule change is important and asked by the business
=> If it is generalization or a specialization applicable only to new instances -> Add suffix or postfix using a separator (no padding).
=> Otherwise -> Make a migration and compute new BIDs (produce a mapping table object as the result of the migration).
Else it is just an overflow -> Keep the existing values having variable BID length (no padding).
#
Decision service is a good idea to externalize Business Rules (Rules Engine).
See how to handle that in ISA.
#
Access rights representation in memory
Access rights exists on each Object, so memory space is very important to manage
1) The access rights owned and required are limited to 32 per Object. A Sbyte represents this 2 rights allocation: 0 no have the right, 1 have the right.
Each bit is an index in a Rights Vector having 32 positions.
2) The Status Sbyte have 4 bits for Common Rights Vectors. So there is up to 15 Common Rights Vectors and 1 room for the case a Specific Rights Vector is needed.
In this last case, an additional Sbyte exists in the Object memory space pointing to this Specific Rights Vector.
Common Rights Vectors are for the rights set the most used by Objects.
3) To get more than 32 rights, the rights have to be organized hierarchically. Ex: a single right A gathers rights a, b and c.
#
Symetric cryptography : https://fr.wikipedia.org/wiki/Advanced_Encryption_Standard