The Domain Hierarchy and Domain Plug-ins

At each step in data life-cycle, knowledge of a value's domain is required to ensure that the correct processing is performed. Embedding this domain information in the application is one of the tasks performed by the application code generators. With this information available, the application can invoke data conversion and comparison operations tailored for each domain.

Not only is information about each domain available at run-time, information about the relationships between these domains is also available. A model of the domain hierarchy is maintained in memory using tree structures and all the necessary information about how values in the domains should be processed "hangs" from these trees.

The domain hierarchy is composed of nodes implementing the curam.util.common.domain.Domain interface. The main methods declared in this interface are listed below. For more information see the Cúram JavaDoc documentation for this interface.

• getName()

  This method is used to get the name of this domain.

• getParent()

  This method is used to get the parent domain of this domain if it exists.

• getRootDomain()

  This method is used to get the ultimate root domain of this domain.

• getChildren()

  This method is used to get the list of children of this domain.

• getPlugIn()

  This method is used to get the named plug-in object associated with this domain.

For the purposes of writing custom data conversion and comparison operations, this interface is rarely used directly, but it is instructive of the mechanism by which custom code is integrated into an application.

Each domain has a unique name: the name defined for it in the UML model. As domains can be derived from other domains, parent-children relationships exist, and these are also represented. Also, the root domain (the ultimate ancestor of any domain) is readily accessible. A root domain is one that does not have a parent domain. Several root domains (for dates, strings, integers, etc.) are supported in the Cúram application, so the domain hierarchy is represented by a "forest" of separate trees, rather than a single tree. All information about a domain, other than its name and relationships to other domains, is provided via domain plug-ins.

As described in the list above, the curam.util.common.domain.Domain interface also describes a method for the retrieval of plug-ins, getPlugIn, that takes the name of the type of plug-in required. The method returns the plug-in configured for the domain or the equivalent plug-in configured for the nearest ancestor domain if none has been configured directly; this is the simple inheritance mechanism. Domain plug-ins are Java classes that implement the data conversion and comparison operations and other features that are specific to each domain. There are four supported plug-in types, each with a unique plug-in name:

"converter"

Converter plug-ins are responsible for implementing the format, pre-parse, parse, pre-validate, and validate operations for each domain. Converter plug-ins can be customized to influence the appearance of values on an application page, to support the parsing of new data formats, and to prevent the submission of invalid data.

"comparator"

Comparator plug-ins are responsible for implementing the compare operation for each domain. Comparator plug-ins can be customized to influence the sorting of data.

"default"

Default plug-ins are responsible for providing default values for each domain when no value is available. While this type of plug-in can be customized freely, there will rarely be any need to modify the implementations provided within the Cúram application.

"options"

Options plug-ins are responsible for providing access to the domain definition options that were defined in the UML model. This type of plug-in is built into the client infrastructure and cannot be customized.

The mechanism used to configure the domain plug-ins exploits the domain hierarchy to simplify the configuration dramatically: very few domains need to be configured, as domains that are not configured will inherit the configuration from their ancestor domains. Each root domain needs to be configured (so that every domain has an ancestor from which it can inherit its configuration), and a small number of specialized sub-domains are also configured further (the most notable being CODETABLE_CODE, a derivative of the root domain SVR_STRING). In all, less than 1% of domains are directly configured, so the configuration information is very manageable. The Cúram application comes complete with plug-in implementations and configuration information for all the domains used by the reference application; modifications are only required to handle specialized custom extensions.