[Go-essp-tech] [esg-node-dev] Re: [esg-gateway-dev] Upcoming gateway/datanode coordination points

Cinquini, Luca (3880) Luca.Cinquini at jpl.nasa.gov
Wed Mar 16 04:30:40 MDT 2011


Hi Chris,
	the ESGF Registry contains service and configuration information, no metadata about datasets. It is how an ESGF Node exposes its services endpoints such as Attribute Service, Authorization Service, MyProxy etc, it includes the certificates of the trustecCAs, and it will also have to contain federation-wide information like access control policies. The information is intrinsically encoded in XML conforming to some XSD, but there is still some debate on what is the best way to query it - hessian or rest. More information, including example document, can be found here: http://www.esgf.org/wiki/FederationRegistry

The REST interface was indeed proposed a long time ago and remains a goal - not sure it can be implemented within a few weeks including all other priorities in ESGF. But we could certainly meet to discuss.

thanks, Luca


On Mar 15, 2011, at 10:41 PM, Mattmann, Chris A (388J) wrote:

> Hey Guys,
> 
> Just wondering: what registry APIs are you guys talking about? What types of information does it store? Is it a registry of services, or a data registry?
> 
> Thanks!
> 
> Cheers,
> Chris
> 
> On Mar 15, 2011, at 8:35 PM, Rachana Ananthakrishnan wrote:
> 
>> Hi,
>> 
>> I have had multiple off-list requests for the registry service information, and seconding the request from Nate here. The work Neill and I did was to define the schema and information model, and had a proposal for a central location to push this and a simple HTTPS download of all the registered nodes. But Gavin has proposed a solution that has a tighter integration with the data node manager, and is working on that. I agree it would be a good point for us to review the service interface and protocol, and look at integration concerns.
>> 
>> I agree on the REST API for this, and there was suggestions about this earlier in other discussions. But I think in interest of time, and the existence of other Hessian services/libraries, this approach was preferred for now. 
>> 
>> Thanks,
>> Rachana
>> 
>> On Mar 15, 2011, at 10:24 PM, Nathan Wilhelmi wrote:
>> 
>>> Hi All,
>>> 
>>> Looks like we are coming up on a couple of feature points that may 
>>> require some coordination between gateway and datanode versions.
>>> 
>>> Metrics integration: We are working on this now with a target of having 
>>> it available for the 1.3 gateway release. What version of the datanode 
>>> is required to expose the AccesslogClientService? For a typical datanode 
>>> is this service always configured? This would also be a bump on the 
>>> request for information on how to setup this component up on our systems.
>>> 
>>> Federation Registry: It's not clear if this has to be a tightly 
>>> coordinated release chain or not. Perhaps this would be a good point to 
>>> take a group look at the proposed service? This isn't in production yet 
>>> so it would be much easier to make any desired changes now rather than 
>>> after the fact.
>>> 
>>> I would like to raise up the intended protocol for the registry service. 
>>> Gavin, at the previous GO-ESSP telco you indicated using hessian for the 
>>> protocol. This seems like this would be a great place to use a rest 
>>> service rather than hessian. Conceptually is should be pretty simple to 
>>> do as a rest service:
>>> 
>>> * nodes post their node configuration to the service
>>> * nodes get the registry information from the service. This could range 
>>> from a simple give me everything request to very specific queries.
>>> 
>>> Going the rest route seems like it would be much simpler from a few 
>>> aspects. No interfaces to distribute, simple API, don't necessarily need 
>>> a client, easily accessible as no limitation on Hessian library support, 
>>> etc...
>>> 
>>> Note: I would would like to see the Hessian APIs in the gateway replaced 
>>> with rest based APIs as well.
>>> 
>>> It would also be really helpful if we could see the intended API for the 
>>> client side of the registry service regardless of protocol.
>>> 
>>> 
>>> Thanks!
>>> -Nate
>>> _______________________________________________
>>> esg-gateway-dev mailing list
>>> esg-gateway-dev at mailman.earthsystemgrid.org
>>> http://mailman.earthsystemgrid.org/mailman/listinfo/esg-gateway-dev
>> 
>> Rachana Ananthakrishnan
>> Argonne National Lab | University of Chicago
>> 
>> _______________________________________________
>> GO-ESSP-TECH mailing list
>> GO-ESSP-TECH at ucar.edu
>> http://mailman.ucar.edu/mailman/listinfo/go-essp-tech
> 
> 
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Chris Mattmann, Ph.D.
> Senior Computer Scientist
> NASA Jet Propulsion Laboratory Pasadena, CA 91109 USA
> Office: 171-266B, Mailstop: 171-246
> Email: chris.a.mattmann at nasa.gov
> WWW:   http://sunset.usc.edu/~mattmann/
> Phone: +1 (818) 354-8810
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> Adjunct Assistant Professor, Computer Science Department
> University of Southern California, Los Angeles, CA 90089 USA
> ++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++
> 
> 



More information about the GO-ESSP-TECH mailing list