Patent Application
20050015383
This invention relates generally to computer networks, and more particularly to the operations of accessing a database, such as a network directory service, to locate objects in the database.
Web services are a new and rapidly growing technology that promises to revolutionize the way business-to-business and business-to-consumer services are provided and used. Web services comprise web-based applications that dynamically interact with other Web applications. At the core of the Web services is the EXtensible Markup Language (XML), which is an open standard from the World Wide Web Consortium (W3C). XML is used for defining data elements on a Web page and business-to-business documents, and provides a mechanism for communication with the Web services. An XML document uses tags to define data elements and attributes that are arranged in a hierarchical structure. For processing XML documents, the XML Path Language (XPath) has been developed to identify tagged XML elements and their attributes in an XML document, and to calculate numbers and manipulate strings. The syntax of an XPath expression is similar to the directory addressing used in certain operating systems, which use a slash for the root directory as well as the separator between nodes on adjacent hierarchy levels.
Directory service is one of the most common types of network services used in the Internet or other large networks. Various network entities are typically represented in the directory service database by objects of different types. Directory service protocols, such as the Lightweight Directory Access Protocol (LDAP), have been developed for accessing the directory service database to perform directory operations on the objects in the database. Generally, the directory access according to LDAP is based on the application of filters, with each query using a filter to select objects. Moreover, LDAP is session-based, and each session may include a sequence of queries to locate the desired objects.
The directory service database contains many different types of objects, which have their respective attributes. Generally, to maximize the usefulness of the data stored in the database, it is desirable to be able to view the data based on various types of relationships among the data items beyond the basic hierarchical structure of the database. This concept of viewing different types of relationships with the same set of data is called polyarchy. In this regard, it is further desirable to provide a simple and flexible way for a client to specify in a request the kind of data it wants to locate based on polyarchical relationships. Current database access protocols such as the LDAP, however, do not lend themselves readily to this task.
In view of the foregoing, the present invention provides a method and system for accessing objects in a network database that uses a location path expression in a database query to indicate how the desired data may be located. To support such path expressions, relationships linking attributes of the database objects are defined as link paths. This allows the viewing of different types of relations among the object attributes using the same set of data, i.e., in a polyarchical manner. Location path expressions may be formed based on the defined path links between the object attributes. The location path expression includes a view name that identifies the attribute relationship on which the viewing is based, and a plurality of attribute values in a hierarchical manner. A database query including such a location path expression is sent to a database access engine. The database access engine parses the data path expression and generates corresponding directory access requests for locating objects along the path specified in the location path expression to retrieve the desired data.
Turning to the drawings, wherein like reference numerals refer to like elements, the invention is illustrated as being implemented in a suitable computing environment. Although not required, the invention will be described in the general context of computer-executable instructions, such as program modules, being executed by a personal computer. Generally, program modules include routines, programs, objects, components, data structures, etc. that perform particular tasks or implement particular abstract data types. Moreover, those skilled in the art will appreciate that the invention may be practiced with other computer system configurations, including hand-held devices, multi-processor systems, microprocessor-based or programmable consumer electronics, network PCs, minicomputers, mainframe computers, and the like. The invention may be practiced in distributed computing environments where tasks are performed by remote processing devices that are linked through a communications network. In a distributed computing environment, program modules may be located in both local and remote memory storage devices.
The following description begins with a description of a general-purpose computing device that may be used for implementing either a client or a server in an embodiment of a system of the invention for accessing directory data, and the system of the invention and its operation will be described in greater detail with reference to
The hard disk drive 27, magnetic disk drive 28, and optical disk drive 30 are connected to the system bus 23 by a hard disk drive interface 32, a magnetic disk drive interface 33, and an optical disk drive interface 34, respectively. The drives and their associated computer-readable media provide nonvolatile storage of computer readable instructions, data structures, program modules and other data for the personal computer 20. Although the exemplary environment described herein employs a hard disk 60, a removable magnetic disk 29, and a removable optical disk 31, it will be appreciated by those skilled in the art that other types of computer readable media which can store data that is accessible by a computer, such as magnetic cassettes, flash memory cards, digital video disks, Bernoulli cartridges, random access memories, read only memories, storage area networks, and the like may also be used in the exemplary operating environment.
A number of program modules may be stored on the hard disk 60, magnetic disk 29, optical disk 31, ROM 24 or RAM 25, including an operating system 35, one or more applications programs 36, other program modules 37, and program data 38. A user may enter commands and information into the personal computer 20 through input devices such as a keyboard 40 and a pointing device 42. Other input devices (not shown) may include a microphone, joystick, game pad, satellite dish, scanner, or the like. These and other input devices are often connected to the processing unit 21 through a serial port interface 46 that is coupled to the system bus, but may be connected by other interfaces, such as a parallel port, a game port or a universal serial bus (USB) or a network interface card. A monitor 47 or other type of display device is also connected to the system bus 23 via an interface, such as a video adapter 48. In addition to the monitor, personal computers typically include other peripheral output devices, not shown, such as speakers and printers.
The personal computer 20 may operate in a networked environment using logical connections to one or more remote computers, such as a remote computer 49. The remote computer 49 may be another personal computer, a server, a router, a network PC, a peer device or other common network node, and typically includes many or all of the elements described above relative to the personal computer 20, although only a memory storage device 50 has been illustrated in
When used in a LAN networking environment, the personal computer 20 is connected to the local network 51 through a network interface or adapter 53. When used in a WAN networking environment, the personal computer 20 typically includes a modem 54 or other means for establishing communications over the WAN 52. The modem 54, which may be internal or external, is connected to the system bus 23 via the serial port interface 46. In a networked environment, program modules depicted relative to the personal computer 20, or portions thereof, may be stored in the remote memory storage device. It will be appreciated that the network connections shown are exemplary and other means of establishing a communications link between the computers may be used.
In the description that follows, the invention will be described with reference to acts and symbolic representations of operations that are performed by one or more computers, unless indicated otherwise. As such, it will be understood that such acts and operations, which are at times referred to as being computer-executed, include the manipulation by the processing unit of the computer of electrical signals representing data in a structured form. This manipulation transforms the data or maintains it at locations in the memory system of the computer, which reconfigures or otherwise alters the operation of the computer in a manner well understood by those skilled in the art. The data structures where data is maintained are physical locations of the memory that have particular properties defined by the format of the data. However, while the invention is being described in the foregoing context, it is not meant to be limiting as those skilled in the art will appreciate that various of the acts and operations described hereinafter may also be implemented in hardware.
The present invention is directed to a new approach to accessing objects in a database, such a directory service database, by expressing the relationships among attributes of the objects in the database to allow the objects in the database to be located based on different types of relationships among the object attributes. This concept of viewing different types of relationships with the same set of data is termed “polyarchy.” The polyarchy concept of the invention enables clients to query and access the database objects in ways that are much more powerful than conventional database queries, such as LDAP filters even the Structured Query Language (SQL) queries. As a direct result of the polyarchical arrangement of the database, a new form of database query expression can be used to identify a path through the database objects for locating the desired data. Such an expression of a path is hereinafter referred to as a “location path expression.”
As will be explained in greater detail below, in a preferred embodiment, the syntax of the location path expression for accessing database objects in accordance with the invention looks somewhat similar to that of the XML Path Language (XPath), which is for identifying particular parts of XML documents. It must be appreciated, however, that the present invention should not be viewed as a straightforward or obvious application of XPath, because XPath is developed for viewing XML documents, which are not analogous to a database containing objects of different types. Also, it should be appreciated that the invention does not limit itself to data structured like XML documents, and the use of location path expressions for database access in accordance with the invention can be easily applied to various database structures that support hierarchical relationships among the attributes of the database objects.
Before describing the implementation of polyarchy for objects in a database, an exemplary system implementing an embodiment of the invention is described first. Referring now to
In accordance with an aspect of the embodiment, to enable network clients 90 to access the directory service in accordance with a Web services model, a Web service 92 for directory access is provided. As will be described later with reference to
Referring now to
Although the directory hierarchy indicates parent-child relationships between the directory objects, there are many other types of relationships among the attributes of the objects that, although existing conceptually, are not identified by the hierarchy, and such relationships are often difficult to identify by examining the graph of the directory hierarchy. For instance, a manager in a corporation may have a plurality of employees that report to her. In that case, the user object representing the manager may have an attribute in the form of an array called “DirectReports,” with each array element identifying the name or ID of an employee that directly reports to the manager. Similarly, the user object for the employee reporting to the manager may have a data member called “manager” that indicates the name or ID of the manager. The relationship between the “manager” attribute and the “DirectReports” attribute, however, is not explicitly identified and may not be ascertained by checking the attribute names.
Conventionally, directory search operations for the directory service are based on a simple attribute-matching model, and the instructions for performing the searches, such as those according to the LDAP, reflect that approach. For instance, to find the addresses of people reporting to Jane Smith in Fabrikam Corporation, one directory access instruction may be given to find the object for Jane Smith by matching the name “Jane Smith” with the name attribute of user objects identified as employees of Fabrikam Corporation. Once the Jane Smith object is found, its “DirectReports” array is retrieved to identify the names of employees reporting to Jane Smith. Another directory access instruction may then be given for each employee reporting to Jane Smith to find the object with that employee's name. It can be seen that the task of obtaining a simple type of needed information may require the use of multiple database access instructions, and sometimes the instructions have to be recursively performed to obtain the desired information. If the directory access instructions have to be issued by a network client, the client has to have the proper programming logic to carry out the sequence of instructions for retrieving the desired information. This can put a significant burden on the client device (and its software developers), and the network traffic becomes very “chatty” in the process of traversing the relationships. Moreover, to properly form the instructions to accomplish the task, the client has to know how the objects in the directory database are linked to one another, and that requirement is often difficult to meet.
In accordance with the invention, a link between the attributes of two objects can be created to provide a path from one attribute to the other, and such link paths between attributes provides a powerful tool for accessing the data of objects in a database according to different types of relationships beyond the hierarchical relationship of the database. To illustrate this concept,
In accordance with a feature of the invention, once the relationships between attributes of the classes for the database objects are defined, they can be used for locating objects and their attributes in the database by providing a path that uses the relationships between the attributes to lead to the desired data. This new approach to expressing a query for database access is significantly different from the conventional model, such as LDAP, for accessing data in a database. As will become clear from the discussion below, this new enables the use rich, multi-attribute, queries on a directory service or similar databases containing different types of objects with linked attributes. Rich queries can be formed that are difficult to do using conventional directory service query approaches. For instance, as will be explained in greater detail below, the query expressions in may be along the line of “list those employees reporting to Steve Smith who are allowed access to resource B.”
Referring to
Each ViewName parameter in the data path expression represents a “view” based on a predefined relationship between object attributes. The definition of the ViewName is in the configuration data of the server and describes the following things:
By way of example, various examples of the data path expressions for accessing the directory service objects are provided below. The examples in the first set include “simple” location paths in that they follow a straightforward hierarchical path to a specified object and do not use wildcard symbols.
In the examples above, the path expressions are in the abbreviated form. They can also be expressed in the unabbreviated form, wherein each location step in the path has two required parts: an axis and a node test, separated by a double colon (::), as in unabbreviated XPath expressions. For instance, the abbreviated path: Enterprise/business/ may also be written as: child::Enterprise/child::Business.
The following data path expression examples are more complicated than the simple paths shown above due to the use of wildcard features. The wild card symbols and their usage are similar as in XPath expressions. For instance, the asterisk (*) matches any object node regardless of its name. Also, the double forward slash (//) selects from all descendants of the context node, as well as the context node itself, and the @ sign followed by an attribute name is used to select a particular attribute of that name of the context node object.
The data path expressions can be used in database access queries to specify the data that are to be retrieved for operations specified in the queries. Several examples of database queries using data path expressions are provided below. In these examples, the syntax of these queries is very similar to that of XQuery.
1. Find all users who are under DaveD and work in Building 40.
2. Return all DaveD's Direct Report in his/her reports in a hierarchical format.
3. Return Union of all persons who worked in UDDI projects and developers who are at Cost Center 12504.
4. Identify managers that are common to Bob and Alice.
Referring to
To illustrate how the location path expressions are used in searching for the desired data, two examples are provided here. The Manager-DirectReports relationship can be modeled as:
Even though the embodiment of
In view of the many possible embodiments to which the principles of this invention may be applied, it should be recognized that the embodiments described herein with respect to the drawing figures are meant to be illustrative only and should not be taken as limiting the scope of the invention. Therefore, the invention as described herein contemplates all such embodiments as may come within the scope of the following claims and equivalents thereof.
