JPH07129453A - Method for constructing directory system using object-oriented data base - Google Patents

Abstract

PURPOSE:To provide a directory system for efficiently collating attributes and further for improving maintainability and extensiveness. CONSTITUTION:First and second RDN are provided respectively as RDN objects 61 and 62, the group of attributes A-C consisting of the first RDN is expressed as the chain of attribute objects 611-613, and the group of attributes A-C consisting of the second RDN is expressed as the chain of attribute objects 621-623. The arrangement of attributes at the respective chains of attribute objects 611-613 and 621-623 is previously sorted by fixed rules. When the collation with the RDN object 62 is requested to the RDN object 61, the leading attribute object 611 is extracted and collated with the attribute data of the leading attribute object 621 inside the RDN object 62 and only when they are matched, the collation with the following attribute objects 612 and 623 is started.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a method of constructing a directory system, which is an information management system, realized by using an object-oriented database (OODB).

[0002]

2. Description of the Related Art As is well known, an entry, which is an information management unit of a directory system, is managed by a tree structure. The path between nodes (entries) in this tree structure is a Relative Distinguished Name (RD).
N), which is itself defined by a set of attributes.
This attribute has a type (attribute type) and a value (attribute value). Generally, an unspecified number of these attributes form an RDN. This usually complicates the structure of the RDN.

In order to specify an entry in the entire tree structure, all paths from the root of the tree structure are required, so that it is necessary to specify by the RDN column. This RD
Distinguished Name (D) of the entry in the N column
N).

In the DIB (directory information base),
A search that does not follow a tree structure is also possible, and the search path based on this is called the entry name. The DN and the name have the same appearance, and their appearance is indistinguishable. That is DN
Whether it is a name or a name will be distinguished by the information in each entry.

As described above, the RDN has a complicated structure, and therefore the DN and the name formed by the RDN are also complicated.

Conventionally, this RDN is represented by a chain (using pointers) of an unspecified number of attributes which is a constituent element of the RDN, and the complexity of the structure is the same as that of the processing and the complexity of the program. It was connected to Therefore, not only the processing efficiency is lowered, but also the extensibility and maintainability of the program are lowered.

Such a conventional problem will be specifically described with reference to FIGS. 11 and 12.

FIG. 11 shows an example of an RDN matching model in a conventional directory system.

In FIG. 11, the RDN object D0
, D1 are the objects of RDN matching and are realized by using the RDN as an object.

The RDN object D0 is the corresponding RD
Attribute objects D02, D03, and D that realize the three attributes A, B, and C constituting N respectively as objects.
Have 04. These attribute objects D02, D03, D04
Are linked by pointers (links) D05 and D06.

On the other hand, the RDN object D1 is an attribute object D12, D which realizes the three attributes B, C, A constituting the corresponding RDN as objects.
Holds 13, D14. These attribute objects D12, D13,
D14 is linked by pointers (links) D15 and D16.

Such RDN objects D0 and D1
In order to verify the RDN indicated by and to show that it has a matching relationship D2, first, the number of attributes D which is a constituent element is D
It is necessary to indicate that 01 and D11 match as indicated by reference numeral D21, and that the respective attributes match each other as indicated by reference numerals D22 to D24.

Here, the coincidence D21 of the number of attributes D01 and D11
Since it can be obtained by giving data to the RDN objects D0 and D1 or by tracing the chain of attribute objects, it can be easily realized. However, since the attributes (objects) that are the constituent elements are arranged randomly, it is not easy to collate the attributes.

Conventionally, the processing flow of the procedure (method) for checking the matching relationship of the RDN is the conventional RD of FIG.
Taking the procedure D07 of the N object D0 as an example, it is as shown in FIG. The flow of the conventional RDN matching process will be described with reference to the flow chart shown in FIG.

First, for the RDN object D0, R
When a message is issued requesting a match with the DN object D1, the corresponding procedure D in the object D0
07 (represented as procedure E0 in FIG. 12) is called. In this procedure D07 (procedure E0), first, the number of attributes D01 of the own object D0 and the comparison object D
The attribute number D11 of 1 is acquired and the comparison is performed (step E01). In the example of FIG. 11, since each has three attributes, the matching D21 is obtained by the collation in this step E01.

