Designing for event isolation

When designing a generic business object, it is recommended that you consider the needs of event isolation, as explained in the Collaboration Development Guide (in the section entitled "Designing for Parallel Execution").

To prevent more than one collaboration object from updating the same data at the same time, each business object should be modified by only one type of collaboration object. In other words, a Customer business object should be modified only by a CustomerSync collaboration object.

If a collaboration object modifies a business object that contains a child business object, and the child business object is also contained by a different top-level business object that has its own modifying collaboration object, design the top-level business objects to contain the child semantically rather than structurally. Develop a third collaboration object to modify the shared child. The collaboration objects that own the two top-level business objects should then delegate processing of the shared child to the third collaboration object.

For example, if both Customer and Contact business objects contain the same address data, design the Address business object as a top-level business object that is referenced by Customer and Contact, but not contained by them. Then develop a separate Address collaboration object to modify address data.

In another example, however, if the Order business object is the only business object that modifies OrderLineItem data, you can design Order to contain the OrderLineItem child business objects rather than merely reference them.

In other words, design the Customer and Contact business objects so that they contain a foreign-key attribute that references the Address business object, that is, that contains only the key value for Address. Do not design them to contain an attribute that represents a full-valued Address business object. But design the Order business object to contain an attribute that represents a full-valued OrderLineItem business object.

Note:
Designing shared business objects as referenced rather than contained can simplify business object distribution. If the same child business object is defined in multiple business object definitions, the repos_copy utility attempts to load the same business object twice during installation, causing rollback. For information on repos_copy flags that change this default behavior, see the System Administration Guide.

Copyright IBM Corp. 1997, 2004