Speaker
URL
https://twiki.cern.ch/twiki/bin/view/EMI/EMIRegistry
Overview (For the conference guide)
The European Middleware Initiative(EMI) is a European project that represents a collaboration of four middlewares namely ARC,dCache,gLite,and UNICORE.All these middleware services should be easily deployable in a DCI.However the immediate challenge is the discovery of those services in a particular DCI that is typically done via so-called registries.This is a major requirement for operational systems,and the middleware itself.Existing registries such as ARC Information Index or UNICORE registry are designed to index middleware specific services.Given the centralized nature,the scope of these registries can become limited when considering a federated infrastructure that relies on service of different technology providers.DCIs such as EGI are federated in nature,thus a unified registry should reflect this requirement.In this contribution,a new unified registry EMIR is proposed,which attempts to overcome the challenges of federation,robustness and performance implications of today's DCIs.
Description of the Work
EMI aims at providing a unified software bundle to Distributed Computing Infrastructures (DCI). The bundle contains all of the software and services which a DCI would need to exploit the infrastructure resources. Despite of being unified, the services publish and register their information to the platform or middleware specific service registries; for example ARC job submission service should be registered to the ARC information system before being discovered by the submission client, likewise for the UNICORE and gLite. Having multiplicity of such registries implies proprietary protocols and interfaces which may enforce the client to either setup all the registries before allowing the clients to use the infrastructure or reduces the scope of offering to limited number of middleware services. Considering the problems, EMI developed a unified, but federated service registry “EMIR”, which offers a common interface to publish and discover all the services under the spectrum of EMI. The interface of the registry is a Web service based on REST using Java Script Object Notation (JSON) during the message exchange, whereby HTTP URIs methods are exposed to interact with the service indexes. In addition to the common interface, the registry offers federation and global tier P2P based replication for robustness and scalability to match the current trends of DCIs. The information model of the registry adopts a subset of the GLUE 2.0 model – which we call “Service Endpoint Model”, for that a new JSON rendering has been derived to create the service descriptions in articulated manner. A fine grained and standardized authentication and access control mechanisms such as X.509 and XACML have been provided to cope with the emerging security requirements and compatibility with the EMI based infrastructures.
Impact
The EMIR can be seen as instrumental in unifying the service discovery of all the EMI services in modern large scale computing infrastructures (e.g. EGI, NGIs). Having REST interfaces enables the services (and their providers) to intuitively advertise the reference/endpoint information. The adoption of the OGF GLUE2 standard facilitates the process of publishing middleware specific services to the EMIR. A generic but highly configurable EMIR client has been implemented for middleware agnostic service publishing, thus offering a way for any remote service to be indexed and discoverable. Enabling federations is a norm in current DCIs, therefore right from EMIR’s inception federation was one of the intrinsic parts of the design and therefore strongly supported. Furthermore, the global tier replication at the global registries enables the service discovery on global level but in decentralized and robust manner. The feature set offered by EMIR benefits not only the operations personnel but increases efficiency of the overall functioning of a DCI.
Conclusions
While considering the amount of multifarious services offered by EMI, we can conclude that a common and unified services’ registry is indispensable. The EMIR offers service publishing with following two options:
• Publishing Client: A configurable daemon which publishes the service endpoint information on the behalf of service provider in a periodic fashion.
• REST API: It is a most option available, in which the service providers (or middlewares) use the API to publish their service’s information according to their own requirements
The first prototype release is scheduled for EMI 2, this would give an opportunity for the infrastructure operators and service providers to test the registry.
