Release 3 (8.1.7)
Part Number A83729-01
 Library |
 Product |
 Contents |
 Index |
| Oracle8i Integration Server Overview Release 3 (8.1.7) Part Number A83729-01 |
|
Oracle Message Broker (OMB) determines message routing information for point-to-point messaging by looking up the destination address in a Lightweight Data Access Protocol (LDAP) directory. OMB accesses the LDAP directory through a standard Java Naming and Directory Interface (JNDI) driver.
By storing message routing information in an LDAP, OMB provides two important benefits:
This chapter tells you all about directory services provided through the Oracle LDAP directory, Oracle Internet Directory (OID). It contains:
This section contains:
A directory service is a centralized, network-based repository that stores and provides access to information that must either be shared between applications or is highly distributed. Directory services play a vital role in developing intranet and Internet applications by helping you share information about users, systems, networks, services, and applications throughout the network.
Directory services have been used in a variety of forms for a number of years. For instance, e-mail systems include directories to store user information and to route messages between senders and receivers. Large corporations also use directories of various forms as repositories of employee information: centrally storing names, departments, managers, social security numbers, and other organizational information.
Although the evolution of directory services has been piecemeal in most companies, the value of directory services has increased sharply with the growth of Internet computing. Internet applications are by nature highly distributed and need an efficient mechanism to share information across a network.
For instance, consider an expense-reporting application that migrates from a client-server application to an Internet application. A few human resource professionals enter the expense reports for an entire company to an Internet self-service application on which each employee also enters his expense reports. The volume of users accessing the self-service Internet application is far greater than the volume who accessed the client-server system. As a result, the cost of managing Internet users becomes a much greater part of the total cost of administering the application.
Similarly, modern Internet applications are developed as modular Enterprise JavaBean or CORBA components, each of which is accessed by a particular name that identifies its location and its public interfaces. Each time a component is moved from one node in the network to another, it must provide a new name that all of its clients must be able to find. With many different components distributed across an intranet, the cost of administering these components becomes a significant part of the total cost of ownership of the system.
Finally, using an Internet architecture to develop applications simplifies how applications are deployed: they are no longer deployed on many client computers but are deployed on a few centralized, professionally managed servers. However, a number of new infrastructure components are required for Internet applications: ORBs, Web servers, Java Virtual Machines, databases, and application servers, to name just a few. The cost of administering these infrastructure components also must be managed.
All Internet applications have a common problem: how to centralize information in a single repository from which it can be efficiently accessed and shared by users or applications. The solution is Directory Services. You can use directory services to store and share a variety of different kinds of information.
For instance, a directory service can administer Internet, intranet, or extranet users who access OLTP applications and databases. Users are represented by their security certificates and their access control privileges, which can be stored centrally in a directory. An administrator then changes the user's information and privileges in a single location rather than making such changes in each of the applications and databases that the user accesses. Additionally, the directory service serves as a central repository to manage distributed network resources such as Net8 and IIOP listeners, dispatchers, and connection managers in an intranet environment.
Further, you can also use a directory service to store the names of CORBA and Enterprise JavaBean application components in a similar manner to storing Net8 names in a TNSNames file.
Directory services are, therefore, now recognized as a critical component of the management infrastructure required to lower the total cost of ownership of Internet applications. Directory services do this in two ways:
A directory service requires a robust, fast, and highly scalable data store for the information stored in it. As a result, these services are typically built on an enterprise database. A directory service is, therefore, essentially a specialized database with a hierarchical schema that can be easily extended to store a variety of different kinds of information.
Most directory services are accessed through the Lightweight Directory Access Protocol (LDAP), which defines an open, vendor-neutral, industry standard network protocol and set of access methods to a directory. LDAP has become the standard access method for directory information, much as the Domain Name System (DNS) is used for IP address look-up on almost any system on an intranet and on the Internet. LDAP is currently supported in most network operating systems, groupware, and even shrink-wrapped Internet applications.
LDAP evolved from the X.500 OSI directory service standard. X.500 incorporated many useful ideas, but was too heavyweight and complex to be useful for Internet applications. LDAP was designed to provide 90% of the functionality of the full X.500 specification at 10% of the cost. It radically simplifies the format in which messages are transported across the wire, representing data elements as simple strings, and leaving out many of the little-used but redundant operations in X.500. The efficiency of the LDAP on the wire and its aptness for Internet applications have catapulted it into the forefront of Internet directory services.
LDAP defines four basic information models that fully describe its operations, what type of information can be stored in LDAP directories, and what can be done with the information. These four models are:
Let us look at each of these in greater detail to understand how you use them in developing Internet applications.
The LDAP Information Model is centered around the concept of an entry. Entries are created in the directory to hold information about some object or concept in the real world (for example, a person, an organization, or a printer). Entries are composed of attributes that contain the information to be recorded about the object. Each attribute has a type and one or more values.
The type of an attribute has an associated syntax that defines what kind of information can be stored in the values of the attribute and how those values behave during searches and other directory operations. For example, the attribute cn (short for common name) has syntax called caseIgnoreString that implies three things:
Attribute types can also have various constraints associated with them, both limiting the number of values that can be stored in the attribute to one or many and limiting the size of those values. For example, an attribute to hold a person's identification number might be single-valued. An attribute to hold a photograph might be constrained to a size of no more than 10 KB to prevent unreasonable uses of storage space. The attributes required and permitted in an entry are controlled by content rules defined on a per-server basis, or by a special attribute in every entry called an objectclass. The values of this objectclass attribute identify the type of entry (person, organization, and so on) and determine which attributes are required and which are optional.
For example, the objectclass person requires the sn (for surname) and cn (for common name) attributes. This is the LDAP equivalent of the rules associated with a schema.
LDAP release 3 adds the ability to do away with schema enforcement altogether and add any attribute you choose to an entry. This is useful in environments where the overhead of adding new schema entries and making all the clients and servers aware of the new elements is prohibitive. To facilitate this, the LDAP release 3 protocol adds a special objectclass called extensibleObject. If the objectclass attribute of an entry contains the value extensibleObject, any other attribute is permitted in the entry regardless of the schema rules in place.
Though it is not a protocol requirement, LDAP directory entries are usually arranged in a hierarchical tree structure, for instance, following a geographical and organizational distribution. Entries are named according to their position in the hierarchy by a distinguished name (DN). Each component of the DN is called a relative distinguished name (RDN) and is composed of one or more attributes from the entry. To anyone familiar with a UNIX or a Windows file system, this concept is analogous to pathnames and filenames: the RDN is analogous to the name of a file and the DN to the absolute path name to the file. As with a file system, sibling entries (entries with the same parent) must have different RDNs. However, LDAP has two important differences from a file system:
filenames, LDAP components start with the least significant component (that component that names the entry itself) and proceed to the most significant (that component just below the root). In contrast, filenames usually start at the root and proceed down to a file or a directory. This difference is only syntactic and not semantic.
RDN components, separated by commas or semi-colons. Note that in contrast to filenames, LDAP name components are separated by commas and not by forward or backward slashes. For instance, a filename has the structure
/usr/local/ldap/include/ldap.h
but an LDAP entry has the structure
cn = Steve Harris, o=Software Industry, c=India
As shown, alias entries that point to other entries are permitted to circumvent the tree-like hierarchy. Further, note that a hierarchy is supported but is not required by LDAP. In many applications, the ability to organize and search information hierarchically is useful, however, in other cases, it may be inconvenient. The LDAP model can handle both cases because, in non-hierarchical case, you can use a one-level hierarchy as a flat namespace.
After you place information in an LDAP directory, LDAP defines nine different operations to authenticate clients so that they can access the directory, search the directory and retrieve information from it, and update information in the directory.
The search operation selects information from a defined area of an LDAP tree based on selection criteria. For each matching entry, a requested set of attributes (with or without values) can be returned. The searched entries can span a single entry, the immediate children of an entry, or the entire sub-tree of an entry. Alias entries can be followed automatically during a search and clients can specify the size and time limits of the search. LDAP release 3 directories also retrieve the results from a query in the form of a scrollable result set. That is, search results can be retrieved a page at a time, and clients can scroll up and scroll down to view the results they require.
LDAP Summary
LDAP provides three important facilities that makes it an ideal way to access Directory Services.
First, it provides a namespace that can be partitioned into a number of different naming contexts into which information in the directory can be organized. Each of these naming contexts can be hosted on a separate physical server node in order to provide clients with the perception of a single logical directory. This enables a directory service administrator to speed performance by placing frequently accessed information on a high performance server computer. For instance, in managing many different suppliers accessing a set of e-commerce applications, you may partition them into a set of namespaces based on the priority of the supplier: placing top priority suppliers in one namespace, next tier suppliers in a different namespace, and so on.
Additionally, since LDAP namespaces are physically separable, administrators can eliminate the risk of single points of failure by placing directory information in a mirrored CPU configuration.
Secondly, LDAP-based directory services organize information in a hierarchical pattern. This makes a directory service a natural way to represent hierarchical information, such as inventory lists for supply chain applications and price lists and catalogs for e-commerce applications. In the inventory example, for instance, each product is represented as a single product entry in the directory with child entries that represent the inventory levels for each subcomponent of the product itself.
Information in the directory service can itself be queried dynamically to find the root node of a naming context. You can access the child entries by sequentially navigating the hierarchy of the directory.
Finally, an LDAP directory service provides a number of stringent security mechanisms to protect the information stored in it. For instance, directory users must first authenticate themselves to the directory using either a username and password or an SSL/X.509 release 3 certificate (through a bind operation). Once the user has been authenticated, the information he can access is still further constrained by using an access control list.
Access control lists specify the users who can read information within the directory. Since entries in the directory are stored hierarchically, you can easily apply access controls to both individual entries and entry attributes, as well as to subtrees of entries. Further, access control applied to the product entry is automatically inherited by all the children. As a result, directory services enable you to control access to information in the directory in a detailed manner. This makes directory services ideal mechanisms to share information.
Oracle Corporation recommends that you use a directory service as a centralized administration facility to manage any information or facility that is distributed across the intranet, extranet, or the Internet. This includes users, application components, security, and business processes or workflow. We also recommend the use of a directory to manage information that is shared between applications within a corporate intranet and across an extranet.
Oracle Internet Directory is an application running on the Oracle8i database server that implements directory services. It is LDAP release 3 compliant.
Because it is based on the Oracle8i server, Oracle Internet Directory leverages the standard features of the database to offer unparalleled scalability in terms of size, performance, reliability, availability, and management by using:
Access to the LDAP server can be provided securely through the support of OID for Secure Socket Layers (SSL) release 3.
|
See Also:
Oracle Internet Directory Administrator's Guide for more information on Oracle Internet Directory and its capabilities |
|
 Copyright © 1996-2000, Oracle Corporation. All Rights Reserved. |
|