Next, in the procedure D07 (procedure E0), it is necessary to show the coincidences D22 to D24 of the respective attributes.
The collation message E4 is transmitted to the first attribute object D02 (expressed as attribute D02 in FIG. 12 for simplification) in the attribute object chain (attribute chain) of the N object D1 (step E02).

Then, the attribute object D02 calls the procedure D021 in its own object. This procedure D02
Within 1 (represented as procedure E1 in Figure 12), RDA
The object of the attribute A matching the object D02 of the attribute A in the object D0 is the RDN object D
In order to show that the attribute object D1 also exists, the first attribute object D12 in the attribute object chain of the RDN object D1 is acquired (step E11), and the attributes indicated by the attribute objects D01 and D02 are compared ( Step E12).

In the example of FIG. 11, the attribute object D01,
The attributes indicated by D02 do not match. In this case, within the procedure D021 (procedure E1) of the attribute object D02, the RDN
By tracing the pointer D15 in the object D1, the next attribute object D13 is acquired, and the attribute is compared again with the attribute object D02 (step E13). Since this also does not match, by tracing the next pointer D16 again in the RDN object D1,
Further, the next attribute object D14 is acquired, and the attributes are compared with the attribute object D02 (step E).
14). In the collation here, the coincidence relationship D22 is established, and the RDN object D0 of the request source is notified of the collation result "coincidence" (step E15).

The RDN object D0 is the procedure D07.
When this collation result is received by (procedure E0), it is shown that the attribute A (object D14 of it) is in the RDN object D1.

Here, first, by tracing the pointer D05 in the RDN object D0, the next attribute object D03 (object D03 of attribute B) is acquired (step E03). And the previous attribute object D02
In the same manner as in the case of, the attribute B indicated by the attribute object D03 is also found to be present in the RDN object D1 (attribute object D12 therein), and the matching relation D
23 is shown (steps E04, E21 to E23).

Similarly, the RDN object D
Also for the attribute C indicated by the last attribute object D04 in 0, since the object D13 of the same attribute C exists in the RDN object D1, a coincidence relationship D24 is shown (steps E05, E06, E31 to E34).

As described above, the number of attributes matches,
As a result of showing that all the attributes in the RDN object D0 also exist in the RDN object D1, the RD
The coincidence relation D2 of N comes to hold.

As a result, the RDN object D0 becomes
According to the procedure D07 (procedure E0), the agreement of the entire RDN is reported to the request source (step E07).

As described above, conventionally, in order to check whether or not a certain attribute exists in (an object of) an RDN to be collated, an attribute chain (a chain of attribute objects) in the (object of) the RDN is checked. ) Had to be followed according to the pointer, and the processing efficiency was poor. In particular,
If the target attribute did not exist in the RDN object to be collated, it would be compared with all the attributes in (the object of) the RDN, which was even less efficient.

That is, conventionally, there is a problem that maintainability and extensibility are reduced by explicitly performing a pointer operation indicating a chain of attributes, and processing is performed by comparing attributes arranged randomly as they are. There was a problem of reduced efficiency.

Conventionally, entry retrieval and DN acquisition are performed separately, and in order to return the DN of the specified entry, the entry itself must have the DN information or the tree structure must be the parent. The DN was acquired by going back to the node and joining the RDNs.

However, since data duplication occurs in the former method, the data capacity is increased by double management and the code amount for maintaining consistency is increased. In the latter method, searches are performed twice. However, there is a problem in that the processing speed is reduced due to.

[0028]

SUMMARY OF THE INVENTION As mentioned above, OO
In a conventional directory system using a DB (Object Oriented Database), an RDN having a complicated structure is used.
Since the attribute string forming the (relative identification name) is realized by explicitly managing the chain of pointers, it is necessary to explicitly identify the data by the program.

For this reason, conventionally, the data structure and the program are tightly coupled, and the expandability and maintainability are poor. Further, since the entry is searched and the DN (identification name) of the entry is separately acquired, duplication of data and duplication of processing are caused, which is inefficient.

The present invention has been made in consideration of the above points, and its purpose is to realize an RDN (relative identification name) and its constituent attributes as objects, and At the RDN
By giving the order of an unspecified number of attributes that make up, and rearranging these attributes in advance according to a predetermined fixed rule, attribute matching can be efficiently performed,
Moreover, it is an object of the present invention to provide a method for constructing a directory system that can improve maintainability and expandability because it does not require an explicit pointer operation.

