The purpose of a business object is to transport data between components of a business integration system and the applications that it integrates. Therefore, the business object should model the data that needs to be transported. This data is usually associated with some entity in an application or technology that the business integration system integrates. The structure of a business object can be either of the following:
In addition, this section provides "Design considerations for multiple entities".
The simplest business object design is a flat business object that represents a single entity. All the attributes of a flat business object are simple (that is, each attribute represents a single value, such as a String or Integer or Date). For more information, see "Flat business objects".
In the case of an application-specific business object, a flat business object can represent a single entity in an application or in a technology standard. For example, assume an application has a database table that describes a record. Assume further that this table has five columns named ObjectID, UserName, TimeStamp, Detail, and Status (see Figure 8). The ObjectID is the primary key for each row, and its value is generated by the application. This table has no relationships to other tables.
Figure 8. Flat business object representing a single entity
As Figure 8 shows, the Record business object you design to represent the table might have five attributes, one for each column, with the key attribute corresponding to the ObjectID column.
Use of flat business objects can simplify corresponding connector design in the following ways:
This type of business object is straightforward in its design and in the connector logic required to process it. Typically, however, application entities are more complex and include information that is stored in other objects.
A business object can represent application entities that include data from
other entities in one of the ways shown in Table 3.
Table 3. Representing multiple entities.
Structure of business object | Type of data organization | Type of parent/child relationship |
---|---|---|
Parent business object can have one or more child business objects that represent the other entities. | One-to-one
One-to-many | Structural |
Parent business object can have one or more foreign-key attributes that reference other top-level business objects that represent the other entities. | One-to-one
One-to-many Many-to-many Many-to-one | Semantic |
If the application and its interface permit, a flat business object can include attributes that directly reference other entities. | One-to-one | None |
When deciding how to structure business objects that represent multiple entities, consider these guidelines:
The following sections describe each of these representations is described in more detail.
In a structural relationship, the parent business object physically contains the child business object. Such a business object is a hierarchical business object: at least one of its attributes is complex (that is, it contains either a child business object or an array of child business objects). The Relationship attribute property for this attribute is containment, to indicate a containment relationship. The type of this attribute is the type of the child business object (or objects) it represents. For more information, see "Hierarchical business objects".
The following hierarchical business objects represent structural relationships:
In both cases, because the parent business object contains the child or array of children, the relationship is defined structurally.
A structural relationship assumes that the parent business object owns the data within the child object. Thus, when a new employee is created, a new row is inserted into the address table to hold that employee's address. Similarly, when an employee is deleted, the employee's address is also deleted from the address table.
In a semantic relationship, either the parent business object references the child, or the child references the parent. When one business object references another, it stores a value that uniquely identifies the other, but it does not contain the other. In this case, the component that processes the business object derives the relationship semantically.
A semantic relationship is typically defined by a simple attribute that serves as a foreign key. The foreign key attribute is located in one business object and contains the unique identifier (called the primary key) of the other. In other words, both business objects have a primary key attribute that holds its unique identifier. In addition, one of the business objects also has a foreign key attribute that holds the primary key value of the other. The foreign key establishes the link semantically between parent and child.
Semantic relationships are important when there is a many-to-many or many-to-one relationship between entities, in other words, when more than one parent has a relationship to the same child. Relating the entities semantically rather than structurally isolates the child's data, which is important to maintain data consistency.
Because the parent does not contain the child in a semantically defined relationship, the connector that handles requests for the parent and child receives them in separate operations. In other words, the requests are sent separately to the connector, which handles the parent and child in separate operations. For more information, see "Data ownership in relationships" and "Choosing between a semantic and a structural relationship".
Consider the design options in Table 4 for specifying a semantic relationship.
Table 4. Design options for semantic relationships.
Design option | Type of relationship |
---|---|
Storing the foreign key in the parent object | One-to-one
Many-to-one |
Storing the foreign key in the child object | One-to-many |
Storing foreign keys in an array of child objects | One-to-many
Many-to-many |
Storing the foreign key in a business-object tree | One-to-one |
In the simplest use of foreign keys, the foreign key that establishes the relationship is stored in the parent. In this case, a parent can contain a reference to only one child of a given type. The relationship between parent and child is clearly defined in the parent. Therefore, this structure represents a one-to-one relationship. However, multiple parent business objects can reference the same child business object to implement a many-to-one relationship.
In Figure 9, the Customer business object has two attributes (AddressId and CustInfo) each of which contain a reference to a child business object. The foreign key attributes in Customer readily identify the parent's relationship to the two children.
Figure 9. One-to-one: Multiple foreign key attributes stored in the parent.
If your integration broker is InterChange Server, you can examine the delivered generic Order business object for an example of a parent object that stores a foreign key reference to another object. It contains the CustomerId attribute, which references the top-level generic Customer business object. See Figure 11 for an illustration of the Order business object.
Alternatively, the foreign key that establishes the relationship can be stored in the child. This case represents a one-to-many relationship; that is, multiple children can reference the same parent. However, because the relationship between parent and child is defined in the child, the relationship is invisible when you examine only the parent. Therefore, if the parent business object triggers an integration flow, those children cannot be retrieved--there is no reference to them in the parent business object that is traveling through the system.
In Figure 10, the foreign key attribute is stored in each child business object rather than in the parent. This structure allows multiple children to be semantically related to the same parent. In this case, however, because the parent business object has no attributes that contain a reference to a child business object, there is no way to identify the parent's relationship to its children or, given the parent, to retrieve all of its related children.
Figure 10. Many-to-one: Foreign key stored in multiple children.
To represent a one-to-many relationship, the foreign key that actually establishes the relationship is stored in a simple attribute in a child business object. The parent business object structurally contains an array of these children. In other words, the parent contains an array of child business objects, each one of which contains a foreign-key reference to another top-level business object. In addition, multiple parent business objects can reference the same child business object in their child business object arrays to implement a many-to-many relationship.
In Figure 11, the Order business object contains a reference to a single Customer business object and structurally contains an array of ContactRef business objects. Each ContactRef business object contains a reference to a single Contact business object.
Figure 11. Parent containing a child that stores foreign keys.
In this design, the foreign key that establishes the relationship is stored in a "child" business object whose parent is another business of the same type as itself. If your integration broker is InterChange Server, you can examine the generic InstalledProduct business object for an example of this design. This business object contains the ParentId attribute, which can contain a reference to another InstalledProduct business object, which is the direct parent of the current business object.
In Figure 12, the ParentId attribute of one InstalledProduct business object contains a reference to the primary key (ObjectId) attribute of its immediate parent InstalledProduct business object. The head of the hierarchy is the business object whose ParentId attribute does not contain a value.
Figure 12. Business object storing a foreign key to its parent of the same type.
Because an InstalledProduct business object can contain a reference to its parent business object, the business integration system can synchronize installed products that are part of a large hierarchy. The business integration system can manage the components of a complex installed product hierarchy as individual InstalledProduct business objects. If your integration broker is InterChange Server, you can see the InstalledProductSync collaboration template documentation for more information.
If the application interface provides the capability of joining multiple application entities in one business object, you may be able to define a flat business object that contains attributes referring to a primary entity and to related entities. If the relationship between the entities is a one-to-one relationship, where one instance of the primary entity can be associated with one instance of each related entity, attributes from multiple entities can be included in a single business object.
When designing an application-specific business object of this type, you may need to use application-specific information to specify the location of attribute data in the application so that the connector can find and process the data correctly.
Figure 13 provides an example of a flat WebSphere business integration system business object that represents data in two entities, one a table containing address data and the other a table containing lookup data for state/province and country abbreviations.
Figure 13. Flat business object that represents two entities.
This example uses application-specific information to establish a foreign key relationship between the entities. In this case, the connector performs a lookup from a value in an attribute that represents one table to provide a value for an attribute that represents another table. To retrieve this data, the connector performs two table reads.
Although flat business objects can encapsulate information from or included in multiple application entities, cross-application integration problems often require more complex integration logic and more complicated data structures than flat business objects can represent. To handle more complexity in application entities and integration requirements, the WebSphere business integration system provides hierarchical business objects.
This section provides the following considerations when you design business objects for multiple entities:
The way you design your business objects to represent multiple entities has an effect on the ownership of the data:
This distinction is significant when considering the data consistency of an entity that is shared by multiple business objects.
For example, assume that a customer and a contact share an address. If the Customer and Contact business objects contain a reference to the Address business object (a semantic relationship) instead of containing the business object (a structural relationship), changes to the Address can be made independently of changes to the Customer or Contact.
However, if the Customer and Contact business objects each contain the Address business object, changes to the Address made by Customer might overwrite changes made by Contact. In this case, two different collaboration objects (CustomerSync and ContactSync) might update the same address data at the same time, causing data inconsistency.
If Customer and Contact have a semantic rather than structural relationship to the Address business object, you can limit modification of Address data to a third interface. For instance, you might have one interface for each of the Contact and Customer business objects. Then both of those interfaces could delegate management of Address business objects to a third interface. If your integration broker is InterChange Server this is done by having the CustomerSync and ContactSync collaboration objects call AddressSync through a wrapper collaboration object rather than directly making the changes themselves. For more information on designing business objects to maintain data consistency for InterChange Server integration scenarios, see "Designing for Parallel Execution" in the Collaboration Development Guide.
Figure 14 illustrates the difference between semantically and structurally defining the relationship to a child business object.
Figure 14. Comparing semantic and structural relationships.
The figure above illustrates two kinds of relationships to child data:
As Table 3 shows, both the one-to-one and one-to-many relationships can be
represented by a structural or semantic relationship. Table 5 summarizes these structural and semantic
representations.
Table 5. Representations for one-to-one and one-to-many relationships
Figure 9 and Figure 10 illustrate business objects whose single- and multiple-cardinality relationships are defined semantically. The business objects in the example might represent data stored in a database. Relationships between business objects that represent such data can be defined both semantically and structurally. For such data, the relationship between a parent and child can be defined both semantically and structurally in the same two business objects.
To implement a semantic relationship, the underlying application should be able to support foreign keys. For example, when a business object represents database data, it can establish the relationship between entities both semantically and structurally. Such business objects are designed redundantly. In other words, the component that processes them can locate the child through the parent and the parent through each child.
For example, assume an application has a table that represents purchase orders. This table is related by foreign keys to a table that contains line items for a purchase order. Multiple rows in the line items table reference a single row in the purchase orders table. Figure 15 illustrates these tables.
Figure 15. Example application tables with a one-to-many semantic relationship.
Figure 16 illustrates business objects that might correspond to these tables. This figure shows a top-level PurchaseOrder business object and three child LineItem business objects.
Figure 16. Sample business objects with multiple-cardinality semantic and structural relationship.
The illustrated PurchaseOrder business object has both a semantic and structural relationship to its LineItem children. The PurchaseOrderId attribute in each child creates the foreign-key semantic link to the parent from the child. The LineItem attribute in the parent, which is defined with cardinality n, creates the structural link to the child from the parent.
If the underlying application does not support foreign keys, you probably need to implement a structural relationship. For example, a DTD, which represents a single XML document does not support foreign-key information. Therefore, any one-to-one or one-to-many relationships must be defined structurally. The following Order DTD, which contains elements that correspond to an application Order entity, illustrates single- and multiple-cardinality relationships:
<!--Order --> <!-- Element Declarations --> <!ELEMENT Order (Unit+)> <!ELEMENT Unit (PartNumber?, Quantity, Price, Accessory*)> <!ELEMENT PartNumber (#PCDATA)> <!ELEMENT Quantity (#PCDATA)> <!ELEMENT Price (#PCDATA)> <!ELEMENT Accessory (Quantity, Type)> <!ATTLIST Accessory Name CDATA > <!ELEMENT Type (#PCDATA)>
Figure 17 illustrates a business object that represents the Order DTD. The top-level business object contains the Order business object with a single-cardinality relationship, and Order contains the child Unit business objects with a multiple-cardinality relationship. In turn, Unit contains the Accessory business objects with a multiple-cardinality relationship.
Figure 17. Single- and multiple-cardinality structural relationships.
The relationship of business objects illustrated in Figure 17 is defined structurally; that is, each parent business object contains an attribute whose type is the same as the child's and whose relationship is specified as containment.