Definition: One concept inherits all the properties of another concept, similar to Java, where a subclass inherits all the properties of the superclass that it extends. You can define a hierarchy of inheritance, where each concept in the hierarchy extends the concept above it.Concepts that are related to each other directly or indirectly by inheritance cannot have distinct properties that share a common name. Therefore, the following restrictions apply:
• If two concepts are related by inheritance, you cannot create a new property in one with a name that already exists in the other.
• If two unrelated concepts have properties that share a name, you cannot create an inheritance relationship between the two concepts.Also, TIBCO BusinessEvents does not allow you to create an inheritance loop; for example, if Concept A inherits from Concept B, Concept B cannot inherit from Concept A.At runtime, a rule on a parent concept also affects all its child concepts. For example, suppose the concept Coupe inherits from the concept Car. A rule on Car is therefore also a rule on Coupe.Definition: One concept is contained inside another concept. You can define a hierarchy of containment, where each concept in the hierarchy is contained by the concept above it.The relationship is defined using a ContainedConcept property in the container concept.
When working with container and contained concepts in the rule editor, the XSLT mapper and XPath builder show the entire hierarchy of properties.In the rule editor, you can also use the @parent attribute to get the parent of a contained concept instance.Deep containment relationships can also cause memory issues. When TIBCO BusinessEvents retrieves a concept from cache, its child concepts are also retrieved. When you modify a child concept, its parent concepts are considered to be modified. It is recommended that you keep concept relationships shallow. See Table 3, Containment and Reference Concept Relationship Rules for these and other rules governing the behavior of concepts linked by containment, and also reference. The table can also help you to choose which is the appropriate type of relationship for your needs.The following example illustrates some of the rules that are listed in Table 3. To configure a concept Car to contain a concept Wheel, you add a ContainedConcept property, Wheels for example, whose value is an instance of the concept Wheel. The Wheels property provides the link between the container and contained concept:The concept Car contains four instances of the contained concept Wheel, so you define the property as an array.The concept Car could also contain other concepts, such as Door and Engine, defined in a similar way using ContainedConcept properties.However, the contained concepts — Wheel, Door, and Engine — cannot be contained by any other concept type. They can only be contained by the Car concept. For example, the concept Wheel cannot be contained in the concept Motorbike, if it is already contained by the concept Car.
A container concept can link to a contained concept using only one ContainedConcept property. You can use inheritance, however, to achieve a result similar to that gained by the general programming technique of linking to multiple contained class properties. Suppose you extend the concept Wheel by creating child concepts CarWheel and MotorcycleWheel. You can then use CarWheel as the concept contained by Car, and MotorcycleWheel as the concept contained by Motorcycle. Rules that apply to Wheel also apply to CarWheel and MotorcycleWheel, because of inheritance.Depending on your needs, another option would be to use a reference relationship instead of a containment or inheritance relationship.Definition: One concept instance references another concept instance. A concept that is the target of a reference can itself refer to one or more other concepts. Reference relationships are not, however, hierarchical.The relationship is defined by a ConceptReference property in the referring concept.See Table 3, Containment and Reference Concept Relationship Rules for rules governing the behavior of concepts linked by containment or reference. The table also helps you to choose which is the appropriate type of relationship for your needs.
To configure a concept Order to reference a concept SalesRep, you add a ConceptReference property, Rep for example, whose value is the ID of concept SalesRep. The Rep property provides the link between the referring and referenced concepts:A concept definition can have a reference relationship to itself. This is generally because the instances of one concept definition can have reference relationships to other instances of the same definition. For example:
•
•
• Table 3 presents the rules governing designtime and runtime use of containment and reference relationships. By comparing the rules, you can decide which type of relationship to use an a particular case.
One container concept can contain multiple different contained concepts, and a contained concept can itself also act as a container concept.One referring concept (that is, the concept that has the ConceptReference property) can have a reference relationship with multiple referenced concepts, and a referenced concept can also refer to other concepts. A container concept can link to a contained concept using only one ContainedConcept property. (Some other object oriented languages do allow you to reuse object types in parent object properties.) A referring concept links to a referenced concept using multiple ConceptReference properties. (That is, multiple ConceptReference properties can reference the same referenced concept.) A contained concept can have only one container concept. A referenced concept can be referred to by multiple referring concepts When one contained instance is replaced with another, TIBCO BusinessEvents automatically deletes the instance that it replaced. You do not have to delete the replaced instance explicitly. When one referenced instance is replaced with another, TIBCO BusinessEvents does not delete the instance that it replaced automatically. It may not be appropriate to delete the referenced instance. If you want to delete the referenced instance, do so explicitly. When a contained instance is modified, the container instance is also considered to be modified. The reasoning can be seen by a simple example: a change to the wheel of a car is also a change to the car. Rules that test for modified instances would return the Car concept instance as well as the Wheel concept instance. When a referenced instance is modified, the referring instance is not considered to be modified. The reasoning can be seen by a simple example: a change to the support contract for a customer is not a change to an order that references that customer. When a container instance is asserted or deleted, the contained instance is also asserted or deleted, along with any other contained instances at lower levels of the containment hierarchy. When a referring instance is asserted or deleted, the referenced instance is not also asserted or deleted.This section highlights an important difference in behavior when history is tracked for an array property, and when history is not tracked, or the property is not an array.
(ContainedConcept or ConceptReference Property) Multiple-value property (array), with History is set to 0 or 1 (that is, historical values are not tracked). The array entry that held the deleted concept is removed, reducing the array size by one. Multiple-value property (array), whose History is set to 2 or more (that is, historical values are tracked). The array entry that held the deleted concept remains and its value is set to null, so that history can be tracked.
Copyright © TIBCO Software Inc. All Rights Reserved.