Browse Prior Art Database

Method for reducing impedance mismatch between LDAP Trading Partner Profile data and application clients. Disclosure Number: IPCOM000028363D
Original Publication Date: 2004-May-12
Included in the Prior Art Database: 2004-May-12
Document File: 4 page(s) / 158K

Publishing Venue



How do you interface the two very different solution environments of OO applications and LDAP servers. Furthermore, how can you design to accommodate unforeseen data structure changes in the LDAP data in such a way that impact to application code is minimized.

This text was extracted from a PDF file.
At least one non-text object (such as an image or picture) has been suppressed.
This is the abbreviated version, containing approximately 43% of the total text.

Page 1 of 4

Method for reducing impedance mismatch between LDAP Trading Partner Profile data and application clients.

Numerous issues can arise when designing applications that access information stored in LDAP servers.

The typical problem is due to different constructs used in the respective environments. The application environment is constrained by the constructs provided by it's programming language, while the LDAP space is constrained by tree constructs loosely defined by its schema. Although LDAP API's are available for most programming languages, they provide only an LDAP-centric view of the data - the application still has to know what the data's tree structure looks like, and use the API's to navigate through the data using that knowledge.

Another problem arises due to the non-static nature of the data. Although LDAP data storage solutions are ideal when the data is of a high-access and low-update nature, it's unreasonable to expect that the structure of the data will never need to be changed (as with Trading Partner Profiles).

Eventually, the tree structure of the data will need to be enhanced for example, by adding a new simple leaf type or perhaps a complex leaf object definition will need modification. Typically, the impact to an application when the data needs to be changed in this manner consists of having to update all the application components that deal with the LDAP API's as well as the components that encapsulate the data, and of course, this potential problem gets bigger if we consider that other applications may be accessing the data as well.

Problem in context of Trading Partner Profiles Trading Partner Profiles (TPP's) often exhibit properties that are best expressed with object oriented concepts. For example, in B2B applications, TPP details can vary between customers belonging to the same company. For example, they may be associated with different departments or areas within their company that have negotiated separate contracts with a supplier. Hence, from the supplier's point of view, the TPP's could be conceptualized as a hierarchy of TPP's with "base" and default values (such as security credentials typically used by all customers belonging to a particular company) contained in a parent TPP and "overriding" and custom values (such as entitled catalog url's or custom rules for generating Quotes) contained in child TPP's.

This conceptualization clearly fits the OO concept of inheritance, but unfortunately isn't supported by LDAP API's or schema, an otherwise attractive place to hold TPP information.

Figure 1 below shows the impedance mismatch [Keene 93] between an LDAP TPP data and an application structure.


Page 2 of 4

The Solution

Conceptually, it is desirable to separate the design of the application from the design of the data, so that the application does not depend on the details of how the TPP's are stored in LDAP.

Ideally, it would be advantageous to be able to modify the structure and/or content of our TPP...