Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
2000-03-15
2003-01-14
Rones, Charles L. (Department: 2175)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000
Reexamination Certificate
active
06507849
ABSTRACT:
BACKGROUND OF THE INVENTION
Some application developers develop applications which perform data storage and retrieval operations. To this end, an application developer typically writes application source code which includes data storage and/or retrieval commands using a programming language (e.g., the C programming language). In general, the application developer builds an executable application from the application source code (e.g., by compiling and linking the application source code). This executable application contains instructions that run on a computer system to store data within and/or retrieve data from memory of the computer system.
By way of example,
FIG. 1
shows a computer system
20
which includes a first computer
22
-A, a second computer
22
-B, and a network connection
24
allowing communication between the first and second computers
22
-A,
22
-B. Each of the first and second computers
22
-A,
22
-B includes a filesystem. In particular, the first computer
22
-A includes a UNIX filesystem
26
-A. Similarly, the second computer
22
-B includes a UNIX filesystem
26
-B. As shown in
FIG. 1
, each of the UNIX filesystems
26
-A,
26
-B includes files which are logically organized in an inverted tree configuration.
The second computer
22
-B further includes a directory system. In particular, as shown in
FIG. 1
, the second computer
22
-B has a Lightweight Directory Access Protocol (LDAP) directory system
28
-B and operates as an LDAP server. The LDAP directory system
28
-B includes directory entries which are organized in an inverted tree configuration which is similar to that of the UNIX filesystems
26
-A,
26
-B. Directory systems are similar to databases in that they operate as repositories, or storage facilities, for information. However, in contrast to databases, directory systems tend to contain more descriptive, attribute-based information (e.g., names, addresses, job titles, etc.). Furthermore, information is generally more often read from such directory systems than written to such directory systems.
FIG. 2A
shows application code
30
having commands for accessing the filesystem
26
-A of the first computer
22
-A. In particular, the application code
30
, when compiled and linked into an executable application, provides instructions for retrieving information
32
from a file
34
of the filesystem
26
-A.
To create application code for accessing UNIX filesystems, application developers can use file access commands in the C programming language. In general, such commands have standardized names (e.g., “open( )”, “write( )”, “read( )”, “getline( )”, “close( )”, etc.) and standardized expression formats (e.g., operation(arg
1
, . . . ,argN)).
Some application developers develop applications which conform to a programming standard called POSIX, which is an acronym for portable operating system interface for computer environments. By conforming application code to the POSIX programming standard, the application developer has some assurance that the application will be relatively easily portable to POSIX-compliant computer systems. Sun Microsystems, Inc. of Palo Alto, Calif., International Business Machines Corporation of Armonk, N.Y., and Hewlett-Packard of Palo Alto, Calif. are examples of computer manufacturers which provide POSIX-compliant computer systems.
It should be understood that there are other filesystems which can be used for storing and retrieving data. Examples of other filesystems include the MS-DOS filesystem and the Windows/NT filesystem, both of which are provided by Microsoft Corporation of Redmond, Wash.
Furthermore, it should be understood that some computer systems provide access to multiple types of filesystems. For example, some computer systems running the UNIX operating system can be configured to provide access to both a UNIX filesystem and a Windows/NT filesystem. In general, when applications run in such a computer system, the operating system handles application instructions (e.g., system calls) which request access to files of the different filesystems. Typically, when a running application reaches a file access instruction (e.g., open( )), the operating system figures out which type of filesystem the file access instruction is attempting to access (i.e., UNIX or Windows/NT in this example), and then performs one or more file access operations which are appropriate for accessing that type of filesystem.
FIG. 2B
shows application code
40
having commands for accessing the LDAP directory system
28
-B of the second computer
22
-B (an LDAP server). In particular, the application code
40
, when compiled and linked into an executable application, provides instructions for retrieving information
42
from an LDAP directory entry
44
of the LDAP directory system
28
-B. Generally, the computer system
52
-B operates as an LDAP server such that an executable application derived from the application code
40
can run on any of the computers
22
as an LDAP client communicating with the LDAP server.
To create application code for accessing directory systems, an application developer typically obtains a development environment package from a provider or manufacturer of a directory system product (hereinafter referred to as a vendor). Such a package typically includes a vendor-specific application programming interface (API) for developing an application, and a directory system server platform having a suite of services, utilities and tools for testing the application. In general, the application developer includes, in the application code, directory access commands (e.g., “ldap_search( )”, “ldap_entry( )”, “Idap_first_attribute( )”, “ldap_next
13
attribute( )”, etc.) which conform to the vendor-specific API. In the case of LDAP directory systems, such code typically relies on manipulating LDAP information such as directory entry locations, port numbers, etc.
Additionally, it is common for such commands to have unique, vendor-specific names and expressions. Examples of LDAP directory system vendors include the University of Michigan of Ann Arbor, Mich., Sun Microsystems, Inc. of Palo Alto, Calif., International Business Machines Corporation of Armonk, N.Y., and Netscape Communications Corporation of Mountain View, Calif. By way of example, the command for performing a bind function using ADSI, which is provided by Microsoft Corporation of Redmond, Wash., is similar to:
AdsOpenObject(“LDAP://server/en=bols,o=company . . . ).
In contrast, the command for performing a bind function using NDS, which is provided by Novell of Orem, Utah, is similar to:
NWDSLogin(context,o,UserName,UserPassword,o).
Accordingly, LDAP expressions can vary greatly among vendors.
SUMMARY OF THE INVENTION
Applications which access directory systems using vendor-specific APIs are often hindered by unique aspects of such APIs. For example, it is common for LDAP vendors to require unique names and expressions for particular LDAP commands. That is, application developers must use these unique names and expressions in order to properly program an application to a particular LDAP vendor's API. Accordingly, the application developer of an application often relies on each customer having a particular LDAP server product also installed on computer systems running the application developer's application. Otherwise, it may be possible for the application to include one or more LDAP commands (e.g., ldap_open( ), ldap_create( ), ldap_read( ), etc.) or command expressions (e.g., Idap_open(arg
1
,arg
2
) vs. Idap_open(*argl,*arg
2
)) which the computer system cannot understand or handle.
In situations where the LDAP product of a particular LDAP vendor is unavailable but the LDAP product of another LDAP vendor is available, the application developer may be able to port the LDAP application such that it is able to use the other LDAP product. However, in some situations, applications are not easily portable and require significant code changes when switching between different vendor-specific APIs. Furthermore, if even only minor code change
Chapin & Huang , L.L.C.
Cisco Techno-ogy, Inc.
Huang, Esq. David E.
Rones Charles L.
LandOfFree
Methods and apparatus for accessing a data storage system does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Methods and apparatus for accessing a data storage system, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Methods and apparatus for accessing a data storage system will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-3045849