Applications may define their configuration in a set of configuration or “side” files. In these cases, administration of this information becomes the major administrative task of the application. Providing a command-line or graphical user interface (GUI) for this configuration information is a development expense and necessarily implies a separate set of interfaces, wizards, and management tools to support the configura- tion. When applications use a generic directory service to store their configuration information, the interfaces are defined and the administrative user interface can be consolidated into a larger, cross-product, consistent, distributed administration “con- sole.” While this can be done without using a generic directory service to hold the configuration, the implementation is simplified if updates to the directory are per- formed instead of requiring updates to remote configuration files. See Chapter 28 for a case study involving the use of a directory to manage the configuration of a Web farm.
As distributed middleware becomes more and more complex, a generic directory ser- vice can help ease the complexity by providing a centrally administered, widely acces- sible information source for configuration information. Applications such as IBM’s CICS, MQSeries, DB2, and Lotus Domino have large requirements on distributed administration.
Location
In most cases, applications that communicate with other applications must determine the network access addresses and protocols to be used to make the connection. These applications use directories to locate remote computers and software. An example of this is the Object Management Group (OMG) Name Service definition. The OMG Name Service provides a name to distributed object instance mapping that is used to build client-side proxy object instances through which the distributed object can be contacted and used. The OMG Name Service provides a directory of information pertaining to the distributed objects that are accessible by name in the directory name space. Another example of an application that uses a directory to locate and contact remote systems and services is the generic Web browser. Web browsers con- tact DNS servers to resolve host names to IP addresses so that information can be loaded into the browser from the remote location.
Users and Groups
It seems that for every application available in environments today there are user and group definitions stored and managed by the application. Electronic commerce web applications, single sign-on solutions, automated backup applications, and electronic mail and groupware applications, all define and exploit user and group information stored in directories. Administration of each of these directories usually brings with it a separate set of programmable and graphical interfaces. The definition of a user becomes scattered across a multitude of directories so that modifications, in some cases, must be performed multiple times, using each applications’ set of interfaces. A generic directory service can provide a single point of administration of this informa- tion. (See Figure 7.4.)
The the code in Code Example 7.4 shows how the directory in Figure 7.4 would be searched using the LDAP C client APIs.
Applications will begin to adopt a generic directory service for storing and retrieving information. Applications that store and retrieve their configuration information in a generic directory service can benefit from using a generic interface to access and update this information. Applications can use a generic directory service for retrieving
LDAP server
dn: ou=dusters, l=flintrock
dn: l=flintrock
dn: cn=applications, l=flintrock
HTTP server on sys1 HTTP server on sys2
Shared file system /home/httpd/pub
LDAP ldap_search:
baseDn: cn=httpd, cn=applications, l=flintrock filter: (objectclass=*) dn: cn=httpd, cn=applications, l=flintrock portNumber: 80 protectedPortNumber: 444 userRoot: l=flintrock fileRootDir: /home/httpd/pub ... portNumber: 80 protectedPortNumber: 444 userRoot: l=flintrock fileRootDir: /home/httpd/pub
sslCertDN: cn=Fred Flint, ou=flints, l=flintrock
remote server and application locations. Applications using a generic directory service for user and group definitions can benefit from a common user definition across mul- tiple applications. Ultimately this simplifies administration for users and groups and provides single sign-on to end users across multiple applications.
Summary
Individual users, computers, networks, and applications use directories. Each can benefit from storing and accessing information in a generic directory service instead of in various files and databases scattered across network-connected systems. Using a generic directory service can reduce or eliminate duplication of information across applications and can simplify administration and usage of multiple applications.
int rc = 0;
int TYPES_AND_VALUES = 0; LDAPMessage *res = NULL;
rc = ldap_search_s( ld, "cn=httpd, cn=applications, l=flintrock", LDAP_SCOPE_BASE,
"(objectclass=*)", NULL, TYPES_AND_VALUES, &res );
85
THE EVOLUTION
OF APPLICATION MODELS
“Dave, my mind is going! I can feel it! I can feel it!”
—2001: A SPACE ODYSSEY
pplication models and computers at the beginning of the new millennium have not quite evolved to the level of HAL in 2001: A Space Odyssey, although evolu- tion has occurred rapidly. Pioneer programmers were happy just to get a computer to do something interesting before it malfunctioned. The evolution of application mod- els followed the evolution of computers and operating systems. A directory service can enable better enterprise characteristics for appreciation models.