[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [Handle-info] Handle source code - compile / github
It sounds like you want API Gateway to receive calls from clients to resolve your handles, and pass to Lambda code which constructs the response. Is that correct?
In particular, you don't want a "handle resolver" in the sense of resolving other people's handles... you want a "handle server" in the sense that you want to respond to client requests to resolve *your* handles. Though your "server" will actually be a "serverless" application, its function is still to receive and respond to network requests. Let me know if I understand correctly.
In order for hdl.handle.net to be able to resolve your handles, you do need to support the RFC3652 Handle binary protocol. However, you can tunnel it over HTTP, so you might still be fine even if you can only support HTTP. The code in the Handle.Net software source that provides this functionality is NativeServlet, but I suspect you can with a little work decouple the request-processing logic from the servlet framework. NativeServlet.Handler.handle() does the work of reading the bytes of the request and writing the bytes of the response. The HTTP wrapping is pretty spare... you should set Content-Type: application/x-hdl-message on your response, and that will also be the Accept: and Content-Type: header on the requests you receive, but everything else is in the handle messages themselves. Now, you want to dispatch based on that Content-Type: header, not based on the URL---the URL will contain the percent-encoded handle, but that is ignored, and whenever you see that Content-Type: header you should just process the RFC3652 message in the HTTP request body instead.
RFC3652 is the documentation, but you should be able to copy and paste the logic from NativeServlet and other bits of the Handle.Net source code. The code in NativeServlet produces an AbstractRequest and needs to get from you an AbstractResponse. The only AbstractRequest you care about is ResolutionRequest. The only AbstractResponses you will need to construct are ResolutionResponse and ErrorResponse (for handle-not-found or values-not-found).
It is not necessary for hdl.handle.net resolution today, but you should also support the HTTP JSON API. It is documented in the Handle Technical Manual (https://www.handle.net/tech_manual/HN_Tech_Manual_8.pdf) and the relevant code is HandleJsonRestApiServlet.
You can run this on any port; port 8000 is typical for the HTTP interface of handle servers, but not mandated.
You will need to specify one or more IP addresses. It is not currently possible to use a DNS name. If you can not get the IP addresses that your API Gateway instance will use, you may need to run a single server instance to forward HTTP requests.
Interesting approach. Let us know more about how it goes.
Robert
> On May 26, 2016, at 11:59 AM, Peter Dietz <peter@longsight.com> wrote:
>
> Hi Robert,
>
> My goal, just to be clear, is to move running the handle proxy resolver off of our servers, and to instead be part of our serverless architecture, and run it on AWS Lambda (a runtime that runs a java (or node or python) function, infinitely scalable). Lambda does not have a webserver, you have to declare your url structure in API Gateway, and then map urls to lambda functions. As much as this sounds like a pain in the butt, its just a different paradigm, that once working, makes things much simpler. Instead of running a long running jvm instance with the handle daemon, just map some urls to functions that get spun up in demand to handle requests, resolve them, and spin down when not needed. We host multiple instances of DSpace, and already have a plugin that allows us to register multiple DSpace instances, which our code then queries its handleresolver listprefixes, adding it to a local registry, and then for incoming requests, it will check a certain prefix against the matching DSpace instance.
>
> So, I guess my question at this point. Is there documentation on all the url's that a handle proxy resolver needs to listen to, ports that need to be available, and what the data in and out need to look like? This architecture requires that the resolver and the webserver be completely decoupled. I've already gotten local code that works this way, pass parameters to a jvm instance for handles to resolve, and it returns the resolved handle. Our next step is just wiring this to the API gateway for data in / data out. Can you fully resolve using HTTP (JSON), or is the binary handle 2641 protocol still needed at times?
>
> Another question, does the global handle server registry require that you specify a single IP address, or is it possible to use a DNS name?
>
> ________________
> Peter Dietz
> Longsight
> www.longsight.com
> peter@longsight.com
> p: 740-599-5005 x809
>
> On Thu, May 19, 2016 at 1:43 PM, Robert Tupelo-Schneck <schneck@cnri.reston.va.us> wrote:
> The handle.jar code includes both handle server code and handle client ("resolver") code. If you just want handle client code, you can download a smaller library jar from http://handle.net/client_download.html .
>
> If you want a resolution service, you could download the "proxy servlet" from http://handle.net/proxy_servlet.html . It is a servlet but doesn't incorporate Jetty and can run in any servlet container. Perhaps you could adapt it to a non-servlet-based server environment.
>
> The JSON REST API is implemented by HandleJsonRestApiServlet; that is used by either the handle server or the proxy server.
>
> Now---are you saying you want to write a stripped-down minimal handle server? I suspect in that case you want to start with the proxy servlet code. In addition to the JSON REST API, you'll also have "NativeServlet" which accepts Handle-protocol requests tunneled over HTTP. Native handle clients (including hdl.handle.net) would then be able to talk to your server. In Handle parlance you'd have a handle site with a single HTTP interface.
>
> Let me know if that is helpful, and feel welcome to keep asking questions.
>
> Robert
>
> > On 2016-05-19, at 13:23, Peter Dietz <peter@longsight.com> wrote:
> >
> > Hi Robert,
> >
> > Thanks for that pointer, unpacking the src.zip in place provides the lib jars that got it to work, thanks. Once I got the ball rolling, I realized what all was needed, and am making progress. I was able to convert this locally to a gradle build project, pretty easy.
> >
> > My next question is, how married is the handle resolver to jetty (listening on network interface and ports) and all that? I just want to run the jvm with a resolver, but no servlets, no ports, no ip addresses being listened (something else, lambda, will do that). Perhaps a different way of phrasing this, is whats the minimum amount of handle logic that I could get away with, if I'm only providing handle resolution? Are handshakes and key exchanges necessary, or can I just run something that responds to incoming requests.
> > GET /handle/1234/5678 -> http://some.repository/handle/1234/5678
> >
> > The release notes mention something about REST + JSON, which opens the door to independent handle servers (my very simple code that returns simple handle resolution), but that isn't enough information for me to build something.
> >
> > Thanks.
> >
> > ________________
> > Peter Dietz
> > Longsight
> > www.longsight.com
> > peter@longsight.com
> > p: 740-599-5005 x809
> >
> > On Wed, May 18, 2016 at 4:18 PM, Robert R Tupelo-Schneck <schneck@cnri.reston.va.us> wrote:
> > Either unzip src.zip in place, or copy the entire "lib" directory structure from the distribution. Then you will have all the necessary dependencies, including cnriutil.jar which has net.cnri packages (the source for those is also included separately in src.zip).
> >
> > We have discussed dependency management / build frameworks and have not been moved to adopt Maven or Gradle for our own development. However, we do have an eventual goal of making the handle client library easily available to those who do use Maven and want to use the handle library.
> >
> > We have also discussed having our source on GitHub, and although some of us find that a very exciting option, it's not clear if or when it would actually be something CNRI would choose to do.
> >
> > Robert
> >
> > > On May 18, 2016, at 3:53 PM, Peter Dietz <peter@longsight.com> wrote:
> > >
> > > Long time handle user, first time trying to get my hands dirty and play with the code itself.
> > >
> > > 1) I'm having trouble getting the 8.1.1 code to compile. Here's what I've done so far:
> > >
> > > wget http://www.handle.net/hnr-source/hcj-8.1.1.tar.gz
> > > tar xzvf hcj-8.1.1.tar.gz
> > > cd dist/hcj-8.1.1/
> > > mkdir handle-library-8.1.1
> > > cp src.zip handle-library-8.1.1/
> > >
> > > cp src.zip handle-source-8.1.1
> > > cd handle-source-8.1.1
> > > ant
> > >
> > > BUILD FAILED
> > > /Users/peterdietz/Projects/handle/hsj-8.1.1/handle-8.1.1-source/build.xml:224: /Users/peterdietz/Projects/handle/hsj-8.1.1/handle-8.1.1-source/lib/jetty does not exist.
> > >
> > > Okay.. So then, I make that directory:
> > > mkdir -p lib/jetty
> > > ant
> > >
> > > util:
> > > [javac] Compiling 14 source files to /Users/peterdietz/Projects/handle/hsj-8.1.1/handle-8.1.1-source/build
> > > [javac] /Users/peterdietz/Projects/handle/hsj-8.1.1/handle-8.1.1-source/src/net/handle/util/DeepClone.java:16: error: package net.cnri.util does not exist
> > > [javac] public interface DeepClone extends net.cnri.util.DeepClone
> > >
> > > It looks like things are referencing net.cnri, which doesn't exist in my source tree. Maybe I'm missing some jar? I only see net.handle.*
> > >
> > > I feel like instead of packaging the jar dependencies yourself, using a dependency management tool would work better, i.e. maven/gradle. Also, maybe I've missed some documentation about how to build it yourself.
> > >
> > >
> > > 2) Is there a reason why the source code isn't somewhere accessible like GitHub? To get the library code, you have to get a tarball of the binary release, then unzip a src.zip file, and as I've mentioned above, is not working out of the box for me.
> > > (Sorry if this is a naive question, it seems pretty commonplace these days).
> > >
> > >
> > > Thanks in advance.
> > >
> > >
> > > ________________
> > > Peter Dietz
> > > Longsight
> > > www.longsight.com
> > > peter@longsight.com
> > > p: 740-599-5005 x809
> > > _______________________________________________
> > > Handle-Info mailing list
> > > Handle-Info@cnri.reston.va.us
> > > http://www.handle.net/mailman/listinfo/handle-info
> >
> >
>
>
_______________________________________________
Handle-Info mailing list
Handle-Info@cnri.reston.va.us
http://www.handle.net/mailman/listinfo/handle-info