Another object of the present invention is to reduce the duplication of data and the duplication of processing by performing the retrieval of the entry and the DN (identification name) of the obtained entry in parallel to improve the efficiency. It is to provide a method of constructing a directory system capable of performing.

[0032]

According to the present invention, the data to be managed by the directory system is OODB.
(Object-oriented database) to store and manage,
The RDN (relative when processing and associating the entry forming the structural unit of the information managed by the directory system with the object (instance) in the object-oriented manner and selectively selecting another entry that is a subordinate node from each entry (Identification name) and its constituent attributes are also realized as objects (RDN object and attribute object), and in the RDN object, an unspecified number of attributes (objects) forming the RDN are arranged in the order. And that these attributes are rearranged in advance according to a predetermined fixed rule.

In such a configuration, since no explicit pointer operation is required, maintainability and expandability can be improved. In addition, the order of the attributes (attribute objects) in the RDN object follows a certain rule,
The attribute to be collated can be easily obtained, and the end of the collation can be quickly determined, so that efficient attribute collation can be performed.

Further, according to the present invention, a name and a DN are expressed by a chain of objects (RDN objects) indicating an RDN, and when an entry is searched, the RDN is removed from the name (search path) to be searched and the DN (acquisition) is acquired. It is also characterized in that it is connected to (path).

In such a configuration, since it is possible to perform entry retrieval and DN acquisition in parallel, duplication of data and duplication of processing can be reduced.

[0036]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS An embodiment of the present invention will be described below with reference to the drawings.

FIG. 1 is a block diagram showing a model of a directory system according to an embodiment of the present invention.

The system shown in FIG. 1 is composed of a computer (client computer) 10 having a client function and a computer (server computer) 12 having a server function. The client function of the client computer 10 and the server function of the server computer 12 are each realized by software. The client computer 10 and the server computer 12 are connected by a communication line 11.

The client computer 10 and the server computer 12 do not necessarily have to be physically independent.
It may be realized on the same computer. In that case, the communication is directly performed by the software signal without passing through the communication line 11.

The client computer 10 provides an interface with the user, and the user process 1
01, and a directory user agent (DUA) 102 provided as another process or subroutine of the process 101.

In such a client computer 10, the items requested by the user are the user process 10
1, the request for the directory system is issued to the DUA 102.

The DUA 102 converts the request from the user process 101 into a format based on the directory protocol, and issues the converted request to the server computer 12 via the communication line 11. When the client computer 10 and the server computer 12 are realized on the same computer, a request is issued directly to the server computer 12.

Further, the DUA 102 receives the status resulting from this request from the server computer 12,
The process is changed to a form suitable for the processing of the user process 101 and transmitted to the process 101.

The user process 101 receives the status from the DUA 102, further processes it if necessary, and reports the processing result to the user.

The server computer 12 actually provides management, retrieval, and updating means for data. The server computer 12 includes a directory system agent (DSA) 121 and a directory information base (DI) in which data to be managed by the server computer 12 is stored.
B) 122. The DIB 122 is an OOD (not shown)
It is managed by B (object-oriented database).

The request issued by the DUA 102 of the client computer 10 is the DSA 1 in the server computer 12.
Received by 21. The DSA121 is the DIB12
2 provides a function to access the data (directory information) stored in (the database that manages), converts the protocol of the received request from the DUA 102 into a form suitable for actual processing, and stores it in the DIB 122. Issues a search or update request.

The DIB 122 performs actual processing in response to the request from the DSA 121, and reports the processing result as D.
Perform on SA121.

The DSA 121 converts the processing result report from the DIB 122 into a format based on the directory protocol, and reports it to the DUA 102 of the client computer 10.

Next, an example of a model of the information storage structure in the DIB 122 will be described with reference to FIG.

It is specified that the information storage structure of the DIB (directory information base) in the directory system is a tree structure. Therefore, the information storage structure of the DIB 122 in this embodiment also has a tree structure as shown in FIG. A unit of information in the DIB (122) is called an entry and constitutes a node in this tree structure.

The DIB (122) has a special entry (root entry) 211 called a root. In the example of FIG. 2, an entry A212 exists as a lower entry of this entry 211. Further, in the example of FIG. 2, the entry A 212 has two lower entries including the entry B 213, but the entry B 213 has no lower entry. An entry such as this entry B213 is called a leaf entry.

As is clear from the example of FIG. 2 described above, each entry has an unspecified number of lower-order entries (it is not necessary to have it), and only one direct higher-order entry. In addition, each entry holds information in the form of a column of attributes.

