This is a resurrection of the China Digital Museum External Handle Server Support from the corresponding SF Tracker issue.
This patch enables a DSpace site to connect to a remote Handle Server, and create new Handle records in that server. That remote Handle Server can then deal with resolution requests.
Developed as part of the China Digital Museum project:
Modifications by Wang Shu (Sandy) of Beihang University and Robert Tansley of HP Labs. Thanks also due to Jane Euler, Larry Lannom, Henry Herez and others at CNRI.
This is probably preferable if you have a Handle Server to hand, as it will give you more flexibility later on to move content identified by individual Handles or groups of Handles around.
You will need:
- A dedicated prefix for the DSpace site. This can be a 'sub-prefix'; for example 1721.1 and 1721.3 are sub-prefices of 1721.
This is because the Handle System and protocol does not actually define Handle generation functionality, so the full Handle will need to be generated locally by the DSpace instance in a way that will not clash with those created anywhere else.
- A functioning Handle Server, registered up as the 'home' for your prefix. If your organisation has an existing prefix, a sub-prefix can easily be set up for your DSpace instance. Your
organisation's Handle Server will need to be registered as the 'home' for that prefix too.
- An 'admin' Handle on that Handle Server, which your DSpace will use to authenticate in order to create Handle records. Note that currently, only secret key authentication is supported by the DSpace client.
For example you could create a Handle for a sub-prefix 1234.5678/ADMIN containing data:
Index Type Data
300 HS_SECKEY mypassphrase
Obviously, the HS_SECKEY should not be publicly readable!
- To set up the corresponding configuration parameters in dspace.cfg:
handle.remote = true
handle.auth.handle = 1234.5678/ADMIN
handle.auth.index = 300
handle.auth.passphrase = mypassphrase
Your DSpace should then register all new Handles in the remote Handle server.
There are a few caveats to note, which should be fixed over time:
- Every time a Handle is generated/created, a separate Handle request is sent synchronously. There is no session support yet. Also, if the Handle creation request fails because of network problems/Handle Server downtime, the whole transaction will fail. Presently there is no support for queueing Handles to be created asynchronously.
This should be fine for general user submission use, but may slow down batch imports.
- Handle request failures are reported as SQLExceptions. This is not really 'correct' and does not give ideal error reporting to the user. However it's done this way because currently, in general, upstream code knows what to do with SQLExceptions.
- Each Handle request may cause the Handle client to attempt to contact the Global Handle Server to get pointed at the appropriate Local Handle Server. This clearly isn't very efficient and introduces more potential points of failure. One way to alleviate this is to tell the Handle client code to go straight to your organisation's Handle Server. This is done by copying the server's siteinfo.bin file to ~/.handle/resolver_site where ~ is the home directory of the dspace user.
- Actually a general limitation: When a new Handle is generated, the primary key of the 'handle' table in the database is used to generate the actual Handle. If one imports items with
supplied Handles, problems occur. If the imported Handles have other prefices, the only side-effect is that the sequence of Handle suffices is broken. If you import an item with an
existing Handle that has your prefix, however, you definitely get problems.
In fact, any sort of backup/restore may end up breaking the correlation between handle_id and the Handle suffix, which would break the current generation algorithm. Longer term, we need a more robust generation algorithm, for example a new, dedicated sequence in the database.