Hierarchical business objects

Hierarchical business object definitions define the structure of multiple related entities, encapsulating not only each individual entity but also aspects of the relationship between entities. In addition to containing at least one simple attribute, a hierarchical business object has one or more attributes that are complex; that is, the attribute itself contains one or more business objects, called child business objects. The business object that contains the complex attribute is called the parent business object.

There are two types of relationships between parent and child business objects:

In turn, each child business object can contain attributes that contain a child business object or an array of business objects, and so on. The business object at the top of the hierarchy, which itself does not have a parent, is called the top-level business object. Any single business object, independent of its child business objects it might contain (or that might contain it) is called an individual business object.

In a typical business object hierarchy, a top-level business object definition contains one or more simple attributes, one or more attributes that represent a child or array of child business objects, and a list of supported verbs. Figure 7 shows a typical hierarchical business object. The top-level business object, Customer, has both single-cardinality attributes and multiple-cardinality attributes with child business objects:

In Figure 7, the Customer and CustProfile business objects, as well as each of the Address business objects is an individual business object.

Note:
When a top-level business object contains information used to process its child business objects, it is called a wrapper business object. For example, the XML connector requires a wrapper business object to contain information that determines the format of its child data business objects and routes the children.

When designing the structure of a hierarchical application-specific business object, you need to determine:

For more information, see Design considerations for multiple entities.

Copyright IBM Corp. 1997, 2003