In the directory system,
There is a special entry called alias. In the example of FIG.
Entry D21 which is a subordinate entry of entry C214
5 is an alias for the entry A212. The search for the entry D215 is expanded to the search for the entry A212. Therefore, assuming that the entry A212 is, for example, the company (target object) after the company name change and the entry D215 is the company (target object) before the company name change, the entry A212 is searched even if a search request for the entry is made with the old company name. It becomes possible to do.

Now, referring to FIG. 2, for example, entry B2
In order to specify the processing for 13, the search path DN, that is, the chain of RDN221 and RDN222, or another name, that is, RDN2
23, RDN 224, and RDN 2222.

FIG. 3 shows a model of the information storage structure in the OODB of the DIB 122 of FIG.

FIG. 3 shows a state where each entry in FIG. 2 is realized as an object (entry object). For example, the root entry 211 in FIG.
Is realized by the root object 311 and the entry A
212 and entry B213 are the objects 3 and 3, respectively.
12 and the object 313. The entry C214 and the entry D215 are realized by the object 314 and the object 315, respectively.

Further, the RDN indicating the path between the entries shown in FIG. 2, for example, RDN 221, 222, 223, 224.
Is realized by linking links 321, 322, 323, and 324 between corresponding objects, as shown in FIG. Similarly, the information indicating the entry A212 that is the expansion destination of the entry D215, that is, the alias expansion destination 231.
Is the pointer 3 pointing to the object 312 of the entry A212, and the pointer 3 pointing to the object 312 of the entry A212.
It is realized by having 31.

FIG. 4 shows an example of a lower entry management structure in an object (entry object) indicating the above-mentioned entry.

The object (entry object) indicated by reference numeral 40 in FIG. 4 is an object (dictionary structure object) 402 for managing lower entries of the entry corresponding to the object, and a lower object based on the designated RDN. It has a procedure (search procedure) 401 for searching an entry (an entry object corresponding to the entry).

Object (dictionary structure object) 4
02 has a dictionary structure in which when an RDN which is a path to a corresponding lower entry is given to the object 402, an object indicating the lower entry is returned. This dictionary structure object 402 includes a procedure 4021 for returning an object indicating a corresponding lower entry using the given RDN as an index, and an RDN in which the corresponding RDN is realized as an object.
An index string 4022 composed of a group of objects 403, 404, ... And RDN (RDN object 403,
..) corresponding to the entry specified by 404 ...), and an entity sequence 4023 made up of a group of pointers pointing to objects (entry objects) 41, 42.

Next, the flow of the lower entry search processing according to the procedure 401 in the object (entry object) 40 shown in FIG. 4 will be described with reference to the flowchart of FIG.

First, the entry search request from the user is
User process 101, D in the client computer 10
UA102 and DSA121 in the server computer 12
Sent to the DIB 122 via the
It is assumed that a request for retrieving an object indicating a subordinate entry is given to the entry object 40 shown in FIG. 4 stored in the (object-oriented database).

