Impact analysis means finding dependencies between objects: which object depends on which other object, or vice-versa: if one object is modified or deleted, which other objects are affected? For example, if a web service interface changes, which callers must be adapted?

In JAXR, dependencies between objects are established via associations. There are a variety of pre-defined association types, and moreover a JAXR-based client can create its own association types. Although the names of the association types - for example HasChild or HasMember - suggest a certain semantic, JAXR itself does not imply any semantics with the association types. CentraSite supports the following conventions for associations.

If there is a dependency between two objects, each of which can exist on its own, then this dependency should be expressed by a Uses association. Example: one web service calls another web service. Remember that JAXR-based associations are directed: the association's source object should be the caller/user (in general, the object that depends on another object), and the association's target is the called/used object.

If there is an object C that cannot exist without another object P, then C should have a HasParent association to P. Example: A table object cannot exist without a database object, hence there is a HasParent association from each table to the corresponding database.

The reason for preferring HasParent over the “inverse” HasChild association is as follows: CentraSite tries to maintain referential integrity; this means, among other things, that is not possible to delete an object that is still the target of an association. Hence associations should be directed in such a way that an object cannot be deleted if someone else still depends on it: an object should not be deleted if it still has children, or if it is still in use by someone else.