Data processing: database and file management or data structures – Database design – Data structure types
Reexamination Certificate
1998-12-02
2001-10-09
Black, Thomas (Department: 2171)
Data processing: database and file management or data structures
Database design
Data structure types
C707S793000, C707S793000, C707S793000, C379S030000
Reexamination Certificate
active
06301589
ABSTRACT:
BACKGROUND OF THE INVENTION
1. Field of the Invention
The present invention relates to a technique which can improve operability in managing a replica of directory data.
2. Related Art Statement
It is now often the case that, in an OA (Office Automation) environment, such as an in-house information system, in which a number of independent systems such as a mail system, a file sharing system etc. are intermixed, a user has plural items of user identifying information such as mail addresses, login names, passwords, etc. Accordingly, with increase or decrease of users, an administrator must add or eliminate each item of the user identifying information used in respective systems, which imposes a heavier burden on the management.
Thus, it is desired to lighten the administrator's management burden by employing a directory system which can perform directory services for administering items of user identifying information used in a plurality of systems and items of information existing on apparatuses and resources in a unified manner. By applying such a directory system, it will be possible to search for information desired by a user and provide it.
Heretofore, such a thus-described in-house information system has been constructed separately for each small department. However, in-house information systems different for respective departments can not smoothly perform procedures relating to movements of personnel or mail exchanges between departments. Thus, construction of a large-scale wider area in-house information system unified for the whole company is rapidly advanced.
As such a large-scale wider area in-house information system develops, it is desired for a directory system to maintain access performance irrespective of the scale of the system. In addition, from the viewpoint of reliability, multiplexing of the service is required for preventing interruption of the entire service caused by the occurrence of a problem in a single place.
To reply to such a request, it is effective to arrange replicas of directory data in a plurality of places. Hereinafter, a replica of directory data is referred to as “replica data”, and replicating directory data is referred to as “replication”.
As a standard relating to replication in directory service, there can be mentioned X.500 recommended by CCITT. In X.500, a client/server type distributed system architecture is provided for directory service, and DAP (Directory Access Protocol) is provided as a protocol for accessing a directory among clients and servers.
Concerning replication, a directory server that manages original directory data (master data) of a replication source and supply directory data to be replicated is defined as a supplier side, and a directory server that manages replica data and receives the directory data to be replicated is defined as a consumer side. Further, DSP (Directory Information Shadowing Protocol) is provided as a replication protocol between a directory server on the supplier side and a directory server on the consumer side.
As an operation model, there are a “push” model in which replication is started up by a directory server on the supplier side, and a “pull” model in which replication is started up when a directory server on the consumer side requests data.
On the other hand, IETF (Internet Engineering Task Force) employed LDAP (Light Weight Directory Access Protocol) (RFC1777) which operates on a TCP/IP stack as a standard protocol for directory access.
Now, conventional replication using LDAP as a replication protocol will be described.
In the following, a directory server that manages master data is called a “supplier directory server”, and a directory server that manages replica data is called a “consumer directory server”. Further, a server that propagates a modify operation performed in the supplier directory server to a consumer directory server is called “replication server”.
As a directory access request in LDAP, there are a reference type directory access request that does not change directory data and an update type directory access request that makes change in directory access data. As the reference type directory access request, there exists only a search request. As the update type directory access request, there are an entry addition request, an entry deletion request, and an RDN change request.
When the supplier directory server succeeds in a modify operation in accordance with an update type directory access request, it adds a time stamp to replication log of this modify operation, and stores it as a replication record in a replication log file. Such time stamps are used for identifying the order in which replication records were stored, i.e., the order in which modify operations according to respective update type directory access requests were performed.
In the conventional replication server, when replication is to be performed, replication records are first acquired from the replication log file in such an order that time stamps are not decreased. Then, based on the acquired replication records, update type directory access requests (LDAP access requests) are prepared, and the prepared LDAP access requests are issued to a consumer directory server.
As a result, that consumer directory server can perform modify operations in accordance with the same update type directory access requests in the same order as the update type directory access requests which caused the changes performed in the supplier directory server.
However, since, as described above, the replication server only propagates modify operations, an administrator of the consumer directory server must prepare a replica of the master data as replica data before the replication is started.
Operation of the replication is a “push” model when the replication server starts replication in accordance with output of replication records by the supplier directory server, and a “pull” model when replication is started in accordance with a state of the consumer directory server.
In the present description, replication in a “push” model is assumed.
Further, a time stamp is a numerical value based on a time point when the supplier directory server receives an update type directory access request, on a time point of a modify operation, or on a time point when a replication record is stored into the replication log file. Time stamps should be arranged in ascending order of performing modify operations.
FIG. 3
shows a replication sequence performed by the conventional replication server.
As shown in
FIG. 3
, the conventional replication server reads out a replication record (
31
) from the replication log file.
Successively, the replication server issues a bind request (
32
) to a consumer directory server, and receives a response (
33
) to it, which establishes a connection with the consumer directory server.
Successively, the replication server prepares an LDAP access request (
34
) based on the replication record (
31
) read out. In the following description, such an LDAP access request is called a “replication request”.
Then, the replication server issues the prepared replication request (
34
) to the consumer directory server, and receives a response (
35
) to it. When a return code included in this response (
35
) is “LDAP_SUCCESS” indicating success of the replication, the replication server records a replication status (
37
). Here, the time stamp of the successful replication record is stored into a replication status file.
The replication server always reads out the replication record having the oldest time stamp among replication records having time stamps subsequent to one stored in the replication status file, so that it can perform replication in the same order as the modify operations were performed by the supplier directory server.
Thereafter, the replication server issues an unbind request (
38
) to cut off the connection with the consumer directory server.
According to the above-described sequence, it is possible that the consumer directory server performs the same modify operations in the same order as ones perform
Hirashima Yoko
Kikuchi Satoshi
Yui Hitoshi
Antonelli Terry Stout & Kraus LLP
Black Thomas
Hitachi , Ltd.
Veillard Jacques
LandOfFree
Replication method does not yet have a rating. At this time, there are no reviews or comments for this patent.
If you have personal experience with Replication method, we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Replication method will most certainly appreciate the feedback.
Profile ID: LFUS-PAI-O-2609120