Progress Report



Using LDAP in place of middleware specific Naming and/or Directory Services

by Shakil Ahmed


Advisor: Dr. Rod Fatoohi

College of Engineering, San Jose State University

May 2000







Introduction

The purpose of this document to is research, analyze and evaluate the feasibility of using the Lightweight Directory Access Protocol (LDAP) [RFC 1777, v3 RFC 2251] as generic naming and/or directory service replacement for different commercial and popular middleware specific naming and directory services. The intention is to be able to use LDAP as an enterprise wide naming and directory resource both for information storage, search and retrieval. This way several and heterogeneous middleware technologies can all operate seemlessly using a standard, secure, scalable and familiar protocol and integrate several applications data store needs in one server(LDAP in this case). The added benefit is that single API(e.g. JNDI API) can be used by all clients to access, store and retrieve directory data.

In the past, several groups of developers have attempted to solve the common naming/directory issue using various customized techniques and approach. Here is a summary of two such approaches :

In theory, as an extension, they could add a similar library functions for RMI applications (RMI Registry replacement) or typical TCP/IP servers (IP and port). The drawback is that the client and server need to know about the library. However, it is a straightforward and maintainable approach but not at all a generic solution.

1. a LDAP client sends a search string to the LDAP server.

2. the LDAP server translates that string into a CORBA based server's search string and then put it in a unique file.

3. the LDAP server then starts the CORBA client which looks at that file and sends it to the CORBA server.

4. the CORBA based server send the results back to the LDAP server as another file.

5. the LDAP server reads that file and send the results back to the LDAP client.

In the LDAP server side, they replaced the LDAP search function with a custom search function. The LDAP server never knew anything different was going on. This approach seems fairly limited and not scalable. Besides, customizing LDAP APIs to every application needs seem to defeat the purpose of using a standard directory server.



Suggested approach

