Re: [Handle-info] Web Services for Handle Servers

[Giridhar Manepalli <gmanepalli@cnri.reston.va.us>]

Hello,
The requirements stated by Colin, in my opinion, justifies the need for 
web services in the Handle System. Although it looks obvious what the 
definitive services would/should be in a Handle System web service 
framework, there are some important things to consider before attempting 
the design of such framework. Specifically, it is crucial to understand 
the options available to us for such a design, and these options are 
stated below. I am hoping that this would throw light on necessary 
design issues and therefore would help us in the longer run.

(1) Web Services Proxy
The services provided by the web services proxy are inclined toward 
resolution services, just on the lines of HTTP based Handle Proxy. 
Providing resolution service at this level has two major advantages
(a) The local handle servers need not host the web services themselves. 
Yet, the clients will be able to use the resolution services from this 
web services proxy.
(b) The clients may assume a default web service endpoint and therefore 
need not burden themselves for discovering the local handle server 
enpoint addresses.

CNRI has designed (and implemented) the web services at the proxy level. 
It is being tested internally and is expected to be released (and 
hosted) in the near future.

(2) Handle Server Web Services
Although the word 'local' pops up in our mind when thinking of 
implementing exhaustive services including administration and resolution 
of handles, it is misleading in the sense that there are two ways in 
which we can design such web services.
The web services framework may itself be hosted on a different location 
(to the local handle server) and talk to the handle server using Handle 
Protocol. This implies that the web services themselves (as seen by the 
clients) are made Handle Protocol independent.
Advantages include
(a) A change in the Handle Protocol (it may never happen), will never 
force a change in the web service definitions itself.
(b) Decoupling of clients perception of Handle services and the Handle 
Protocol.
Disadvantages
(a) Since there is an extra layer of delegation added, the services 
themselves will exhibit some latency. (This may not be an issue to many).

It is appropriate for third-party developers to follow this route since 
it does not demand the spot-on understanding of Handle Protocol.

(3) Local Handle Server Web Services
At this level, the web services themselves implement the Handle 
Protocol. The big difference between present day protocol and this model 
is the encoding of message on the wire to a Handle Server.
Advantages include
(a) The web services will be on a performant side when compared to 
previous option.

CNRI has designed the web services at this level. If the need for web 
services at this level is thought out to be appropriate/important, I see 
no reason why we cannot leverage on the design already done. For 
third-parties to develop web services however, it might challenge their 
knowledge in the Handle Protocol.

Hoping to see lots of traffic on this!

--
Giridhar Manepalli
Senior Software Engineer
Corporation for National Research Initiatives
Phone: (703) 262-5340


Colin Alteveer wrote:

> Dear Handle Users,
>
> Here at the Academic ADL Co-Lab we have been contemplating an 
> automated approach to Handle registration. After meeting with Henry 
> Jerez and Sean Reilly (CNRI), we have all decided it would be best to 
> start a working group of sorts to discuss existing implementations, 
> goals, and the best practice for programmatically creating/registering 
> Handles with our local Handle servers.
>
> _A Little Background_
>
> The main impetus for this functionality is our proof of concept work 
> on the ADL-R project. As opposed to having the local handle 
> administrator manually register every new handle, we would very much 
> like it to be an automated step in the publishing workflow of our 
> repository implementation. There are currently two client libraries 
> for HANDLE.NET, one written in Java and one in C. This poses a problem 
> for us because our repository is written in neither (it is written in 
> python), and even though there is a possibility of calling portions of 
> the C library, this isn’t the most attractive or elegant approach. It 
> was thus tentatively agreed that perhaps an interface via web services 
> would be a better idea seeing as it is flexible and possible to 
> implement in many languages on the client side.
>
> _Requirements_
>
> Our proposed solution has the following requirements; client side 
> platform/language independence via *1)* a web services API for 
> authenticating and creating sessions for admins/users of the handle 
> server, and *2)* a web services API to the administrative functions of 
> the handle server.
>
> If any of this interests you, or you have implementations you would 
> like to share please let Henry or I know you are interested in joining 
> the working group.
>
> Colin Alteveer
>
> Academic ADL Co-Lab
>
> calteveer@academiccolab.org <mailto:calteveer@academiccolab.org>

begin:vcard
fn:Giridhar Manepalli
n:Manepalli;Giridhar
org:Corporation for National Research Initiatives
adr:Suite 100;;1895 Preston White Drive;Reston;VA;20191;USA
email;internet:gmanepalli@cnri.reston.va.us
title:Senior Software Engineer
tel;work:(703) 262-5340
tel;fax:(703) 620-0913
x-mozilla-html:FALSE
url:http://www.cnri.reston.va.us/
version:2.1
end:vcard