ESGF_Registry

Wiki Reorganisation
This page has been classified for reorganisation. It has been given the category REVISE.
This page contains useful content but needs revision. It may contain out of date or inaccurate content.

The ESGF P2P Registry

Registry

The ESGF peer-to-peer registry is a component of the ESGF P2P Node Manager. The central task of the registry is to provide federation wide information about nodes in a completely decentralized way. The Registry makes use of an anti-entropy gossip protocol for maintaining (eventually) consistent federation membership state. It runs as a _ component _ of the Node Manager. The Node Manager's service consumes _ remote events _ and dispatches them through it's FSM (Finite State Machine) arrangement of components. Remote events containing registration _ payload _ are transitioned to the Registry component. The Registry component receives the events and then transitions events through to the next _ component _ in the Node Manager's FSM of components.

Node Manager Service Component

_ (receiver/dispatcher) _

• The service interface: The Node manager runs a single service that receives RemoteEvents and wraps them in local _ events _ that is then undergoes state transitions as it traverses the FSM and then released as a RemoteEvent to the next peer. The Node Manager is an event based architecture built to support bother intra and inter node communication. Events are propagated and routed throughout the federation seamlessly. The interface for the Node Manager consists entirely of two methods.

  boolean ping();
  void handleESGRemoteEvent(ESGRemoteEvent evt);
  

Registry Component

_ (state) _

• The registry component itself, inspects the payload information that describes the state of the upstream peer. This information is codified in an xml document called "registration.xml". This document lives on each node in the specific location under the node manager's application root. (Ex: http://esgf-node3.llnl.gov/esgf-node-manager/registration.xml )

Remote Event

_ (transport) _ The remote event encapsulates the salient features necessary for inter node transport.

    String getOrigin()
    String getSource()
    int    getMessageType()
    Object getPayload()
    String getPayloadChecksum()
    long   getSeqNum()
    int    getTTL()

    void decTTL()
    boolean checkTTL()
    boolean isValid()
    int copyTTLFrom(ESGRemoteEvent otherEvent)

Registration Schema

_ (payload) _

• As we have described the RemoteEvent object is only concerned with the transport level information of peer to peer interactions. However they do carry _ payload _ , which is where the semantic information is stored. The payload is the semantic data that is being shepherded through the system cloaked inside of RemoteEvents . For registration in particular the payload is an xml document that follows a specific xml schema, shown below.

http://rainbow.llnl.gov/dist/devel/esgf-node-manager/registration.xsd

...
    <xsd:attributeGroup name="ResourceAttributes">
        <!-- Name of organization -->
        <xsd:attribute name="organization" type="xsd:string" use="required"/>
        <!-- Oragnization namespace org.esgf.badc, etc -->
        <xsd:attribute name="namespace" type="xsd:string" use="required"/>
        <!-- Address to send requests to -->
        <xsd:attribute name="supportEmail" type="xsd:string"/>
        <!-- Hostname, full domain name, and unique identifier -->
        <xsd:attribute name="hostname" type="xsd:string" use="required"/>
        <!-- Host Certificate DN, will be used as default identity for all services,
        unless overridden by the DN attribute in the service -->
        <xsd:attribute name="dn" type="xsd:string" use="required"/>

        <xsd:attribute name="shortName" type="xsd:string" use="required"/>
        <xsd:attribute name="longName" type="xsd:string"/>
        <xsd:attribute name="timeStamp" type="xsd:long" use="required"/>
        <xsd:attribute name="version" type="xsd:string" use="required"/>
        <xsd:attribute name="release" type="xsd:string"/>
        <xsd:attribute name="nodeType" type="xsd:string"/>
        <xsd:attribute name="adminPeer" type="xsd:string"/>
        <xsd:attribute name="defaultPeer" type="xsd:string" use="required"/>
    </xsd:attributeGroup>


    <xsd:complexType name="Node">
        <xsd:all>
            <xsd:element ref="tns:CA" minOccurs="0" maxOccurs="1"/>
            <xsd:element ref="tns:NodeManager" minOccurs="0" maxOccurs="1"/>
            <xsd:element ref="tns:OpenIDProvider" minOccurs="0" maxOccurs="1"/>
            <xsd:element ref="tns:FrontEnd" minOccurs="0" maxOccurs="1"/>
            <xsd:element ref="tns:IndexService" minOccurs="0" maxOccurs="1"/>
            <xsd:element ref="tns:AttributeService" minOccurs="0" maxOccurs="1"/>
            <xsd:element ref="tns:AuthorizationService" minOccurs="0" maxOccurs="1"/>
            <xsd:element ref="tns:OAIRepository" minOccurs="0" maxOccurs="1"/>
            <xsd:element ref="tns:ThreddsService" minOccurs="0" maxOccurs="1"/>
            <xsd:element ref="tns:GridFTPService" minOccurs="0" maxOccurs="1"/>
            <xsd:element ref="tns:MetricsService" minOccurs="0" maxOccurs="1"/>
            <xsd:element ref="tns:LASService" minOccurs="0" maxOccurs="1"/>
            <xsd:element ref="tns:MyProxyService" minOccurs="0" maxOccurs="1"/>
            <xsd:element ref="tns:PublishingService" minOccurs="0" maxOccurs="1"/>
            <xsd:element ref="tns:RelyingPartyService" minOccurs="0" maxOccurs="1"/>
            <xsd:element ref="tns:PEMCert" minOccurs="0" maxOccurs="1"/>
        </xsd:all>
        <xsd:attributeGroup ref="tns:ResourceAttributes"/>
    </xsd:complexType>
...

This document is parsed, its information is then merged into the local node's state. The new state, resulting from the merge, is pushed to the next peer following the event driven architecture.