The approach suggested here is not a “all-in-one” solution. This approach does not solve legacy applications issues and is not completely language neutral. But , it is the goal is to attempt to solve most issues with using LDAP as a generic directory service not necessarily all. It does not seem to be achievable to have a completely language neutral and one directory fits all solution without the requirement of some server side enhancements and modifications. It is believed that, using JNDI as a common API, LDAP can be used to access, store and retrieve many kinds of naming/directory service data. The naming and directory services targeted for this discussion includes Cell Directory Service (CDS) [DCE middleware’s directory service], COS Naming (CORBA’s Naming Service), RMI Registry (Java 2 platform's remote object naming service). Similar discussions and arguments can be made for Network Information Services (NIS) and Novell Directory Service (NDS). The next steps in completing the experiment is to do proof-of-concept. This will be done using the following development steps(not in particular order) :

  1. A CDS Service Provider Interface (SPI) API will be developed as a plugin component to Java Naming and Directory Interface (JNDI) 1.2 API and framework. This will be tested with a CDS client in DCE 1.1 cell environment.

  2. An online bill payment E-commerce application(using Java) will be designed and developed. This application will run on a web browser and would be simplified it (no SSL, no DBMS, no heavy duty back-end processing except for LDAP). This application client would have a web front end and in the back end, it will use LDAP as its data store. The experiment would be that, the server side would actually use some NIS information(saved in LDAP), use Java objects (stored in the LDAP DIT), CORBA objects and may be even a few RMI references(over Internet Inter-ORB Protocol - IIOP). This application will use Java servlet technology to combine everything. This would prove that LDAP can be used pretty much to store any naming/directory information without running a separate name service for each middleware to resolve Java objects, CORBA objects or other references. JNDI will be used as the middle layer that would perform data store and retrieval using the middlewares native API(LDAP, IIOP and Java).



Technical Tidbits

Lets define some terms before diving into the technical details.

Naming Services :- A service that provides for the creation of a standard name for a given set of data. In general, a naming service provides a method for mapping unique identifiers, or names with a specific value, a range of values, or an object that is referenced by the naming service.

Binding :- a mapping between a name and a unique object reference

Namespace :- a set of names in which all names are unique.

Compound name :- a sequence of names that conform to the naming convention of a namespace.

Composite name :- names that span multiple namespaces.

Context :- each node of a directory structure. A context represent a connection to a JNDI Service Provider.

Directory Services :- This a special type of object database that is designed to be read very quickly through various indexing, caching and disk access techniques. Directory service typically describes data in a hierarchical information model. A directory service will always have a naming service but not vice versa. A directory service is a type of naming service that provide a structure to some set of objects or data values. LDAP(an example directory service) allows the definition of arbitrary attributes on a resource. Like files in the file system, contents of directories are referred to by name, relative to the current directory. This current directory is called a context.

Schema :- A schema describes rules regarding the structure of the namespace and the attributes stored in it. Schema specifies the type of objects that can be added to the directory, the mandatory and optional attributes that are possible, and where the objects can be added in the schema.

COS Naming :- CORBA uses this naming service for defining the location of the available objects. Applications contact COS Naming service via the ORB. JNDI environment property java.naming.corba.orb specifies which ORB to use.



LDAP ::

LDAP defines how clients should access data on the server but does not specify how this data is stored in the server. LDAP can become a front-end to any type of data store. Because of this, most popular Directory services now have an LDAP front-end of some type including - NIS, NDS, Active Directory and even NT Domains. The various usage of LDAP servers are: application servers, certificate servers, e-mail servers and clients, PBXs, IPSEC capable routers, VPN software etc.

LDAP schema consists of three primary kinds of definitions :

A unique number is used to represent each type defined in a schema. The schema identifiers are called Object Ids (OID).

To add an entry to an LDAP server, the following must be specified -

  1. name of the entry, a name can have multiple parts

  2. place to insert in the hierarchy - the context

  3. class which the entry implements

  4. Object's. Attribute values

Sun has proposed an IETF standard schema(RFC 2713) for representing Java objects in LDAP.

LDAPv3 specifies a mechanism for a server to respond to a request with a new address, effectively redirecting a client to a new location - this is called referral. In LDAP the special type “top” is a primordial base class of all object classes. Its only attribute is “objectclass” - hence all object classes have this attribute by means of inheritance.



JNDI ::

With JNDI, we still have multiple servers and multiple APIs underneath, but to the application developer, it is a single API. The problem is, all JNDI SPI (drivers to interact with different directory services) are not created equal. Each directory service is still different with their different entry names and capabilities. Hence, applications are more complex and larger and hence more prone to failure. JNDI and LDAP can work together for a more elegant solution. Use JNDI to communicate with LDAP. We could rely on vendors to provide LDAP interfaces to their respective protocols(someday this will be a reality, till then...). For NIS, NDS and NT domains there exists products already which allows us to communicate with them via LDAP.

JNDI uses interfaces heavily. An interface is a type of abstract class that defines a set of methods that a particular class must implement to be concrete. The biggest difference between abstract class and interface is that, a class can extend only a single abstract class while it can implement many different interfaces. Interfaces are a form of multiple inheritance in Java.

A JNDI Service Provider Interface (SPI) or JNDI driver is a set of Java classes that enable us to communicate with a directory service similar to the way a JDBC driver enables us to communicate to a database. A SPI must implement the Context interface(most SPI implements DirectoryContext interface which extends Context interface to enable directory services). The SPI worries about the ugly details like network protocols and encoding/decoding values etc.). JNDI 1.2 Service Providers can support a “federation” concept, where a service provider can pass an operation to another SP if it does not understand the naming or operation scheme. One thing worth noting that can be confusing about JNDI Interfaces, which is, not to confuse Attributes, an interface for managing collections of attributes, with Attribute, an interface for an object that represents a single attribute from the directory service.