Upon receiving this search request, the object 40 calls the corresponding procedure 401 (represented as procedure 50 in FIG. 5). This procedure 401 (procedure 5
In (0), the search request received by the object 40 is converted into a format that is easily understood by the dictionary structure object 402 that manages the lower-order entry, and the search message and the (search-target lower-order entry as an argument A process of sending the RDN (indicating the path of the) to the object 402 is performed (step 501).

Upon receiving this search message, the object 402 calls the corresponding procedure 4021 (expressed as procedure 51 in FIG. 5) and starts its processing.

In this procedure 4021, first, an object (RDN object) matching the designated RDN is selected from the index column 4022 (step 511). Here, assuming that the RDN object 404 shown in FIG. 4 is selected, the substance sequence 40 corresponding to (the RDN indicated by) the RDN object 404.
The entry object 42 pointed to by this pointer is acquired based on the pointer stored in the 23 position (step 512).

Next, in the procedure 4021 (procedure 51), the acquired entry object 42 and its result report (status indicating the processing result) are notified to the requesting entry object 40 (step 513). As a result, the processing of procedure 4021 (procedure 51) ends.

When the entry object 40 is notified of the result report, the procedure 401 of the object 40 is notified.
In (procedure 50), the acquired entry object 42 and its result report are further notified to the request source.

Next, the RDN object 40 in FIG.
R using the RDN object represented by 3,404
The DN matching model will be described with reference to FIG.
The RDN here is the conventional RDN shown in FIG.
It is assumed to be the same as RDN in the collation model of.

In FIG. 6, the RDN object 61,
Reference numeral 62 is a target of RDN matching, and is realized by using the RDN as an object.

The RDN object 61 is the corresponding RD
Attribute objects 611 and 61 that realize the three attributes A, B, and C constituting N as objects, respectively.
Has 2,613. That is, the group of attributes A to C that are the constituent elements of the RDN corresponding to the RDN object 61 is expressed as a chain of attribute objects 611 to 613. Further, the RDN object 61 has a procedure 614 for checking the RDN matching relationship, and the attribute objects 611, 612, 613 have procedures 6111, 6121, 6131 for checking the attribute matching relationship.

On the other hand, the RDN object 62 is an attribute object 621 that realizes the three attributes A, B, and C constituting the corresponding RDN as objects.
It has 622 and 623. That is, the RDN object 62
A group of attributes A to C that are components of RDN corresponding to
It is expressed as a chain of attribute objects 621 to 623. The RDN object 62 has a procedure 624 for checking the matching relationship of RDNs, and the attribute objects 621, 622, 623 have procedures 6211, 6221, 6231 for checking the matching relationship of attributes.

Here, the arrangement of attributes by the chain of attribute objects 611 to 613 in the RDN object 61 and the arrangement of attributes by the chain of attribute objects 621 to 623 in the RDN object 62 are both sorted in advance according to a certain rule (see FIG. In the example of 6, attribute A,
Sorted in the order of B and C).

Therefore, the RDN object 61 and R
In order to indicate the match 63 with the DN object 62, the match between the attribute objects (attributes shown) at the same position in the chain of objects, that is, the match 631 between the top attribute object 611 and the attribute object 621,
Next attribute object 612 and attribute object 62
The match 632 of 2 and the match 633 of the last attribute object 612 and the attribute object 622 may be indicated.

The flow of this RDN collation processing will be described with reference to the flow chart shown in FIG.

First, it is assumed that the RDN object 61 receives a collation message requesting collation with the RDN object 62.

The RDN object 61 then calls the corresponding procedure 614 (represented as procedure 70 in FIG. 7). In this procedure 614 (procedure 70), the top attribute object 611 is extracted from the own object 61, and similarly, the top attribute object 621 is extracted from the RDN object 62 (step 70).
1).

These attribute objects 611 and 621 are not collated at the same level. Here, RDN
A comparison request message (matching message) is sent from the object 61 to the attribute object 611 using the attribute object 621 to be matched as an argument (step 702). The attribute object 611 has a procedure 6111 for comparing actual attributes.

When the attribute object 611 receives the collation message from the RDN object 61, the attribute data of the attribute A stored in the own object 611,
The attribute data of the attribute A stored in the attribute object 621 given as an argument is stored in the procedure 611 (see FIG. 7).
Then, the comparison is performed according to the procedure 71) (step 711), and the coincidence relation 631 is obtained. Then, the attribute object 611 notifies the requesting RDN object 61 of the report of the result of the comparison and collation (step 712).

Procedure 614 of RDN object 61
In (procedure 70), when a result report indicating a match is received from the attribute object 611, the process for the next attribute matching is started. Here, by incrementing the counter for each attribute of the RDN objects 61 and 62 by one,
The second attribute objects 612 and 622 from the attribute object chain in the RDN objects 61 and 62 are acquired (step 703). Then, by the procedure 6121 in the attribute object 612 (represented as the procedure 72 in FIG. 7), the previous attribute objects 611, 621
Attribute objects 612 and 622
The attribute data of the attribute B stored in is compared (step 721), and the coincidence relation 632 is obtained. Then, the attribute object 612 notifies the requesting RDN object 61 of the result of the comparison and comparison (step 722).

Procedure 614 of RDN object 61
In (procedure 70), when the result report indicating the match is received from the attribute object 612, the process for the next attribute matching is performed. Here, the last attribute object 613, 623 is acquired from the attribute object chain in the RDN objects 61, 62 by further incrementing the counter for each attribute of the RDN objects 61, 62 (step 705). Then, the procedure 6131 (expressed as procedure 73 in FIG. 7) in the attribute object 613 compares the attribute data of the attribute C stored in the attribute objects 613 and 623 (step 731), and the coincidence relation 633 is obtained. Then, the attribute object 613 notifies the requester RDN object 61 of the report of the result of the comparison and collation (step 732).

