1. Towards an Integrated Information system: the EMI view
Balázs Kónya (Lund University)
8th EGI-TCB, 29 September 2011

2. disclaimer The slides were prepared on a very short notice
Information area consolidation plan within EMI is not finalised yet
Expected by end October
EMI delivers building blocks, operation and deployment is not in our hand
8th EGI-TCB

3. Where are we? Glite “world” ARC “world”
Resource BDII (LDAP, glue 1.x, 2)
Site, Top BDII (LDAP, glue 1.x 2)
GOCDB, non-EMI
ARC “world”
ARIS (LDAP and XML, nordugrid, glue 1.2, 2)
EGIS (LDAP, propriatery schema)
ISIS (“SOAP”, propriatery schema), non-EMI
UNICORE “world”
CIP (WSRF, XML, glue 2)
UNICORE Registry (WSRF, XML, propriatery schema)
8th EGI-TCB

4. Where are we? No common way to obtain
Service/resource information
Discover existing services
A client must talk different protocols and contact different services
No common “service” to store service information
A service must register to different indices
A service must publish different “records”
No common information backbone
No common grid! (or DCI :)
8th EGI-TCB

5. Where do we want to go? Consolidation on two levels: Resource level
Resource BDII, ARIS, CIP
Index level
Site/Top BDII, GOCDB, EGIS, ISIS, U. Registry
8th EGI-TCB

6. Resource-level consolidation
EMI Resource Information Service (ERIS)
EMI expert group proposal (recently approved by EMI PTB):
“The Task force has considered the options and on balance recommends that the ERIS should provide an LDAPv3 interface to GLUE 2.0 information. Information providers, in the classic sense, will extract information from the underlaying Grid service and produce GLUE 2.0 information in the LDIF format. These two together represent the external and internal interfaces for the ERIS. It is envisioned that this approach will be a minimal-cost solution for EMI and will have a low-impact on existing infrastructures.”
The ERIS service/product does not exist, however
Both glite and arc has very similar product in production
ERIS is basically an “LDAP server” with the right wrapper
UNICORE will use translators or JAVA-based ldap server
8th EGI-TCB

7. Index-level consolidation (1/3)
EMI service Registry (EMIR)
A new index service
To store service registration records of all EMI services (glite, ARC, UNICORE, dCache)
Some real records from the testbed: ml
Offer support for “federations”
Offer a common entry point for service discovery
GLUE2-based service record
Minimal information, mostly about the “existance” of a service
A clean REST-ful interface:
To add, update and remove records
To query service registration records
ARGUS-based Access control
8th EGI-TCB

8. Index-level consolidation (2/3)
EMIR: status
Prototype exists
A testbed with few instances is available
Some UNICORE and ARC services are already able to register to the Index
Most critical not-yet completed feature: ARGUS-based acces control
Prototype ready for EGI inspection will be out as part of the EMI Matterhorn release
Tech documentation is comming soon
Until then you may use the internal (!) wiki:
8th EGI-TCB

9. Index-level consolidation (3/3)
Integrating EMIR with EMI components
All EMI services will send registration records to EMIR
“Information consumers” (different clients and services) will perform service discovery using EMIR
EMIR and the ARC infosys indices:
EMIR will eventually replace them
EMIR and the UNICORE Registry:
EMIR will eventually replace it
EMIR and the BDIIS:
TOP BDII will contact EMIR to discover the site BDIIs
similarly, the site-BDII will contact EMIR to discover the ERIS of different services.
EMIR and the GOCDB:
The GOC DB is a service catalogue that is maintained manaully
The GOC DB could poulate the service catalouge by queriying the EMIR
GOC DB could benefit from the federation support of EMIR too
8th EGI-TCB