JNDI allows to store the following 4 types of Java related objects into the LDAP server :

  1. LDAP directory entries - regular LDAP entries, language neutral, smaller in size.

  2. Serialized Java objects - serialized Java objects (current object and all its related classes are stored in binary format), easiest to store but require more bandwidth and storage, only understood by Java.

  3. Pointers to RMI objects - store a reference in RMI URL format to available RMI classes instead of running a registry in each computer.

  4. References to Java objects - this allows to store a subset of the object inform in the directory server in a format which can be used to recreate the object using Java Factory class at a later time.

The following lists a usage of storing options in LDAP Directory Information Tree(DIT) :

One benefit of using LDAP and JNDI is that, we can have easy access to a networked object persistence which enables the exploitation of a component architecture. To share common data in a platform and language independent format, standard LDAP entries and attributes can be used. Even if this is not a requirement, LDAP entries and attributes should be used because this will be smaller and quicker to do so. Storing object data in LDAP server provides the ability to match an object's hierarchical relationship to its parent's class. The main problem with LDAP is its relatively poor write performance.

What are BDO and BRO ? :

Business Data Objects (BDO) - these are objects that contain only data that correlates specifically with some part of the business. An abstraction of the “physical” items an organization uses to do business.

Business Rule Objects (BRO) - these are the objects that define the computational logic of how the organization does business.

The following are the steps in storing a Java object in the LDAP server using JNDI :

  1. Create a Java class that implements the Serialized interface.

  2. Connect and authenticate(with proper credentials) to the LDAP server with “write” permission.

  3. Create an instance of that class in the application.

  4. Bind the entry to the server with bind() method of the DirContext interface.

The LDAP server's schema must support storing Java objects. To specify a user schema with the Netscape Directory Server, take the slap.user_at.conf and slapd.user_oc.conf and put them in the <NetscapeServer>/slapd-hostname/config directory to replace the empty files that exists by default.

It is important to separate BDO from BRO, which implements business logic. By storing the BDO in LDAP, we can provide a common access protocol to our data over the network using a standard and open protocol. We can abstract our data out and develop a server side Java application to take advantage of the LDAP directory infrastructure.

Retrieving Entries using JNDI from service provider :

There are 2 ways to obtain an object using JNDI :-

A JNDI service provider can be automatically configured to automatically follow referrals via the Java environment property java.naming.referral set to “follow” (set it to “ignore” otherwise and this setting causes exception). If it is set to “throw”, a ReferralException is thrown whenever a server returns a referral. Some JNDI service providers support “delegation” which is the ability of the name server to act as a front end to a remote server.

Storing Entries using JNDI from service providers :

This requires mapping of the object's state and definition to the schema of the repository. A Java object can be stored in an opaque way, but it will then only be available to Java applications. JNDI provides special mappings for certain classes of Java objects, including RMI references. If the object is stored in an opaque manner and it is not serializable, JNDI provides a way to store a proxy for the object for later reconstruction or reconnection - this is called JNDI Reference Object.

Storing Java objects in LDAP using JNDI =

JNDI LDAP service provider has built-in support for the Java-to-LDAP mapping schema. Java objects have natural repositories of their own, including the RMI Registry for RMI objects, and ORB Naming services for Java CORBA objects. RMI remote references are not supported by the JNDI 1.1 Java LDAP service provider, but it is supported in the JNDI 1.2 LDAP service provider.

There are two ways to store RMI object references in the directory :-

MarshalledObject mobj = new MarshalledObject(rmiRef);

and then storing this marshalled object. in LDAP. The LDAP SP in this case, will use the javaMarshalledObject schema. However, for this to work, some application needs to always maintain at least one strong ref to the remote object so that it wont be garbage collected.

JNDI API shields the applications from underlying differences between providers. But, the properties required to initialize a provider are unique to each provider. The way to encapsulate provider environment initialization is via property adapter. This performs the functions for setting up all connection properties. This adapter can retrieve the properties from a properties file or it can even obtain some properties like server-specific credentials from another repository (LDAP or other authentication servers).

RMI ::

