IDM This Old Web 
* [ Home | eXchange | F A Q | Find | comment? ] Technology & Techniques for Webmasters 
 
 
Team of skydivers CORBA as an LDAP Server Datastore
An architecture for intranet directory services

by Ted Burghart, QUOIN, Inc.

The Lightweight Directory Access Protocol (LDAP) is a standard maintained by the Internet Engineering Task Force (IETF) for remote access to centralized directories. Due to its features and ease of implementation it has gained rapid and broad acceptance. (See IDM's Foundation Series for an LDAP primer.)

The Common Object Request Broker Architecture (CORBA) is a standard maintained by the Object Management Group (OMG) for the distribution of objects across heterogeneous networks. Designed as a platform-neutral infrastructure for inter-object communication, it has gained widespread acceptance.

Both of these standards are targeted at networks communicating via TCP/IP [1], the predominant protocol used by the Internet and an increasing number of local- and wide-area networks.

Because of the acceptance of LDAP as a directory service and CORBA as an object distribution mechanism, using CORBA objects directly as a backend datastore for an LDAP server may be attractive to a growing number of organizations. For example, many electronic mail clients support LDAP directories for use as address books, while many organizations have deployed or are developing CORBA based servers for this same type of information. Integrating the CORBA object framework into an LDAP server provides access to this directory information from within off-the-shelf email packages without need of additional tools.

These two standards have several architectural attributes that make them a good fit with one another. First, both are object-oriented; this common approach helps their data models work together. Second, LDAP provides an asynchronous search and retrieval model with client adjustable limits that meshes well with the opaque nature of CORBA object distribution.

1 Transmission Control Protocol/Internet Protocol, IETF STD 7 (RFC 793) & IETF STD 5 (RFC 791)

The LDAP Model

LDAP initially grew out of earlier work [2] on lightweight X.500 [3] access protocols. One of LDAP's goals was to provide 90% of the functionality of the heavyweight X.500 protocol at 10% of the processing cost. This was accomplished through simplifications such as running directly over TCP/IP and removing little used and redundant operations. The lightweight nature of LDAP spurred development of clients for the protocol, but servers were still complex as they had to interface to X.500.

The next logical step was to remove X.500 from the picture altogether and create standalone LDAP servers that were able to manage their directories (i.e. data) themselves. This change reduced the resources required to implement the service. This last step has moved LDAP into the prominent position it holds today.

Although LDAP version 3 [Wahl, et al 97A] has just become a Draft Internet Standard, LDAP version 2 [Yeong, et al 95] will remain the most widely implemented version for some time to come. LDAPv3 contains all of the elements of LDAPv2, so v2 implementations will remain valid indefinitely.

LDAP objects are actually nothing more than named collections of named attributes, each of which has associated with it a data type and one or more values. An object is named by it's dn attribute, or Distinguished Name. The naming convention for the objects supports a hierarchical relationship between objects, though there is no requirement to use such an organization. Each object has an objectclass attribute which identifies its structure within the server's object schema, where required and optional data attributes are defined. LDAP itself makes no assumptions about the storage mechanism used to provide object persistence, if any. Figure 1 provides a simple example of an LDAP entry. 

dn: cn=Barbara J Jensen, o=Ace Industries, c=US
cn: Barbara Jensen
cn: Babs Jensen
sn: Jensen
objectclass: person
Figure 1. A typical LDAP entry.

In this entry only the basic text fields for a person object are defined. Some fields, such as dn (distinguished name) and sn (surname), can only have a single value associated with them, while other fields, such as cn (common name) and objectclass, can have multiple values.

LDAP provides for runtime configuration of the object schema. In practice, this configuration is likely to be fairly static, but the architecture allows the schema to be changed without necessarily having to change any code. Although not supported in LDAPv2, LDAPv3 includes a schema discovery mechanism, whereby the client can query the server to determine the objects and attributes supported. LDAPv3 also includes a special objectclass extensibleObject [Wahl, et al 97B] which can contain any attributes, allowing runtime definition by the client of objects to be stored by the server.

Fig. 2 - LDAP Client/Server Interaction

Figure 2. LDAP Client/Server Interaction.

LDAP objects are retrieved from the server based on their attributes as specified in a client search operation. The protocol does not specify how these searches are conducted, instead it provides a flexible mechanism whereby objects meeting the search criteria are returned one at a time to the client until one of the following occurs:

  • The server determines that it has no more objects to return
  • One of the search constraints set by the client is reached
  • Return no more than n objects
  • Spend no more than n seconds conducting the search
  • The client issues an abort request

2 DIXIE Protocol Specification, IETF RFC 1249 & Directory Assistance Service (DAS), IETF RFC 1202

3 X.500 is the Open Systems Interconnection (OSI) Directory Standard defined by ISO and ITU

The CORBA Model

The OMG is a consortium of more than 700 companies formed to create a standard architecture for distributed object computing. The goal of the OMG's members [4] was to combine object and distributed systems technologies into an interoperability architecture that supported integration of existing and future computing platforms. The result of that effort is the Object Management Architecture (OMA); CORBA specifies the Object Request Broker (ORB) underlying the OMA. The ORB provides the base architecture [OMG 97A] as well as a number of services [OMG 97B] such as security, transactions and messaging.

CORBA allows applications to use a common interface, defined in Interface Definition Language (IDL), across multiple platforms and development tools. IDL is designed to be platform- and language-neutral; data and call format conversions are handled transparently by the ORB. All interfaces to CORBA objects, and the data types used in those interfaces, are specified in IDL. This common definition allows applications to operate on objects without concern for the manner in which the object is implemented.

As viewed by the client, a CORBA object is entirely opaque, in that the object's implementation and location are unknown to the application using it. Generally, a CORBA client will know only how to find or create the objects it needs through interfaces to well known objects such as query mechanisms and factories. It is likely that the client will not know where or how even these well known objects are implemented, but will instead be able to locate them by name only through the CORBA Naming Service [OMG 97B]. This implementation hiding, while one of the CORBA model's strengths, also makes it very difficult for the client to be able to determine what performance it can expect from any given object or its server.

Fig. 3 - The CORBA Architecture

Figure 3. The CORBA Architecture.

In the case of any of these CORBA objects the client knows only what the object's public interface is and can therefore access the object's functionality. CORBA also provides some capabilities for runtime object interface identification and invocation through its Interface Repository (IR) and Dynamic Invocation Interface (DII). While these have the potential to allow (almost) complete runtime configuration of access to CORBA objects, in practice there may be very few cases where such capabilities are actually workable due to semantic issues.

Figure 4 shows an OMG IDL interface for person. This interface uses the same semantics (i.e. the same object model) as the LDAP example in Figure 1. 


   interface Person
   {
      attribute sequence<string> common_names; // collection of names
      attribute string surname;                // one last name
      attribute Organization organization;     // an organization
   };

Figure 4. CORBA interface to a simple person object.

4 Microsoft participates, but does not submit technology to the OMG. Instead, Microsoft promotes its own Windows-centric Distributed Component Object Model (DCOM)

Why CORBA makes a good LDAP server datastore

Limit server overhead

  • LDAP's asynchronous retrieval model is ideal for searching and retrieving CORBA distributed objects. Because the results of the search are returned to the client as they are identified, no demands are placed upon the server to return summary information prior to completion of the search. In fact, the server is never obligated to determine the total number of objects satisfying the search criteria, although upon successful completion of a search it does provide the number of objects returned to the client.

    • Client retains execution control

  • Because the client can submit a search and go back to doing other work, constrain the number of objects it wants returned and the amount of time to be spent on the search, and has the capability to asynchronously abort the search, it can safely attempt any search without surrendering execution control for an indeterminate time.
  • Since the server is freed from the expectations of synchronous operations, it can search across any datastore(s) which it deems appropriate regardless of their response times. The opacity of this arrangement is perfectly suited to the opaque nature of CORBA object distribution.

    • Compatible object models

  • CORBA and LDAP provide compatible well-defined data types such as numbers, character strings and binary objects. As such, data elements used and returned by operations invoked on objects can be easily and reliably mapped between the two models by the LDAP server. The server can also map LDAP search syntax to whatever is required to invoke a search on its CORBA datastore and use whatever method the datastore provides for retrieval of the search results.

    Since the server is under no obligation with regard to how the results are returned, at least as far as a monolithic versus an iterative result set are concerned, it can adapt to the datastore's retrieval model transparently to the client.

    •      Compatible security services

  • These two protocols also provide compatible and highly granular security services. Security policies can be administered and enforced from a system-wide perspective down to the per-operation/per-object level.

    • While the LDAP data model is highly flexible and extensible, in most cases LDAP servers will be used simply to provide access to 'white pages' information, such as corporate directories. Here, CORBA may be of particular value as the OMG is currently in the process of defining a facility representing a common functional model for person and organization objects, among others [OMG 97C]. QUOIN is actively involved in this effort.

    Implementing CORBA as an LDAP server datastore

    Translating between CORBA objects and LDAP objects is fairly straightforward and should not be difficult for implementors familiar with streaming protocols. Generally it would be expected that a given CORBA object implements one or more LDAP object classes and that the CORBA objects' attributes can be statically mapped to the attributes defined for the LDAP object(s).

    Note: While there may be some applicability of CORBA's IR and DII capabilities to this discussion, we will assume that all of the objects' interfaces are known to the LDAP server and that any extensible objects will simply be instances of a common object capable of holding the attributes of any LDAP object.

    The first general purpose implementation of LDAP servers and tools was released by the University of Michigan. Since then, several vendors have released or announced commercial LDAP servers 5 both for general use and for access to system-specific data, with many more on the way. These commercial implementations, however, do not provide a means for building a customized server to access a specific datastore.

    The most commonly used base for a standalone LDAP server is the University of Michigan's SLAPD, contained in the UMich LDAP distribution. This publicly available distribution contains C-language source code for the server and many tools, as well as the LDAP client API 6. SLAPD has several strengths and weaknesses in general and when coupled with CORBA. We'll touch briefly on two of them here.

    SLAPD is designed to allow multiple backend datastores

  • One of the greatest strengths of this server is its design around modular, pluggable backend datastores. The model allows definition of a datastore to be supported in the server configuration files and implemented essentially as an object, albeit in a non object-oriented language. This structure allows backends to operate as opaque objects without any knowledge of each other and allows the server to use multiple backends to support disparate datastores.

    • SLAPD doesn't support real object-oriented backend implementations well

  • Although the server is designed to support multiple backends, it's internal structures are optimized for data storage and retrieval via the included DBM 7-like database backend. Because of this and the server's C source code base, it can be difficult to integrate a true object-oriented backend. Some features, such as exceptions, can be used only by making sure they are in no way exposed to the C code base which doesn't understand them. Others, such as constructor/destructor semantics, can't easily be applied to the C data structures used by the server. Overall the interface between the procedural server and the object-oriented backend can be difficult to manage.

    • Ideally, in order to provide a truly flexible server, it should be written completely in an object-oriented language, with C++ being the strongest contender. Properly done, this would make integrating CORBA and other object-oriented backends much easier while providing improved error handling and greater manageability.

    5 Hewlett Packard, IBM, Microsoft, Netscape, Novell, Sun and many others.

    6 LDAP Application Programming Interface, IETF RFC 1823, currently under revision.

    7 The UNIX DataBase Manager interface.

    Conclusion

    LDAP is very well suited to the role of a gateway between directory clients and distributed objects. Combining it with CORBA provides a secure means for standard off-the-shelf applications to transparently access data in system-specific object schemas at a relatively low cost.

    Bibliography

    [Yeong, et al 95]
    W. Yeong, T. Howes, S. Kille; "Lightweight Directory Access Protocol", RFC 1777 (Performance Systems International, University of Michigan, ISODE Consortium, March 1995)

    [Howes, et al 95]
    T. Howes, S. Kille, W. Yeong, C. Robbins; "The String Representation of Standard Attribute Syntaxes", RFC 1778 (University of Michigan, ISODE Consortium, Performance Systems International, NeXor Ltd., March 1995)

    [Kille 95]
    S. Kille; "A String Representation of Distinguished Names", RFC 1779 (ISODE Consortium, March 1995)

    [Wahl, et al 97A]
    M. Wahl, T. Howes, S. Kille; "Lightweight Directory Access Protocol (v3)", RFC 2251 (Critical Angle Inc., Netscape Communications Corp., Isode Limited, December 1997)

    [Wahl, et al 97B]
    M. Wahl, A. Coulbeck, T. Howes, S. Kille; "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions", RFC 2252 (Critical Angle Inc., Isode Inc., Netscape Communications Corp., Isode Limited, December 1997)

    [Wahl, et al 97C]
    M. Wahl, S. Kille, T. Howes; "Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names", RFC 2253 (Critical Angle Inc., Isode Limited, Netscape Communications Corp., December 1997)

    [Howes, et al 97]
    T. Howes, M. Smith; "LDAP: Programming Directory-Enabled Applications with Lightweight Directory Access Protocol" (Macmillan Technical Publishing, 1997)

    [OMG 97A]
    "The Common Object Request Broker: Architecture and Specification, Version 2.1" (Object Management Group, et al, August 1997)

    [OMG 97B]
    "CORBAservices: Common Object Services Specification" (Object Management Group, et al, July 1997)

    [OMG 97C]
    "Finance/Insurance Party Management Facility Request For Proposal" (Object Management Group, June 1997) 
    QUOIN, Inc.
1208 Massachusetts Ave.
Suite 3
Cambridge, MA  02138
Tel:  617-492-6461
Fax:  617-492-6861
E-mail: info@quoininc.com
Web: www.quoininc.com
    		 
    Using CORBA objects directly as a backend datastore for an LDAP server may be attractive to a growing number of organizations.
     
    LDAPv3 includes a schema discovery mechanism, whereby the client can query the server to determine the objects and attributes supported ... CORBA also provides some capabilities for runtime object interface identification and invocation.
     
    Implementation hiding, while one of the CORBA model's strengths, also makes it very difficult for the client to be able to determine what performance it can expect from any given object or its server.
     
    About QUOIN, Inc.
    QUOIN, Inc. is leading the industry in the use of Object Technology to build distributed business components. The Cambridge, MA-based consultancy has extensive experience in software development, object-oriented analysis, design, construction and testing. QUOIN services are customized to each project and organization, providing clients with a depth of expertise unique in the industry.
    The Author
    Theodore Burghart joined QUOIN as Principal Engineer in the spring of 1997. In addition to his contributions to the specifications and implementation of distributed systems, Ted also provides object technology training and consulting services to clients.
     
    [ Top ]  
     
    [ Home | eXchange | F A Q | Find | comment? ]
    Copyright © 20001 internet.com LLC. All rights reserved. + Disclaimer