Benefits
- Partial Graph Sharing
- Thread-safe
- reusable objects are immutable (unless used for special
purposes)
- Full update history of all graphs
versions
- Safe Programming
- it eliminates need for defensive copies of arguments/results passed
to or returned from 3rd party modules
- Object class can be updated in runtime
- an object can be replaced by instance of more specific subclass
instance
- New design patterns
Areas of Use
- Integration
- suitable as interface (API) between modules and systems
- secure
- ThreadsOwn accelerator encourages design of a bytecode
verificator
- Parallel processing
- without need for synchronization
- immutable
- Shared representation of
- rules/schema/formulae/knowledge
- backtracking results
- other structures
- Optimization of N-dimensional state space
- Graph algorithms
Design of reusable composites, which have connectors (seeds). They may be
used multiple times independently at various parts of the graph.
Classic way - indirect references
This approach keeps object references in a separate table. Components refer
to each other indirectly using symbolic or non-symbolic ID keys.
Auto-generated IDs are used by collections of arbitrary number of components.
A reference table maps IDs to actual references and must be passed along
every method call. Drawbacks and options:
- separation of objects and their relations
- graph structure
- responsibility for graph reuse is shifted from objects and context
to reference table
- generally, the whole reference table must be copied on every
change
- object relations are dispersed accross
- objects which keep target ID and
- reference table
- global scope of reference table
- the same element can't be mirrored to various objects at different
parts of the graph
- limited possibilities of component reuse
- complicated API
- reference table is passed along method calls as an extra
parameter
- [reference, object table] pairs must be passed to
3rd party modules
- manipulation with pair [reference, object table] could be
wrapped the same way as Element wraps ElementShadowed and Context.
That involves another type of entity.
- deliberate combinations of objects and reference tables involve
- inconsistencies
- confusion
- indirect references - IDs - can be replaced by direct object references
- In given Context, an Element can be superseded by another Element.
Then the Context has [original, target] entry in an
identity-based table of mirrors. Otherwise the Element is not
mirrored, and it's used as it is. Therefore direct references can
replace indirect references. That even spares one layer of primary
[reference, object] mappings for objects which are unmirrored
in given Context.
Other ways
- relative references
- similar approach as using object table and symbolic or non-symbolic
IDs
- hierarchical composite/component structures are required, or are to
be fabricated
- whole addressing map must be copied on change
- or reusable hierarchical trees of addressing maps
- that allows to share lower parts of trees between several
contexts - versions
- changes to deep objects involve copy and update of whole higher
part of the tree - - domino effect on a smaller scale
- awkward programming API
- several entities - object, relative reference (path) and
context (addressing map or tree of maps)
- easily confusing
- difficult to integrate with 3rd party
modules
- Let's define absolute path as relative path an object can be
accessed from root - top - object. There must be exactly one
absolute path per object, otherwise its relative references to
ancestor/sibling objects would be ambiguous. It implies that
only tree object graphs are allowed.
- Every object culd have its "authoritative" absolute path,
against which its relative references to other objects are
resolved. But then relative references wouldn't need to be used
at all. They can be replaced by symbolic or non-symbolic IDs
explained earlier.
- integration with standard and 3rd party modules
involves same wrappers as in non-relative reference tables
- multiple processes
- modification of shared data involves copy-on-write
- only one version of object net can be accessed in a process
- context switching between processes is time-consuming
- processes consume system resources and their number is limited
- SQL transactions - commit/rollback
We haven't found any other implementated design that would
share substantial part of whichever component (values and relations) that is
same among arbitrary number of different recurrent graphs, where components
could be used as fully-fledged entities without any auxiliaries.
|
Copyright (c) 2005, 2006, 2007 Peter Kehl
|