Remote Method Invocation (RMI) is Java's built-in distributed object protocol. RMI is analogous to CORBA, but it is lighter-weight, provides a much simpler and standard model for establishing and managing connections between callers and callees. Java object serialization is a general-purpose mechanism for converting an object's state into an encoded form that is independent of the VM context in which the object was created. This is often referred to as “freezing” and the opposite is “thawing”. For an object to be serializable, it must implement the java.io.Externalizable interface. The serialization process is recursive. If a class is serializable, but its superclass is not, none of the attributes of the superclass will be serialized when the object is serialized. Serialized data is “clear” - anyone can read it by writing a simple program. The Externalizable interface provides a way for a class to completely take control over the way it is serialized, including all of its superclass attributes. In general, serialization should not be used for long term data storage. Java 2 adds several enhancements to the serialization mechanism, and changes the serialization format. The version to use can be specified with the Java 2 using ObjectOutputStream.useProtocolVersion() method.

Java passes and returns all objects by reference. A java object ref is always a local one, in the context of the local Java VM. There is no remote referencing built into the Java VM. RMI uses HTTP to retrieve classes dynamically. Before running the server program, the codebase property for the program must be set.

Java -Djava.rmi.server.codebase=http://.......

CORBA from the beginning has had the concept of automatic object creation and activation, which the OMG refers to as a “persistent” object Java 2 adds this feature to RMI , and the component that automatically starts object programs(called server programs) is the object activation daemon “rmid”.

A marshalled object is essentially an object wrapper for a serialized object The true port number (the port number on which the servant object listens) can be obtained by calling getLocalPort() on the ServerSocket. There is one assigned port per server process, since there is one ServerSocket per server process. Within every object reference, RMI by default embeds the IP address of the server which exports the object We can override the use of the IP addresses in remote references. By setting the property java.rmi.server.useLocalHostName to true.



Java and CORBA ::

Java solves the problem of code distribution while CORBA solves the problem of intercommunication between distributed components. The ORB is the component which manages the communication between a system's CORBA objects and objects on other systems. Generally each system has an ORB, although this is not a requirement. The only requirement is that client stubs be able to bind to an ORB, and that the server object adapters be able to bind to an ORB. Most CORBA architecture require at least one ORB per machine.

Object Adapter(OA) is a plug-replaceable component that implements most of the ORB functionality and can be selected based on OA-specific features and advantages. Two important categories of OA are the Basic Object Adapter(BOA) and the Portable Object Adapter(POA). The CORBA specifications define the methods and features of the BOA, but the CORBA Java binding does not include it. This is because, it was realized that a new kind of OA was required and hence POA was introduced. The Java CORBA binding will include POA features when they are finalized. In the mean time, the binding specifies an ORBconnect() method for binding an object to the ORB directly without invoking an OA. Stub implements the interface between a client and its ORB, and a skeleton implements the interface between a server object and its ORB and OA.

An implementation repository(IR) is the ORB’s collection of information about an object type, including the procedure to activate it. An interface repository is a collection information about the methods signatures of objects, so that the objects can be introspected and invoked dynamically at runtime by remote clients. The API for introspecting and invoking CORBA objects dynamically using the interface repository is called Dynamic Invocation Interface (DII). Invoking an object using statically compiled stubs and skeletons is called Static Invocation Interface (SII).

To send a remote invocation request from a client to a server object, CORBA uses a stream protocol to encode the request and results. CORBA allows ORBs to use vendor specific protocols for this, but require all implementations to provide Internet Inter-ORB Protocol (IIOP). The actual messages used by IIOP are defined in a CORBA std called GIIOP, IIOP is GIOP over TCP/IP. A request consists of a message header, request header and request body while a reply consists of a message header, reply header and reply body. The request body contains input parameters according to formatting rules defined in the specification.

