1. INFN Grid Information Services G. Lo Biondo INFN Milano (presented by F. Prelz)

2. As far as now… INFN runs a hierarchical GIS distributed among geographical INFN sites.

3. Bologna (LAN) GIIS dc=bo,dc=infn,dc=it,o=grid GIIS dc=mi,dc=infn,dc=it,o=grid Top Level INFN GIIS dc=infn,dc=it,o=grid Milano( LAN) GRIS Each site runs an Index server that registers itself to a top level INFN GIIS server

4. Still to do... Although the INFN GIS is up and running, it still lacks some production environment capabilities. –Some deployment issues can be addressed in a simple way. –Other issues are tied to the GIS LDAP based architectural model. They require a deeper analysis and must be faced in a context wider than the INFN-GRID project.

5. Still to do... Here is a short description of open issues in the current INFN GIS deployment: –Site Independence (Site functionality must not rely on higher lever services) –Service Reliability (Automatic failover mechanisms) –Service Distribution (Topological distribution of the service) –GRIS/GIIS Registration Mechanism.

6. Site Independence Each INFN site must be able to locate local resources independently of the root GIIS status. Anyway, it's only a matter of using the LDAP native referral mechanism properly.

7. Bologna (LAN) GIIS dc=bo, dc=infn,dc=it,o=grid GIIS dc=mi,dc=infn,dc=it,o=grid Top Level INFN GIIS ldap://mds.infn.it:389/ dc=infn,dc=it,o=grid Milano( LAN) GIS CLIENT Where is your parent? Try: ldap://mds.infn.it:389/dc=infn,dc=it,o=grid

8. Service Reliability Replication must be available at all tree levels to reduce service faults. Slapd replication or synchronization engines must be developed/deployed. A mechanism to automatically locate LDAP servers and replicas must be decided (a possibility is to use DNS SRV RRs or other DNS RRs)

9. Bologna (LAN) GIIS dc=bo, dc=infn,dc=it,o=grid GIIS dc=mi,dc=infn,dc=it,o=grid Top Level INFN GIIS dc=infn,dc=it,o=grid Milano( LAN) GIIS Top Level INFN GIIS Replication/ Synchronization engine Replication/ Synchronization engine

10. Architectural issues The LDAP based model of the Globus GIS has some advantages: –Standard Protocol and APIs –Standard Data Presentation Model –Existing software On the other hand the LDAP protocol is not the best provider for dynamic data. Though LDAP is a ready to use solution other IS models must be investigated.

11. Service Distribution The pull model (chaining) used for data publishing, in some circumstances is not the best approach. –On a large distributed GIS, searches affecting the whole resource collection can be dramatically slow. –We may want to push information to superior knowledge servers as the information changes. A mixed push/pull model is more suitable for real applications. A way to narrow searches must be investigated (indexing?)

12. Registration Mechanism Registrations sent from GRIS’s to a GIIS basically inform about the existence of a resource. Currently, registrations are completely anonymous meaning that everyone can register an host on a GIIS. Access to data is completely anonymous at all tree levels: this exposes “private” data, if any.

13. GIS Future As the GIS is a new, not well standardized Information Service, it is very important that the standardization process be coordinated both from the deployment and from the protocol specifications perspectives. This assumes a tightened collaboration between Grid projects to define and deploy a common GIS model.