Peter,
The way that the Handle service is designed in general, your always going
to need a separate "Handle Service" for "all the handles under one or more
prefixes".
For an organization, this could be a standalone service that maintains
mappings for prefixes (and subpaths in suffixes) it assigns to DSpace and
other applications, serving handles under the prefix to the various URL. IE
the standalone Handle service is such an implementation.
http://www.handle.net/download.html
As MarkW mentions, DSpace is currently doing this Bass Ackwards by
injecting itself as a plugin into the above system.
I'm not sure if https://jira.duraspace.org/browse/DS-1637 really meets the
design goal to split off the Handle service entirely from DSpace. It still
looks to be a plugin to the existing local handle server.
Problems with the local DSpace handle service that really need fixing...
1.) cannot mint under multiple prefixes and opaque unique suffixes with
their own naming conventions.
2.) doesn't implement caching/bulk replication API, so if DSpace is
offline, so is resolution via hdl.handle.net.
3.) DSpace conflates actual Handle with local identifier for
Item/Community/Collection
A HandleIdentifierProvider that remotely registers handles with an
organizational handle service would resolve both these issues. Looks like
MarkW already identified this as well...
https://jira.duraspace.org/browse/DS-2153
Regards,
Mark
On Fri, Nov 14, 2014 at 8:02 AM, Peter Dietz <[email protected]> wrote:
> Hi All,
>
> I've been reading up on the various configurations that you can run DSpace
> and the handle service in, and I was wondering if people would be willing
> to share their experiences with "non traditional" set ups.
>
> So, the out-of-the-box traditional setup, that I'm guessing 99% of us use
> is to run DSpace, and configure the start-handle-server to connect to
> DSpace using java (loads the dspace jars, gets access to DSpace API
> org.dspace.handle.HandlePlugin, tries to resolve the incoming request with
> that DSpace).
>
> So, for an upcoming project, imagine that someone wants to be able to take
> a collection OUT of DSpace, and put it into another application on their
> campus. If they wanted their handles to continue to resolve, the new
> application would need to speak handle, but the handle service would need
> to know how to resolve handles to multiple applications.
>
> I know there have been some enhancements to DSpace over the years, I was
> just wondering if anyone who had experience with them could share what is
> possible, or if there is work that still needs to be done in this area.
>
> One of the new enhancements to DSpace is to allow the handle service to be
> on an external server from DSpace:
> https://jira.duraspace.org/browse/DS-1637
>
> It adds some additional endpoints in XMLUI/JSPUI to respond in text, which
> an external handle service could use to resolve. Then the box that runs
> DSpace, can be properly firewalled, on a private IP address, and not have
> world accessible ports coming in. (Your external webserver, and external
> handle service would be public, but know how to internally connect to
> DSpace).
>
>
> So, some XMLUI endpoints, that external handle service could use to
> resolve:
>
> http://trydspace5.longsight.com/handleresolver/listprefixes
>
> ["123456789"]
>
> http://trydspace5.longsight.com/handleresolver/listhandles/123456789
>
>
> ["123456789/1","123456789/2","123456789/3","123456789/79","123456789/77","123456789/6","123456789/7"]
>
> http://trydspace5.longsight.com/handleresolver/resolve/123456789/79
>
> ["http://trydspace5.longsight.com/handle/123456789/79";]
>
>
> As far as I understand it. DSpace provides a route to allow a handle
> service to determine if DSpace contains that content. If you moved a
> collection from DSpaceA to repositoryX, you would need to have a handle
> service that knew how to lookup both DSpaceA and repositoryX to see if one
> of them can resolve that handle?
>
> And then another question along this same line. Say you have multiple
> applications on campus, and wanted each to be capable of minting handles,
> has anyone ever worked on a process to have each application contact this
> central handle resolver to ensure that the handle it wants to mint is
> available? I imagine this would be some type of transaction, to ensure that
> competition among consumer applications doesn't lead to a conflict. (Both
> apps ask if handle is in use, both hear no, each mints, each posts back to
> handle service that its has just minted it, and then, how to roll back, or
> handle that state). Ivan mentioned to me, that they just assign handle
> ranges to each application.
> i.e. DSpaceA = 0-(1M-1), DSpaceB = 1M-(2M-1)
> I suppose another route, would be to just use a UUID, and not worry about
> colliding. And then, another thing that I think would be possible, but I
> would need clarification is: handle prefixes with dots. Such as 1234.1 or
> 1234.thesis or 1234.dspace1. Are you allowed to claim an additional prefix
> with a dot, or do you have to ($) register that with the handle authority?
>
> Another thing I was just thinking, that instead of allocating million
> record chunks to each application, what if you prefixed your suffix, with
> the application that will be doing the minting? i.e. 1234/thesis-678,
> 1234/thesis-679, or 1234/a-678, or 1234/dspace1-678
>
> Another trick that I've just seen, not related to how handles will resolve
> inside your institution, but it appears that the CNRI handle authority now
> has an API to look at resolutions:
> http://hdl.handle.net/api/handles/10827/16924
>
> {"responseCode":1,"handle":"10827/16924","values":[{"index":100,"type":"URL","data":{"format":"string","value":"http://dc.statelibrary.sc.gov/handle/10827/16924"},"permissions":"1010","ttl":100,"timestamp":"1970-01-01T00:01:40Z"}]}
>
>
> So yes, apologies if this was lots of questions, but I'm thinking that
> since handles have been in use for so long, that people might be needing
> additional tools to help keep these identifiers persistent.
>
>
> ________________
> Peter Dietz
> Longsight
> www.longsight.com
> [email protected]
> p: 740-599-5005 x809
>
>
> ------------------------------------------------------------------------------
> Comprehensive Server Monitoring with Site24x7.
> Monitor 10 servers for $9/Month.
> Get alerted through email, SMS, voice calls or mobile push notifications.
> Take corrective actions from your mobile device.
>
> http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
> _______________________________________________
> DSpace-tech mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/dspace-tech
> List Etiquette:
> https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
>
--
[image: @mire Inc.]
*Mark Diggory*
*2888 Loker Avenue East, Suite 315, Carlsbad, CA. 92010*
*Esperantolaan 4, Heverlee 3001, Belgium*
http://www.atmire.com
------------------------------------------------------------------------------
Comprehensive Server Monitoring with Site24x7.
Monitor 10 servers for $9/Month.
Get alerted through email, SMS, voice calls or mobile push notifications.
Take corrective actions from your mobile device.
http://pubads.g.doubleclick.net/gampad/clk?id=154624111&iu=/4140/ostg.clktrk
_______________________________________________
DSpace-tech mailing list
[email protected]
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette
