Why Marks?

Consider the PIM, modeled without reference to distributed objects and remote accessibility, that we introduced in the previous chapter (see An Informal Example in Chapter 5). A default mapping rule that transforms all object-related source model elements into remotely accessible objects in the target model, just in case there's a need to access them remotely at some time, could yield an implementation that is unacceptably slow. It would instead be more efficient to make some accesses local and others remote.

Of course, there has to be some mechanism that indicates whether to apply the mapping rule that generates a remote access or the mapping rule that generates a local access. The mechanism we use is a mark. Like mapping functions, marks are not part of either the source model or the target model, though they can refer to elements of both models. This separation supports both model portability and longevity.

The separation also provides the ability to evaluate a number of different mapping possibilities without requiring modification of the PIM. This is critical for efficient deployment of enterprise systems, as it allows characteristics like distribution among processors and tasks to be varied while the effects are measured. In embedded systems' design, the same notion of varying characteristics can be applied to associating implementation technology with application models (for example, application elements with a particular task or processor).

An automated mapping could request marking information from the user at mapping time. (One can all too easily imagine an annoying animated paper clip that asks "You seem to be allocating objects. Would you like this access to be remote or local?") However, it's important to store the answer, and thus make it reusable for future applications of the same mapping function to the same source model. This saves the effort of repeatedly and redundantly capturing this additional input (and ridding yourself of that $#@% paper clip again).

Marks can also be derived directly from the source models. For example, we may count how many actions in the Customer class access its Accounts and store that count as a mark. If the count is zero, there's no need to maintain pointers from Customer to Account.