|
Author: Jens Moller
Many Corporate Directories have some application support in them. At some
point in time, the Corporate Directory becomes over-burdened by one or more
applications that access it frequently and require hefty resources to allow
it to perform reliably. When this occurs, the Corporate Directory and
Applications Directory diverge.
The problem is that each shares a subset of data that comes from common
sources, however, the applications Directory will own a large portion of
its data as it relates to the Application.
Its possible that the Application Directory may never have been a part
of the original Corporate Directory, and as such the common data will need
to be synched from some source, and represented in a common way. There is
also the likelyhood that the Directories are largely structured an
incompatable way that makes intersynching somewhat of a challenge.
Source of Record - Personnel Data
Since the Corporate Directory is designed to support management of personnel
information, including the status (active, terminated, on leave, etc.), it
should be the record of source for all other Directories that utilize
this same set of data for application purposes.
Depending on the Applications needs, its also quite possible that more than
one Corporate Directory might be supplying data to the Application Directory
Servers. An example of this mighyt be where the Application Server is
associated with a service that numerous organizations subscribe to. Each of
organizations manage their own Corporate Directory Data, and supply it based
the business rules of that organization.
Source of Record - Applications Data
Applications access is normally associated with the people or applications
that utilize any given application. While it
is possible to have a 'personal' set
of data that is mostly the same as the organizations Corporate Directory, it
is highly insecure to have multiply managed data sources for personnel data.
Many companies have at least a few instances of this
data floating around its network,
but once the business grows it may end up with hundreds of out of sync copies
of personnel data, wasting resources, and also requiring agreements with
various data sources that may not be any more reliable than just keeping the
track of the data yourself.
Therein lies one large problem - the application databases really want to
focus on the applications that they are designed for, but they need data from
the Corporate Directory. The solution is potentially quite simple - work
out an agreement with the Corporate Directory group and share data that each
needs.
Once an agreement exists (this will usually require that upper
management buys into the applications needs and that security is the
prime reason to share this information). This is
often the most complicated part to get agreement on.
Usually, there will not be that much data to return to the Corporate
Directory, however it will often want an application status value
returned to store so that it does not need to refer the applications directory
any more often than it has to.
The remaining data will originate as part of the default data sets of the
application as well as run time data that the application manages.
Application Directories Operations
These are typically optimised for a given set of functions. Unlike a
Corporate Directory Server, where the tree structure changes in a random
fashion over time, the Application Directory tends to have a very structured
Directory Information Tree (DIT). Directory access tends to be entirely
by the application and it can leverage the structure to find and utilize the
directory data more effectively. It may also see substantially more updates
than a Corporate Directory.
Application Directories should still be mostly read-only, as Directory
Servers are designed to operate in that mode.
Application Directories are often created independant of other data
sources, as a result, they often provide utilities and functions that
allow them to edit and manage personell type of data. This is fine until
they are synched with Corporate Directories. Once the record of source is
deligated to another service, Application Directories need to honor the
source of data, otherwise uncontrolled updates will damage the
consistancy between them.
The data found in an Application Directory Server entry will likely be
formatted in a a way that benifits the applications needs, and often is
not in any kind of format that is remarkably easy to look at and guess
what it means. Many instances utilize XML where possible as data elements,
allowing the information to be transformed as needed.
Comments? Questions? Contact Engineering
|