An IDL module is a scoping mechanism analogous to Java package. Java binding maps a module to a package. IDL interface maps to a Java Interface. A struct maps to a Java class with no methods. The CORBA Any type is conceptually a typeless object for representing objects that can be of multiple incompatible types, somewhat analogous to void* in C++. IDL has “out” and “inout” parameters, but Java has only “in” parameters. The mapping from CORBA IDL to Java is specified in the CORBA documentation Mapping of OMG IDL to Java, 98-02-61. 

RMI versus CORBA ::

The RMI community often points out that RMI can pass objects by value, whereas CORBA 2 cannot - actually it can, sort of. The principal deficiency that IDL structs have is that an IDL struct is logically a hierarchical structure and therefore cannot reference other structs in a recursive or cyclic manner. This makes it hard to map Java objects because Java objects often contain referenced of other objects.  The recent Objects By Value specification, OMG 98-1-18, adds value semantics to IDL to allow Java-style object graphs to be passed over the wire.

Another advantage of RMI over CORBA is RMI’s ability to deploy code as needed. The most important advantage of RMI over CORBA in typical organizational applications is its simplicity. How does a program finds CORBA objects? The answer is, remote method call return object references which can be used to get additional object references. The steps to get the first object reference are :



LDAP and CORBA ::

There has been a very wide acceptance of LDAP as a directory service and CORBA as an object distributions mechanism. Hence, using CORBA objects directly as a back-end datastore for an LDAP server is very attractive and feasible. The two technologies have several architectural attributes that make them a good fit to work with one another. Some of these attributes are -

LDAP objects are actually a named collections of named attributes, each of which has associated data type and one or more values. An object is named by its dn attribute, or Distinguished Name. Each object has an objectclass attribute that defines its structure within the server's object schema, where the required and optional data attributes are defined. LDAP provides for a runtime configuration of the object schema. LDAPv3 supports a schema discovery mechanism(not supported in LDAP v2), using which a client can query the server to determine the objects and attributes supported. The LDAPv3 also supports a special objectclass extensibleObject[Wahl, et al 97B] which can contain any attributes. This allows a runtime definition by the client of objects to be stored by the server.

CORBA IDL is platform and language neutral; data and call format conversions are handled transparently by the ORB. All interfaces to CORBA objects and the data type used in those interfaces, are specified in IDL. From a client's point of view, CORBA object is entirely opaque i.e., the object's implementation and location are unknown to the application.

The commercially available LDAP servers and tools do not provide ways for building a customized server to access a specific datastore. Translation between CORBA objects and LDAP objects should not be too difficult with familiarity with streaming protocols. Generally, it would be expected that a given CORBA object implementations one or more LDAP object classes and that the CORBA object's attributes can be statically mapped to the attributes defined for the LDAP object(s).[consider CORBA’s IR and DII capabilities].

The UM LDAP slapd sever was designed to allow multiple back-end datastore. This server is modular and support pluggable back-end datastores. This model allow the definition of a datastore to be supported in the server configuration files and implemented essentially as an object, in a non object-oriented language. SLAPD does not support real object-oriented back-end implementations well. Overall the interface between the procedural server and the object-oriented back-end can be difficult to manage.

Ideally, to provide a truly flexible server, it should be written completely in an object-oriented language like C++. Properly done, this would make integrating CORBA and other object oriented back-ends much easier while providing improved error handling and greater manageability.



RFC 2714 - Schema for representing CORBA object references in an LDAP Directory :

CORBA applications require access to CORBA objects. They use the CORBA COS Naming service for storage and retrieval of CORBA object references. CORBA applications should be able to use the LDAP directory as a repository for CORBA object references. RFC2714 defines a common way for applications to store and retrieve CORBA object references from the directory. Using this common schema any CORBA application can read and store CORBA object references in the directory in a interoperable way. The schema defines the storage of CORBA object references not objects. The CORBA object reference can be used to invoke calls on the object and is known as “interoperable object reference” (IOR). This schema is supported for representing CORBA object in LDAPv3 directory. 

Schema description :

