External Handle Server SUpport
------------------------------
Key: DS-1171
URL: https://jira.duraspace.org/browse/DS-1171
Project: DSpace
Issue Type: Improvement
Components: DSpace API
Affects Versions: 3.0
Reporter: Robert Tansley
Assignee: Mark Diggory
Priority: Major
Attachments: handle-client-patch-20050825.txt.txt.gz
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:
http://wiki.dspace.org/ChinaDigitalMuseumProject
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.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators:
https://jira.duraspace.org/secure/ContactAdministrators!default.jspa
For more information on JIRA, see: http://www.atlassian.com/software/jira
------------------------------------------------------------------------------
Live Security Virtual Conference
Exclusive live event will cover all the ways today's security and
threat landscape has changed and how IT managers can respond. Discussions
will include endpoint security, mobile security and the latest in malware
threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/
_______________________________________________
Dspace-devel mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-devel
