1
MOBILITY SUPPORT WITH CORBA DIRECTORIES Oliver Haase , Andreas Schrader, Kurt Geihsy , Rudolf Janzy
Computer & Communication Research Laboratories, NEC Europe, Adenauerplatz 6, D-69115 Heidelberg e-mail:
[email protected] y Distributed Systems and Operating Systems, University of Frankfurt, PO Box 11 19 32, D-60054 Frankfurt am Main e-mail: fgeihsjr
[email protected]
CORBA, Directory, Mobility, LDAP
ABSTRACT
In the very near future, various aspects of mobility will play a major role in telecommunications. For the support of user and service mobility, the location-independent storage and retrieval of all kind of user-related information is essential. For this purpose, directories are the basic supporting technology. One of the most widely accepted standards for directories is LDAP. On the other hand, CORBA is becoming the de-facto standard for distributed object technology. In this paper, we present a CORBA directory service bridging the gap between LDAP and CORBA. In contrast to LDAP, the semantic plausibility of queries can be syntactically checked at compilation time and correctly typed query results are delivered. We have implemented both pure CORBA servers and LDAP wrappers that we have interconnected to a network of directory servers providing fully transparent access to the entire distributed information base. This paves the path for a smooth migration from LDAP to CORBA directory services. Our performance results show that the general purpose IIOP protocol performs even better than the dedicated LDAP protocol. The bene t of mobility can be illustrated excellently in the context of IP telephony. Therefore, we demonstrate pro leoriented and downloadable service in a real-life telephony environment.
I. INTRODUCTION
In recent telecommunication systems, various aspects of mobility, e.g., terminal, user and service mobility, move more and more into the focal point of interest. As the basic supporting technology in this context, user directories become a crucial part of the network infrastructure. This is true since the use of personal numbers (or to be more general: personal identi ers) instead of device numbers requires the ability to map a personal identi er to the device(s) a user is currently registered with. These mappings can be kept in user directories. The need for such a mapping will be even considerably higher, if a user has a dial-in connection to the Internet, e.g., via PPP, and gets a di erent IP address assigned each time he actually dials in. Directories can also be employed for the storage of userpro le information to enable personalised services anywhere in the network. Moreover, not only service settings but also entire services (or service components such as graphical user Appeared in Proc. CNDS'00 Intl Conference on Communication Networks and Distributed Systems Modelling and Simulation, San Diego, USA, January 2000.
interfaces) can be referred to by directory servers. The services themselves can then be downloaded to the current location of a mobile user. One of the most widely accepted standards for directories is the TCP/IP based lightweight directory access protocol LDAP, de ned by the IETF (RFC97). Though in a strict sense the term LDAP denotes only the access to the directory, it implicitly relies on an X.500-like datamodel with respect to the distribution model, data formats, etc. Today, LDAP is used by a large variety of platforms and applications, e.g., the TAPI 3.0 telephony platform (TAPI99), the telephony platform TOPS (Anerousis99), the Novell Directory Services NDS (Novell99), Netscape's Navigator, to mention only some of them (see also (Maass99) for an overview). In spite of LDAP's lower complexity compared to X.500, the direct use of LDAP is still rather dicult. Hence, the IETF has de ned language APIs for C (RFC95) as well as for Java (Weltman99). These APIs, which are realised as client libraries, encapsulate the packing and unpacking of the actually sent LDAP packets by higher level functions. On the other hand, CORBA is becoming the de-facto standard for distributed object technology, in particular in telecommunications (OMG98). Since CORBA provides for a huge variety of distribution transparency aspects, e.g., location transparency, access transparency, and replication transparency, as well as for platform and language independence, many recent telecommunication platforms exploit it as an enabling technology for the easy deployment of value-added services. In our application domain it is worthwile particularly reminding of the language independence aspect. Because in contrast to the concrete language interfaces for LDAP, a CORBA IDL interface is future-proof since it is completely independent of any particular programming language. The use of the CORBA directory service by means of automatically generated client stubs is depicted in gure 1. Obviously, there is a gap between the CORBA remote service access technology and the directory access protocol LDAP. In this paper we present a CORBA directory service which bridges this gap. Our approach results in an IDL interface similar to the Java-API for LDAP, but, inherently, with the bene t of language independence. In particular, the actual query language remains exactly the same as in LDAP. The similarity to the existing APIs eases the use of our directory services for experienced LDAP users and also makes the port from LDAP to CORBA very straight-forward. Although we intentionally provide a very similar interface to LDAP, we exploit CORBA's strong type system for two other improvements compared to LDAP: First, we deliver the
Directory.idl
Perl-Client Java-Client C++-Client Perl-Client Stub Java-Client Stub C++-Client Stub
IDL Compiler
Directory Server
generates automatically
network communication
C++-Server Skeleton
Fig. 1. Use of the CORBA directory service through generated client stubs
model, i.e. structure of the information base, as well as the core part of the supported query language, i.e. the de nition of so-called lters. A.1 Distinguished Names. Since the CORBA Directory Service adopts the data model of X.500/LDAP, the set of all entries forms a tree hierarchy. With respect to its parent entry, each entry is uniquely identi ed by a relative distinguished name RDN, consisting of a name and a value. struct RDNType { string name; string value; };
The sequence of all RDNs from the top entry root to a particular entry constitutes its globally unique distinguished name DN.
result entries of a query in the correct type format, and second, we express as much semantics of a query through syntactic structures as possible. This allows for checking the plausibility of a query at compilation time. Moreover, due to CORBA's transport protocol independence { although IIOP (GIOP over TCP) is mandatory for each CORBA implementation, other approaches, e.g., GIOP over SS7 also exist { our approach is even applicable to diverse network technologies. We have prototyped implementations of both pure CORBA servers and LDAP wrappers, which we have inter-connected to a network of CORBA directory servers, each of which providing fully transparent access to the entire distributed information base. The interworking of pure CORBA servers with LDAP wrappers paves the path for a smooth migration from LDAP to CORBA directory services. The performance results of our implementations show the competitiveness of a CORBA directory server compared to an LDAP server. Moreover, the general purpose CORBA IIOP protocol proves to perform even better than the dedicated LDAP protocol. The remainder of this paper is structured as follows: in section II we formally specify the directory service. Section III proposes and compares two di erent approaches for implementing a directory server, namely a pure CORBA server and an LDAP wrapper. Performance measurements, validating the feasability of our approach, are considered in section IV. In section V we show how we employ the CORBA directory services in order to support mobility in our IP telephony environment. Finally, section VI concludes the paper.
typedef sequence DNType;
II. SPECIFICATION
Though in most cases we handle collections of values of a certain type, there are a few cases where the use of a collection would be inadequate; thus, we de ne both a single value of the value type de ned above and a set of values.
In this section we will specify the CORBA directory service by means of CORBA's Interface De nition Language IDL. The speci cation is divided into three subsections, the rst one consisting of some general de nitions, the second one de ning the directory service from a user's point of view, and the third one de ning it from an administrative perspective.
A. General
In this section, the foundations of the CORBA directory service are exposed. This comprises the static part of the data
A.2 Directory Entries. Both X.500 and LDAP support a broad variety of so-called attribute syntaxes, which constitute the possible types an attribute can be of. The syntaxes include not only standard types like Boolean and Integer, but also formats like e.g., JPEG or Telephone Numbers. However, in contrast to data representation formats with explicit typing, e.g., BER (used within ASN.1) and CDR (used by CORBA), LDAP encodes only the value of an attribute, not its type. Hence, for each received data value, the receiver has to know the original type of the data. The situation is di erent with CORBA, which o ers a strong type system and automatic marshalling/unmarshalling of parameters. As a consequence, our CORBA directory service can deliver typed attribute values. More technically speaking, an attribute value is transported inside a union, with the tag indicating the actual type. Beside the usual CORBA base types, this union can also hold distinguished names as well as object references (Ryan99). In our IP telephony environment, we use this capability to store references to certain services, e.g., answering machines, within the personal directory entry of the respective user. enum ValueType { VALUE_STRING, VALUE_BINARY, VALUE_LONG, VALUE_BOOLEAN, VALUE_OBJECT, VALUE_DN };
typedef sequence BinaryData; union Value switch(ValueType) { case VALUE_STRING: string string_value; case VALUE_BINARY: BinaryData binary_value;
case VALUE_LONG: long long_value; case VALUE_BOOLEAN: boolean boolean_value; case VALUE_OBJECT: Object object_value; case VALUE_DN: DNType dn_value; }; union Values switch(ValueType) { case VALUE_STRING: sequence string_values; case VALUE_BINARY: sequence binary_values; case VALUE_LONG: sequence long_values; case VALUE_BOOLEAN: sequence boolean_values; case VALUE_OBJECT: sequence object_values; case VALUE_DN: sequence dn_values; };
An attribute consists of a name and one or more values. An entry comprises its identifying DN and a sequence of attributes. struct Attribute { string name; Values vals; }; typedef sequence AttributeSeq; typedef string AttributeName; typedef sequence AttributeNameSeq; struct Entry { DNType dn; AttributeSeq attributes; }; typedef sequence EntrySeq;
A.3 Query Language. As already mentioned in section I, we rely on the same query language as LDAP. The only di erence is that we do not permit the so-called extensible matching which allows to de ne own matching functions. In LDAP as well as in our CORBA directory service, the actual query language is expressed by the de nition of lters, which are passed inside a search request. In the following BNF de nition the LDAP string representation of a lter { without extensible matching { is given; here braces f g indicate arbitrarily many occurrences of the enclosed term, while square brackets [ ] denote zero or one occurrence of the respective term. lter ::= '(' ltercomp ')' ltercomp ::= and j or j not j item and ::= '&' lterlist
or ::= 'j' lterlist not ::= '!' lter lterlist ::= f lter g item ::= simple j present j substring simple ::= attr ltertype value ltertype ::= '=' j '~=' j '=>' j '=
