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
    • thread-safe
    • 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.

SourceForge.net Logo Copyright (c) 2005, 2006, 2007 Peter Kehl