In the RDN object 61, the attributes A to A of the respective attribute objects 611 to 613 are included.
C is all collated, and the corresponding matching relationships 631-6
Since 33 is obtained, it is judged that the matching relation 63 of the RDN itself is established. Therefore, the RDN object 61 notifies the request source of the report of the matching result indicating the matching of the RDNs according to the procedure 614 (procedure 70) (step 707). As a result, the RDN matching process by the procedure 614 (procedure 70) in the RDN object 61 is completed.

As is clear from the above description of the operation, according to the present embodiment, the sequence of attributes in the RDN objects 61 and 62 in the chain of the attribute objects 611 to 613 and 621 to 623 is preset according to a certain rule. Since they are sorted, only one collation partner is needed for each attribute. Therefore, even if they match, matching can be performed efficiently. Further, when a mismatch occurs, it is not necessary to collate the attributes thereafter, which is also efficient in this respect. In addition, the chain of attribute objects in the present embodiment does not require explicit pointer operation, does not need to explicitly identify data by a program, and simply O
Since it can be provided by an ODB (object-oriented database) library, maintainability can be improved.

Next, the DN acquisition processing in this embodiment will be described with reference to the model example of DN acquisition shown in FIG. 8 and the flow charts shown in FIGS. 9 and 10 in combination with FIGS. 2 to 4. To do. Note that FIG. 9 shows the flow of DN acquisition processing in the case of no alias, and FIG. 10 shows the flow of DN acquisition processing in the case of alias.

Here, the entry B213 in FIG.
It shall be acquired by N. In this case, the designation of DN can be expressed by the model shown as the search path 81 in FIG. The search path 81 shown in FIG.
For the notation, first search by RDN221, then R
This shows that the search by the DN 222 is performed.

FIG. 8A shows a state in which the search process itself has not yet been performed, and therefore the acquired path (acquired path) 82 remains empty at this point.

It is not necessary to permanently store the search path 81 and the acquisition path 82 described above, and in this embodiment, they are secured as a queue in a temporary storage area.

Now, the DN acquisition processing in this embodiment is performed in parallel with the entry (entry object realizing the) retrieval processing. The search processing of this entry (when it is not an alias) has already been described with reference to FIG. Therefore, here, the DN acquisition process will be mainly described.

First, for the entry object 311 in FIG. 3 corresponding to the route entry 211 in FIG.
It is assumed that there is a search request. Initially, the search path 81 and the acquisition path 82 are in the state shown in FIG.

The entry object 311 has the same structure as the entry object 40 shown in FIG. Therefore, the operation (behavior) of the entry object 311 will be described with reference to the object structure of FIG.

Since the entry object 311 is not an alias, the corresponding procedure (search procedure) 401 (represented as procedure B0 in FIG. 9) is first called as shown in the flowchart of FIG.

In procedure 401 (procedure B0), FIG.
The RDN 221 as the first search target is removed from the search path 81 in the state shown in (a) (step B01), and then the search message is sent to the dictionary structure object 402 (see the object 40 in FIG. 4) in the entry object 311. B3 is sent (step B02).

Then, in the procedure 4021 (expressed as procedure B1 in FIG. 9) in the object 402,
Similar to the case of searching the lower entry (object indicating) shown in FIG. 5, the corresponding entry (here, as is clear from FIG. 2 is used as an index, the RDN 221 removed from the search path 81 first. A2
An object (here, the entry object 312) that realizes 12) is acquired (steps B11 and B1).
2). Then, in the procedure 4021 (procedure B1), the acquired entry object 312 and the result report (search success message) are compared with the procedure B0 of the request source entry object 311 as indicated by the symbol B4 in FIG. A notification is given (step B13). This completes the processing of procedure 4021 (procedure B1).

When the entry object 311 is notified of the search success message, the same object 31
In the procedure B0 (procedure 401) of No. 1, the RDN 221 previously separated from the search path 81 is connected to the acquisition path 82 (step B03). As a result, the search path 81 and the acquisition path 82 transit from the state shown in FIG. 8A to the state shown in FIG. 8B.