A CORBA object reference is represented in the directory by the object class corbaObjectReference. corbaObjectReference is a subclass of the abstract corbaObject object class. corbaObjectReference is an auxiliary class, which means that it needs to be mixed in with a structural object class.

corbaObjectReference class has one mandatory attribute -

( 1.3.6.1.4.1.42.2.27.4.1.14

NAME 'corbaIor'

DESC 'Stringified interoperable object reference of a CORBA object'

EQUALITY caseIgnoreIA5Match

SYNTAX 1.3.6.1.4.1.1466.115.121.1.26

SINGLE-VALUE

)

The object class corbaContainer is used in a directory entry which represents a CORBA object or object reference. It is a structural object class. corbaContainer is not required when a subclass of corbaObject (like corbaObjectReference) is mixed in with another structural object class.

corbaObject class has two optional attributes -

  1. corbaRepositoryId : multivalued, stores repository id of the interfaces implemented by a CORBA object.

( 1.3.6.1.4.1.42.2.27.4.1.15

NAME 'corbaRepositoryId'

DESC 'Repository ids of interfaces implemented by a CORBA object'

EQUALITY caseExactMatch

SYNTAX 1.3.6.1.4.1.1466.115.121.1.15

)

  1. description : textual description of the object. This is defined in RFC2256 LDAPv3 user schema.

-- from RFC-2256 --

( 2.5.4.13

NAME 'description'

EQUALITY caseIgnoreMatch

SUBSTR caseIgnoreSubstringsMatch

SYNTAX 1.3.6.1.4.1.1466.115.121.1.15{1024}

    )

The LDAPv3 format Schema object class definitions are shown below (from RFC 2714) :-

( 1.3.6.1.4.1.42.2.27.4.2.9

NAME 'corbaObject'

DESC 'CORBA object representation'

SUP top

ABSTRACT

MAY ( corbaRepositoryId $ description )

)

( 1.3.6.1.4.1.42.2.27.4.2.10

NAME 'corbaContainer'

DESC 'Container for a CORBA object'

SUP top

STRUCTURAL

MUST ( cn )

)

( 1.3.6.1.4.1.42.2.27.4.2.11

NAME 'corbaObjectReference'

DESC 'CORBA interoperable object reference'

SUP corbaObject

AUXILIARY

MUST ( corbaIor )

)

-- Matching rule from ISO X.520 --

( 2.5.13.5

NAME 'caseExactMatch'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.15

)



RFC 2713 - Schema for representing Java objects in an LDAP Directory :

There are defined schema elements for representating the following Java objects:

Java Serialized Objects

Java Marshalled Objects

JNDI References

LDAP directory can be used to store Java objects.  RFC2713 defines a common way for applications to store and retrieve Java objects from the directory. Using this common schema any Java application can read and store Java objects in the directory in a interoperable way. A Java remote object is stored as either a Java marshalled object or a JNDI reference.

Schema description :

Java Objects =

A Java object is stored in the directory by using the object class javaObject. This is the base class from which the other Java object related classes derive : javaSerializedObject, javaMarshalledObject and javaNamingeReference. javaObject is an abstract object class.

The object class javaContainer represents a directory entry for storing a Java Object. The javaContainer schema definition is shown below :

( 1.3.6.1.4.1.42.2.27.4.2.1

NAME 'javaContainer'

DESC 'Container for a Java object'

SUP top

STRUCTURAL

MUST ( cn )

)

The schema definition for javaObject class is :

( 1.3.6.1.4.1.42.2.27.4.2.4

NAME 'javaObject'

DESC 'Java object representation'

SUP top

ABSTRACT

MUST ( javaClassName )

MAY ( javaClassNames $ javaCodebase $ javaDoc $ description )

)

The javaObject class has 1 mandatory attribute and 4 optional attributes -

( 1.3.6.1.4.1.42.2.27.4.1.6

NAME 'javaClassName'

DESC 'Fully qualified name of distinguished Java class or interface'

EQUALITY caseExactMatch

SYNTAX 1.3.6.1.4.1.1466.115.121.1.15

SINGLE-VALUE

)

