Hi,

Il 03/06/2013 21:16, Peter Dietz ha scritto:
Hi Jessica / Nikolai,

I've been looking into a possibly related problem. We are planning on consolidating/moving DSpace instances. We want a single handle daemon that supports multiple handle prefixes, and supports multiple DSpace (and possibly non-DSpace) instances.
I have started to think about this too. Our need is very similar to the previous statement from Peter:
one single handle daemon -> multiple handle prefix

we have a semplification here, 1 dspace = 1 unique handle prefix. Handle prefix are not shared between different dspace so there are not issues related to collisions. My idea (we have not yet write any code) is to build a custom connector for the Handle daemon that replace the current out-of-box DSpace HandlePlugin
"storage_type" = "CUSTOM"
"storage_class" = "org.dspace.handle.HandlePlugin"

This connector should read a configuration file (or better a spring bean) that map handle prefix to different resolver. For the dspace instances I plan to write a simple servlet able to answer in JSON with the URL corresponding to the asked handle or N/A if the handle is not valid. So in first instance a single resolver able to query this JSON servlet is needed.

Helix: is your code able to manage my use case?

Any other considerations?
Andrea


My understanding is that the Global Handle Service (GHS) (i.e. hdl.handle.net <http://hdl.handle.net>) resolves requests to your Handle prefix by querying your Local Handle Service (LHS). Your LHS has to respond with a YES or a NO (that you have a specific handle or not), and if YES, then you also include an HTTP URL to redirect the handle to. The handle daemon packaged with DSpace connects to your instances DSpace Database, and basically just queries the handle table for the existence of a handle. I think you could look at the Handle system architecture,and you build a custom daemon, that knows how to query multiple local repositories to see which one has the asset.


For your problem of wanting to register a single handle prefix, and have multiple services use those handles, you run into a problem of needing to ensure that you don't have collisions with your services trying to assign the same number to different resources. You could either adjust the code for each service (DSpace) to have each one assign different ranges of handles. i.e. DSpace1 = 1..50000, DSpace 2 = 50001..99999

Or, since the right hand side of a handle is text, you could stuff another symbol in there. "1811/data-" for your repository that stores research data sets, 1811/video-" for video repository, and so on. Then you'll end up with 1811/data-1 to 1811/data-99999, and 1811/video-1 to 1811/video-99999. You prevent collisions, since each domain-specific repository would only use a specified middle-prefix.

You still need to solve the problem of your handle daemon knowing how to speak for multiple DSpace instances. I don't have any prototype solutions, but I hope this helps to guide your thinking.




Peter Dietz


On Mon, Jun 3, 2013 at 12:12 PM, nraanes <nraa...@gmail.com <mailto:nraa...@gmail.com>> wrote:

    Hi

    I'm also trying to figure out how to accomplish what Jessica asked
    (using
    one handle server for multiple DSpace instances).

    Would it be possible for you to share the "unofficial solution"
    once again?


    As this is my first post I would like to thank everyone on here.
    It's been a
    great resource while learning  DSpace!

    Regards,
    Nikolai



    --
    View this message in context:
    
http://dspace.2283337.n4.nabble.com/One-handle-server-for-two-DSpace-instances-tp4662743p4664577.html
    Sent from the DSpace - Tech mailing list archive at Nabble.com.

    
------------------------------------------------------------------------------
    Get 100% visibility into Java/.NET code with AppDynamics Lite
    It's a free troubleshooting tool designed for production
    Get down to code-level detail for bottlenecks, with <2% overhead.
    Download for free and get started troubleshooting in minutes.
    http://p.sf.net/sfu/appdyn_d2d_ap2
    _______________________________________________
    DSpace-tech mailing list
    DSpace-tech@lists.sourceforge.net
    <mailto:DSpace-tech@lists.sourceforge.net>
    https://lists.sourceforge.net/lists/listinfo/dspace-tech
    List Etiquette:
    https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette




------------------------------------------------------------------------------
How ServiceNow helps IT people transform IT departments:
1. A cloud service to automate IT design, transition and operations
2. Dashboards that offer high-level views of enterprise services
3. A single system of record for all IT processes
http://p.sf.net/sfu/servicenow-d2d-j


_______________________________________________
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette


--
Andrea Bollini
Dipartimento Servizi e Soluzioni per l'Amministrazione Universitaria
Divisione Ricerca

Via dei Tizii, 6
00185 Roma, Italy
tel. +39 06 44 486 087 - mob. +39 348 82 77 525
http://www.cineca.it

------------------------------------------------------------------------------
Get 100% visibility into Java/.NET code with AppDynamics Lite!
It's a free troubleshooting tool designed for production.
Get down to code-level detail for bottlenecks, with <2% overhead. 
Download for free and get started troubleshooting in minutes. 
http://pubads.g.doubleclick.net/gampad/clk?id=48897031&iu=/4140/ostg.clktrk
_______________________________________________
DSpace-tech mailing list
DSpace-tech@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/dspace-tech
List Etiquette: https://wiki.duraspace.org/display/DSPACE/Mailing+List+Etiquette

Reply via email to