Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
2000-12-21
2004-11-09
Rones, Charles (Department: 2175)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000, C707S793000, C709S217000
Reexamination Certificate
active
06816864
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Technical Field
The present invention relates in general to a method and system for retrieving and setting set structured data through the Internet. More particularly, the present invention relates to a system and method using Java and XML to manage LDAP data sources.
2. Description of the Related Art
Companies and other organizations are increasingly turning to computer networks, especially the Internet, for distributed applications. Applications, in turn, are often driven by data. This data can be stored in a variety of formats. Flat files can be used, however they provide little support in managing data files, especially as the application data files become large. Traditional database management systems (DBMS), such as a relational or hierarchical database can be used. An example of a relational database is IBM's DB2™ product and an example of a hierarchical database is IBM's IMS™ database product. While a DBMS is excellent at storing and retrieving data and has rich access methods, including use of a Structured Query Language (SQL), a DBMS is not always the right choice when dealing with large distributed systems where speed is often a critical factor and client computing resources are often limited. An emerging protocol for managing data is the Directory Access Protocol (DAP). Directory services, such as DAP, are fast becoming the key to many organizations, allowing applications to locate the resources they need and enabling network administrators to authenticate end-users.
DAP runs over the OSI (Open System Interconnection) network protocol stack—that, combined with its rich data model and operation set makes it somewhat cumbersome and difficult to implement a full-blown DAP client and have it installed on smaller computer systems. X.500 is an overall model for Directory Services in the OSI environment. The model encompasses the overall namespace and the protocol for querying and updating it.
In response to DAP's shortcomings, LDAP, or “Lightweight Directory Access Protocol” was developed. LDAP is, like X.500, both an information model and a protocol for querying and manipulating stored data. LDAP's overall data and namespace model is essentially that of X.500. The major difference is that the LDAP protocol itself is designed to run directly over the TCP/IP stack, and it lacks some of the more esoteric DAP protocol functions.
A major part of X.500 is that it defines a global directory structure. It is essentially a directory Web in much the same way that HTTP and HTML are used to define and implement the global hypertext Web. Anyone with an X.500 or LDAP client may examine the global directory just as they can use a Web browser to examine the global Web.
LDAP is not a replacement for traditional database management systems and is not a substitute for a file system, nor is it a replacement for domain name servers (DNS).
LDAP was initially a low-cost, PC-based front-end for accessing X.500 directories. When the ISO standard proved too cumbersome and overhead-intensive to be widely adopted, LDAP emerged to fill the gap, expanding its original role. The IETF (Internet Engineering Task Force) specification rapidly became the solution of choice for all types of directory services applications on networks using the Internet protocol (IP).
LDAP applications can be loosely grouped into four categories: those that locate network users and resources, those that manage them, those that authenticate and secure them, and any other application that manages data but, for one reason or another, does not use a traditional DBMS. LDAP can save companies time and money. It can help network managers keep pace with the rising demand for directory services. New applications appear every day, but there are currently limits to what the protocol can do for distributed computing. For example, traditional LDAP solutions cannot store all the types of information used by network applications.
The current LDAP specification includes eight features and functions for defining or performing directory-related tasks, such as data storage and retrieval. LDAP uses an information model organized according to collections of attributes and values, known as entries. This model defines what kinds of data can be stored and how the data behaves. For example, a directory entry representing a person named “John Doe” might have an attribute called sn (surname) with a value of “Doe”. The information model, inherited almost unchanged from X.500, is extensible almost—any kind of new information can be added to a directory.
The LDAP schema defines the actual data elements that can be stored in a particular server and how they relate to real-world objects. Collections of values and attributes-representing objects such as countries, organizations, people, and groups are defined in the standard, and individual servers can define new schema elements as well.
The LDAP naming model specifies how information is organized and referenced. LDAP names are hierarchical; individual names are composed of attributes and values from the corresponding entry. The top entry typically represents a domain name, company, state, or organization. Entries for subdomains, branch offices or departments come next, often followed by common name (cn) entries for individuals. Like the LDAP information model, the naming model is derived directly from X.500. Unlike X.500, LDAP does not constrain the format of the namespace; it allows a variety of flexible schemes.
The LDAP security model determines how information is secured against unauthorized access. Extensible authentication allows clients and servers to prove their identity to one another. Confidentiality and integrity also can be implemented, safeguarding the privacy of information and protecting against active attacks like connection hijacking.
The LDAP functional model determines how clients access and update information in an LDAP directory, as well as how data can be manipulated. LDAP offers nine basic functional operations: add, delete, modify, bind, unbind, search, compare, modify DN (distinguished name), and abandon. Add, delete, and modify govern changes to directory entries. Bind and unbind enable and terminate the exchange of authentication information between LDAP clients and server, granting or denying end-users access to specific directories. Search locates specific users or services in the directory tree. Compare allows client apps to test the accuracy of specific values or information using entries in the LDAP directory. Modify DN makes it possible to change the name of an entry. Abandon allows a client application to tell the directory server to drop an operation in progress.
The LDAP protocol defines how all of the preceding models and functions map onto TCP/IP (Transmission Control Protocol/Internet Protocol). The LDAP protocol specifies the interaction between clients and servers and determines how LDAP requests and responses are “formed” (the structure of the data on the transmission path). For example, the LDAP protocol stipulates that each LDAP request is carried in a common message format and that entries contained in response to a search request are transported in separate messages, thus allowing the streaming of large result sets.
The LDAP application program interface (API) details how software programs access the directory, supplying a standard set of function calls and definitions. This API is widely used on major development platforms running C/C++, Java, Javascript, and Perl (among others).
The LDAP data interchange format (LDIF) provides a simple text format for representing entries and changes to those entries. This ability helps synchronize LDAP directories with X.500 and proprietary directories (or a company's HR directory, which is often a source of useful information).
LDAP describes what a directory looks like and how it acts from a client's point of view. However, the directory itself can be distributed across many servers. Each of these servers can maintain a version of the entire directory
Deuser Mark Wyatt
Easton Wyn Gordon
Mahmoudi Hassan
Rones Charles
VanLeeuwen Joseph T.
Woods Gerald R.
LandOfFree
System and method for handling set structured data through a... does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with System and method for handling set structured data through a..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and System and method for handling set structured data through a... will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3333246