Next, starting from the retrieved entry A212, the next retrieval by the RDN 222 is performed. Here, as described above, the entry object 312 indicating the entry A 212 is (entry object 3
Since it has already been acquired in the procedure B0 (procedure 401) of 11), the same retrieval message as that previously transmitted to the entry object 311 may be transmitted to this acquisition object 312 (step B04).

Upon receiving the search message, the entry object 312 calls the procedure (corresponding to the procedure 401 shown in FIG. 4) of the object 312 (expressed as procedure B2 in FIG. 9).

The processing in the procedure B2 is similar to the processing of the procedure B0 in FIG. 9 described above because the entry object 312 (the entry 212 corresponding to the entry object) is not an alias. Therefore, after going through the same process as procedure B0,
With the RDN 222 removed from the search path 81,
The entry object 313 indicating the entry B 213 corresponding to the RDN 222 is acquired, and further this RDN 22
2 is connected to the acquisition path 82. Search path 8
1 and the acquisition path 82 transit from the state shown in FIG. 8B to the state shown in FIG. 8C.

At this time, the starting point of the search is the entry B213.
Since the search path 81 is empty, no further search is necessary.
It can be seen that 3 is the desired entry. Also, the D
N has been acquired on the acquisition path 82.

Procedure B2 (corresponding to procedure 401 shown in FIG. 4) in entry object 312 (see FIG. 9)
Then, the entry object 313 indicating the acquired entry B 213 and its result report (search success message)
Is notified to the procedure B0 of the request source entry object 311 as indicated by the symbol B6 in FIG.

Upon receipt of this notification, the entry object 311 further notifies the request source of the acquired object 313 (at the entry object 312) and the result report (step B05). In this way, the entry object 311 indicating the route entry 211 is
When the result is reported to the requester, the whole process is completed.

Next, the search request by the name as shown in the search path 81 of FIG.
A description will be given of the DN acquisition processing when the entry object 311 in FIG.

First, the first RDN 223 of the search path 81
Both entries corresponding to the following RDN 224 are not alias entries. Therefore, the process of searching for an entry and acquiring the DN is performed by the RDNs 221 and 222 described above.
Similar to the case of the search path 81 shown in (a), the entry C21 corresponding to the RDN 223 is performed twice.
4 (indicating entry object 314) and RDN2
The entry D 215 (entry object 315 indicating) corresponding to 24 can be acquired. As a result, the starting point of the search moves to the entry D215, and the search path 81 and the acquisition path 82 transit from the state shown in FIG. 8D to the state shown in FIG. 8E.

The entry D215 which is the new starting point of the search is an alias entry of the entry A212.
As shown in FIG. 2, the alias entry D215 is the alias expansion destination 2 which is the data indicating the DN of the entry A212.
I have 31 The entry object 315 of the alias entry D 215 has a pointer 331 that points to the entry object 312 of the entry A (alias expansion destination entry) 212.