-- Matching rule from ISO X.520 --

( 2.5.13.5

NAME 'caseExactMatch'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.15

)

  1. javaClassNames : multivalued, fully qualified names of the object's Java classes and interfaces. If the javaClassNames attribute is present, it should include the value of javaClassName.

( 1.3.6.1.4.1.42.2.27.4.1.13

NAME 'javaClassNames'

DESC 'Fully qualified Java class or interface name'

EQUALITY caseExactMatch

SYNTAX 1.3.6.1.4.1.1466.115.121.1.15

)

  1. javaCodeBase : multivalued, stores the location of the object's class definition.

( 1.3.6.1.4.1.42.2.27.4.1.7

NAME 'javaCodebase'

DESC 'URL(s) specifying the location of class definition'

EQUALITY caseExactIA5Match

SYNTAX 1.3.6.1.4.1.1466.115.121.1.26

)

  1. javaDoc : stores a pointer(URL) to the Java documentation for the class.

( 1.3.6.1.4.1.42.2.27.4.1.12

NAME 'javaDoc'

DESC 'The Java documentation for the class'

EQUALITY caseExactIA5Match

SYNTAX 1.3.6.1.4.1.1466.115.121.1.26

)

  1. description : textual description of the object. This is defined in RFC2256 LDAPv3 user schema.

Serialized Objects =

To “serialize” an object means to convert its state into a byte stream in such a way that the byte stream can be converted back into a copy of the object.  A Java object is serializable if its class or any of its superclasses implements either the java.io.Serializable interface or its subinterface java.io.Externalizable. The Java platform specifies a default algorithm by which serializable objects are serialized.

A serialized object is represented in the directory by the attributes javaClassName, javaClassNames, javaCodeBase and javaSerializedData. The mandatory attribute, javaSerializedData, contains the serialized form of the object.

( 1.3.6.1.4.1.42.2.27.4.1.8

NAME 'javaSerializedData'

DESC 'Serialized form of a Java object'

SYNTAX 1.3.6.1.4.1.1466.115.121.1.40

SINGLE-VALUE

)

The directory entry that contains a serialized object is represented by the object class javaSerializedObject, which is a subclass of javaObject. javaSerializedObject is an auxiliary object class.

( 1.3.6.1.4.1.42.2.27.4.2.5

NAME 'javaSerializedObject'

DESC 'Java serialized object'

SUP javaObject

AUXILIARY

MUST ( javaSerializedData )

)

Marshalled Objects =

To “marshall” an object means to record its state and codebase(s) in such a way that when the marshalled object is “unmarshalled”, a copy of the original object is obtained, possibly by automatically loading the class definitions of the object.  Any object that is serializable or remote(i.e. Implements the java.rmi.Remote interface) can be marshalled. Marshalling records codebases(unlike serialization).  For remote objects, marshalling records the remote object's stub, instead of the object itself.

A marshalled object is represented in the directory by the java.rmi.MarshalledObject class. Marshalled object is available only on Java 2 Platform, standard edition, v1.2 and higher releases.

A marshalled object is represented in the directory by the attributes javaClassName, javaClassNames, and javaSerializedData.

The mandatory attribute, javaSerializedData, contains the serialized form of the marshalled object(i.e. The serialized form of the MarshalledObject instance).

The directory entry that contains a marshalled object is represented by the object class javaMarshalledObject, which is a subclass of javaObject. javaMarshalledObject is an auxiliary object class.

( 1.3.6.1.4.1.42.2.27.4.2.8

NAME 'javaMarshalledObject'

DESC 'Java marshalled object'

SUP javaObject

AUXILIARY

MUST ( javaSerializedData )

)

JNDI references =

A JNDI reference is a Java object of class javax.naming.Reference. It consists of a class information about the object being referenced and an ordered list of addresses. An address is a Java object of class javax.naming.RefAddr. Each address contains information on how to construct the object.

