Each Entity in a Vocabulary can be mapped to a Java Class or Java Interface. Java Classes may have one ancestor. Java Interfaces may have multiple ancestors. A Java Class may implement one or more Interfaces. Say a Java Class A inherits from Java Class B and implements Java Interfaces C & G. Say Java Interface C has as its ancestors Java Interfaces D & F. Say these Classes and Interfaces are mapped to Entities EA, EB, EC, ED, EF & EG in the Vocabulary. The relationships amongst the Java Classes shall be reflected in the Vocabulary using multiple inheritance. Entity EA shall have as its ancestors Entities EB, EC & EG. Entity EC shall have as its ancestors entities ED & EF as shown below:
Figure 289. How the Vocabulary Incorporates Inheritance from a Java Object Model
When a collection of Java objects are passed into the engine through the JOM API, the Java translator determines how to map them to the internal Entities using the following algorithm:
Naming conventions used in the graphic above:
DS = Decision Service
JO = Java Object in input collection
JC = Java Class for the JO and any of its direct or indirect ancestors
JI = Java Interfaces implemented directly or indirectly by JO
E = A Vocabulary Entity with no descendents found in DS context
AE = An Ancestor Entity (one with descendents) found in DS context
CDO = In memory Java Data Object created by Corticon for use in rule execution
For each E:
If there is a JO whose JC or JI is mapped to E then
Instantiate a CDO for E and link to JO
Put CDO in E bucket
Traverse E's inheritance hierarchy one level up
For each AE discovered in current level:
Put CDO in AE bucket
If E has another level of inheritance hierarchy, repeat last step
This design effectively attempts to instantiate the minimum number of CDOs possible and morphs them into playing multiple Entity roles. Ideally, no duplicate copies of input data exists in the engine's working memory thus avoid data synchronization issues.
DS = Decision Service