Therefore, the alias entry D215 becomes the starting point of the search, and the entry object (alias object) 315 of the entry D215 (procedure 4 in FIG.
When the procedure C0 shown in FIG. 10 is called, the starting point of the search is moved to the entry A212, and as shown in FIG.
The acquisition path 82 in the state of
N (here, RDN221) can be replaced (steps C01 and C02).

As a result of the above steps C01 and C02, the search path 81 and the acquisition path 82 are shown in FIGS. 8 (e) to 8 (b).
State (the state of the search path 81 does not change), and within the entry object (alias expansion destination object) 312 of the alias expansion destination entry A212 that is the new starting point of the search (procedure 401 shown in FIG. 4). The procedure C1 (corresponding to the above) is called as indicated by the symbol C2 in FIG. Thus, the alias entry D215
The access to the entry object (alias object) 315 of the object 315 is indicated by (the pointer 331 of) the object 315 (alias expansion destination entry A2).
(12) The access to the entry object (alias expansion destination object) 312 is transparently replaced.

In procedure C1, procedure B shown in FIG. 9 is used.
The same process as 0 is performed. As a result, the starting point of the search moves to the target entry B213, and the acquisition path 82 shown in FIG. 8C is obtained.

As described above, in this embodiment, by performing the entry search and the DN of the search target entry in parallel, it is possible to suppress the duplication of data duplication management and processing.
It is possible to build an efficient directory system.

[0107]

As described in detail above, according to the present invention, R
The DN and its constituent attributes are also realized as objects, and an unspecified number of attributes forming the RDN are arranged in the object of the RDN, and these attributes are preset according to a certain rule. Since the rearrangement is performed, attribute matching can be efficiently performed, and since explicit pointer operation is not required, maintainability and expandability can be improved.

Further, according to the present invention, since the retrieval of the entry and the acquisition of the DN of the acquired entry are performed in parallel, duplication of data and duplication of processing can be reduced and efficiency can be improved. .

[Brief description of drawings]

FIG. 1 is a block configuration diagram showing a model of a directory system according to an embodiment of the present invention.

2 is a diagram showing an example of a model of an information storage structure in the DIB 122 in FIG.

3 is a diagram showing a model of an information storage structure in OODB of the DIB 122 of FIG.

FIG. 4 is a diagram showing a lower entry management structure in an entry object in the embodiment.

5 is a diagram for explaining a flow of a lower entry search process according to a procedure 401 in the object (entry object) 40 shown in FIG.

FIG. 6 is a diagram showing an RDN matching model in the embodiment.

FIG. 7 is a view for explaining the flow of RDN matching processing in the embodiment.

FIG. 8 is a diagram showing a model of DN acquisition in the embodiment.

FIG. 9 is a view for explaining the flow of a DN acquisition process when the alias is not the same in the embodiment.

FIG. 10 is a view for explaining the flow of DN acquisition processing in the case of an alias in the embodiment.

FIG. 11: RDN in conventional directory system
The figure which shows the collation model of.

FIG. 12: RDN in conventional directory system
For explaining the flow of the matching process of FIG.

[Explanation of symbols]

10 ... Client computer, 11 ... Communication line, 12 ... Server computer, 101 ... User process, 102 ... Directory user agent (DUA), 121 ... Directory system agent (DSA), 122 ... Directory information base (DIB), 211 ~ 215 ... Entry, 221-224 ... RDN, 231 ... Alias expansion destination,
311 to 315 ... Object (entry object), 321 to 325 ... (object) link, 3
31 ... Pointer, 40-42 ... Object (entry object), 401, 4021 ... Procedure, 402 ...
Dictionary structure object, 403, 404 ... RDN object, 4022 ... Index sequence, 4023 ... Physical sequence, 50, 51 ... Procedure, 61, 62 ... RDN object, 611-613, 621-623 ... Attribute object, 614, 624, 6111 , 6121, 613
1, 6211, 6221, 6231 ... Procedure, 70, 7
1 ... Procedure, 81 ... Search path, 82 ... Acquisition path, B0 ...
B2 ... procedure, C0, C1 ... procedure.

Claims (6)

[Claims] 1. An object-oriented database stores, manages, and processes data to be managed by a directory system, associates an entry forming a unit of information managed by the directory system with an object-oriented object, and The relative identification name (RDN) when selectively selecting another entry that is a subordinate node from the entry, and the attribute that is its constituent element,
Each attribute is realized as an object, and in the object of the relative distinguished name (RDN), an unspecified number of attributes constituting the relative distinguished name (RDN) are arranged in the order, and these attributes are set to a predetermined constant value. A method for constructing a directory system characterized by rearranging in advance according to the law of. 2. In order to express a tree structure of a directory information base (DIB) which is an information management form of the directory system, the information of a subordinate entry is stored in the object corresponding to each entry. 2. The method for constructing a directory system according to claim 1, wherein the object of the entry and the object of its relative identification name (RDN) are combined as a set. 3. The relative identification name (RDN) is a unique identification name (DN) having a one-to-one correspondence with the entry, or a name for uniquely identifying the entry by a search path other than the identification name (DN). 3. The method for constructing a directory system according to claim 1, wherein the object is represented by a chain of objects that indicate 4. A head object is separated from an object chain indicating the identification name (DN) or the name in the object indicating the entry, and a direct subordinate entry corresponding to the relative identification name indicated by the separated object is associated. 4. The directory system according to claim 3, further comprising: a procedure for acquiring an object, transmitting the remaining object chain to the acquired object, and setting a termination condition for the entry search when the chain disappears. How to build. 5. The stacking of the separated objects in another object chain to obtain the identification name (DN) or the name that matches up to that point from the object chain.
How to build the described directory system. 6. When a search that does not depend on a normal search path occurs, the stack of object chains is replaced with an object chain that indicates a normal search path up to that point, so that the entire normal search path is replaced. The method for constructing a directory system according to claim 5, wherein the directory system is obtained.