A JNDI reference is stored in the directory by the attributes javaClassName, javaClassNames, javaCodeBase, javaReferenceAddress and javaFactory. The mandatory attribute, javaSerializedData, contains the serialized form of the object.

( 1.3.6.1.4.1.42.2.27.4.1.11

NAME 'javaReferenceAddress'

DESC 'Addresses associated with a JNDI Reference'

EQUALITY caseExactMatch

SYNTAX 1.3.6.1.4.1.1466.115.121.1.15

)

( 1.3.6.1.4.1.42.2.27.4.1.10

NAME 'javaFactory'

DESC 'Fully qualified Java class name of a JNDI object factory'

EQUALITY caseExactMatch

SYNTAX 1.3.6.1.4.1.1466.115.121.1.15

SINGLE-VALUE

)

The directory entry that contains a JNDI reference is represented by the object class javaNamingReference, which is a subclass of javaObject. javaNamingReference is an auxiliary object class.

( 1.3.6.1.4.1.42.2.27.4.2.7

NAME 'javaNamingReference'

DESC 'JNDI reference'

SUP javaObject

AUXILIARY

MAY ( javaReferenceAddress $ javaFactory )

)

Remote Objects =

Remote objects that use IIOP are represented in the directory as CORBA object references. Remote objects that use JRMP are represented in the directory in one of the two ways : as a marshalled object or as a JNDI reference. The advantage of using JNDI reference is that, this can be done without a reference to the remote object.

A javaSerializedObject or a Serializable object stored as a javaMarshalledObject represents the object itself.

A javaNamingReference or a remote object stored as a javaMarshalledObject represents a pointer to the object.



It is fairly evident that LDAP can be used as data store and possibly replace the CORBA COS Naming, RMI Registry etc. RFC2307 by L. Howard(http://www.faqs.org/rfcs/rfc2307.html) describes “An Approach for using LDAP as NIS”. This rfc describes a mechanism for mapping entities related to TCP/IP and the UNIX system into X.500 entries so that they may be resolved with LDAP protocol. This document also proposes a set of attribute types and object classes with specific guidelines for interpreting them. 



References

Professional Java Server Programming - Wrox press limited 1999 ISBN 1-861002-77-7

Developing Java Enterprise Applications - Stephen Asbury, Scott Weiner, John Wiley & Sons, Inc ISBN : 0-471-32756-5

Advanced Java 2 Development for Enterprise applications - 2nd edition - Clifford J Berg - Sun Microsystems Press ISBN : 0-13-084875-1

Java Programming with CORBA - Vogel, Duddy - Object Management Group ISBN : 0-471-17986-8

CORBA 3 - Reaz Hoque - IDG Books ISBN : 0-7645-3200-6

CORBA as an LDAP Server Datastore - An Architecture for Internet Directory Services Ted Burghart, QUOIN, Inc. http://www.innergy.com/features/corba-ldap.shtml

RFC 2714 - Schema for representing CORBA object references in an LDAP Directory - V. Ryan, R. Lee, S. Seligman - Sun Microsystems, Inc. October 1999 http://www.faqs.org/rfcs/rfc2714.html

RFC 2713 - Schema for representing Java objects in an LDAP Directory - V. Ryan, R. Lee, S. Seligman - Sun Microsystems, Inc. October 1999 http://www.faqs.org/rfcs/rfc2713.html

RFC 2251 - LDAP v3 Accessing X.500 style directory Services. http://www.faqs.org/rfcs/rfc2251.html

RFC 2252 - LDAP v3 Syntax Definitions http://www.faqs.org/rfcs/rfc2252.html

RFC 2256 - LDAP v3 Standard Attributes List http://www.faqs.org/rfcs/rfc2256.html

RFC 2253 - LDAP X.500 DNs to identify entities for representation of strings http://www.faqs.org/rfcs/rfc2253.html

RFC 1558 - LDAP search filters http://www.faqs.org/rfcs/rfc1558.html