Object nets and object trees
Contents
Summary
- v3 artefacts, when used in a messaging context, are object trees. When one persists these in a RIMBAA application all objects that share one and the same id are 'merged' into one single object. A stack of trees where objects interconnect based on their shared identity is an object net. Object nets have different characteristics than object trees, e.g. in areas such as context conduction, querying of object net subsets, and object versioning.
Related: Context Conduction in cyclic RIM graphs
Analysis
- In a real-world scenario one might assign more 'weight' to certain information from certain senders. Or to ignore 'demographics' sent by a Laboratory application. But then again: if the lab sends me stuff about a new patient (i.e. one unknown to me) it may be a best practice to import whatever demographics the lab is sending me. Or the receiver could decide to query the MPI for full details. But all of the above requires contextual knowledge (which senders are masters for what category of information) on the part of the object store.
- When it comes to the identity of objects: two objects can be identical (same identity), or equal (same value). See identity of objects for a detailed discussion; the identity of objects is a core issue when it comes to merging of object trees.
- See also these articles on the merging of object trees: [1]
example
Below an example of three different object trees. The rectangles represent object instances, the labels (A, B, etc.) the business identifiers of the objects. Some objects don't have an identifier. M1 is a directed graph, serialized using starting point B. M2 is serialized using F as its starting point, M3 using G.
Upon receipt of these three structures the receiver will 'merge' the information about one and the same object. Objects A, B and F appear in multiple object trees.
Note that the resulting object net is a directed graph, where links may be bidirectional in nature. Given the directed graphs (the object trees: M1, M2, M3) the object net, G links to B, and B links to F, but F doesn't link to B.
Merging based on known model constraints
Merging op object trees may use the fact that a known constraint can be used to identify (by means of their context) an otherwise unidentified object. See identity of objects for detailed discussion.
Below an example constraint model (CIM or LIM)
The image below shows two different object trees (m1, m2). If the receiver is somehow aware that both object trees comply with the constraint model shown above it has the ability to merge these object trees into the net1 object net. If the constraint isn't known the resulting object net would be net2. The 0..1 cardinality on the participation allows the receiver to deduce that the two non-identified objects in the two object trees are one and the same object.
So how does one know that (parts of) an object tree conform to a constraint model? The only way is to explicitly convey the Trigger Event (the ControlAct), the identity of the trigger event act, the time when the trigger event happened (to deal with temporal aspects of persisting objects) and the identifier of any constraint models applicable.
XXXX: an object tree may have multiple templates associated with it - open discussion item.
Snapshot Mode
Interactions are effectively a snapshot. An initial laboratory results message (labeled TE1 in the figure above) may be updated by a final laboratory results message (labeled TE2); where the contents (in terms of classes instantiated and attributes used) of the final message could be different from the contents of the initial message.
If both object trees are known to conform to one and the same R-MIM, the receiver should:
- Undo any merging that it did upon receipt of TE1
- This requires that one persists the fact that certain objects are associated with TE1. It also requires that one has a temporal database to revert to a prior version of objects/attributes.
- Merge the contents of TE2 with whatever objects the receiver already was aware about.
