Skip to end of metadata
Go to start of metadata

You are viewing an old version of this page. View the current version.

Compare with Current View Page History

« Previous Version 2 Next »

Page Audience: SMW unit, during development of this page.  Published to partners and customers when ready.
Page Purpose: Describe an important design pattern for middleware services.
Document Status: Early draft


Institutionally there are many kinds of entities that we wish to identify, describe, manage, and share among multiple business functions and application systems: people, groups, departments, roles, classes, budgets, computers, services, programs, functions, etc. Proper management of information about these entities allows this information to be easily shared among all systems. A registry is a design pattern describing key aspects of managing this kind of information.

Registry Defined 

A registry keeps track of all instances of a particular kind of thing.

Appropriate "kinds of thing" are those which have:

  • unique instances; 
  • a common set of attributes among instances, including identifying attributes that reliably distinguish one from another;
  • enough instances to make it worth keeping track of them, eg more than 100;
  • instances that are created and updated on a regular basis (typically several times daily);
  • multiple application systems (subscribers) that need to access their info. 

An entry in a registry has:

  • identifying attributes (identifer(s) and/or name(s));
  • management attributes, including
    • created/updated-by, create/update-date
    • manager(s) (aka owner(s))
    • other access control info;
  • attributes related to the organizational function of the entry.

The functional attributes are those that are most likely to be shared among multiple systems. An application system will typically maintain information about registered entities that is specific to that system, and remains internal to that system.

A registry provides guarantees about accuracy, completeness, timeliness, and accessibility of its records, appropriate to the needs of its subscribers. Those with registry update capability (maintainers) must all agree to abide by conditions necessary to maintain the service guarantees of the registry.

A registry may be maintained (ie, entries created/updated/deleted) via a single business process or application system, or via multiple processes/systems. Supporting multiple maintenance processes raises several design issues, including whether to extend one process to support all others or creating a new one; reconciling conflicting attributes; etc.

A registry has business logic for maintaining quality of entries.

Examples of institutional registries include:

  • persons;
  • network names and addresses (i.e., DNS names and IP addresses);
  • organizational units;
  • groups;
  • accounts/user-ids;
  • budgets.

Some architectural assumptions:

  • Few updaters, more readers
  • Relevant to some organizational scope, eg dept person reg may feed univ PR or reverse

University Person Registry

The goal of this system is to provide a single shared source of data about all people of interest to the institution, that is accurate, complete, up-to-date, and accessible. It is a registry as described above, and will be maintained via multiple processes.

  • No labels