EGEE User Forum

gLite Service Discovery for users and applications

1 Mar 2006, 18:30

1h

CERN

Poster contribution Poster session Poster and Demo session + cocktail

Speaker

Mr John Walk (RAL)

Description

In order to make use of the resources of a grid, to submit a job or query information for example, a user must contact a service that provides the capability, usually via a URL. Grid services themselves must often contact other services to do their work. In order to locate services, some kind of dynamic service directory is required and there exist several grid information systems, such as R-GMA and BDII, that can provide this service. However each information system has its own unique interface, so JRA1 have developed a standard Service Discovery API to hide these differences from applications that simply want to locate services that meet their criteria. The gLite Service Discovery API provides a standard interface to access service details published by information systems. There are four methods available for discovering services, these are: listServices, listAssociatedServices, listServicesByData and listServicesByHost. These all take a range of arguments for narrowing the search and all return a list of service structures. Once you have found a service it is then possible to use other methods to obtain more detailed information about it (using its unique id). These methods are: getService, getServiceDetails, getServiceData, getServiceDataItem, getServiceSite and getServiceWSDL. The gLite Service Discovery API provides interfaces for the Java and C/C++ programming languages and a command line tool (glite-sd-query). It uses plugins for the R-GMA and BDII information systems, and for retrieving the information from an XML file. Other plugins (e.g. UDDI) could be developed if needed. JRA1 also provide a service tool, rgma-servicetool, to allow any service running on a host to easily publish service data via R-GMA. All a service has to do is to provide a description file that contains static information about itself and the name of a command to call, plus any required parameters, in order to obtain the current state of the service. This information is then published via R-GMA to a number of tables that conform to the GLUE specification. The data published to these tables are used by the R-GMA gLite Service Discovery implementation. Any service, including VO services, can make use of rgma-servicetool. The existing system assumes that the underlying information system has been correctly configured. In the case of R-GMA this means that the client needs to know the local R-GMA server (sometimes known as a "Mon box"). A user coming to an unknown environment with a laptop needs to first find the information system before interacting with it. This is the well-known bootstrapping problem that can be solved by IP multicast techniques. We will provide discovery of local services without making use of existing information systems and with near-zero configuration. Clients send a multicast query to a multicast group and services that satisfy the query respond directly to the client using unicast. This capability will initially be added to R-GMA services. Once this has been done it will be possible to introduce additional R-GMA servers at a site, for example to take increased load, without the need to reconfigure any clients. The existing SD API with the R-GMA plugin will immediately benefit from the new server. Subsequently this component, suitably packaged, will be made available to other gLite services. The combination of the rgma-servicetool and the gLite Service Discovery makes it simple for any service to make itself known and then for user and high-level applications to find these services. In addition once the bootstrapping code is developed and added to R-GMA, the configuration of R-GMA, and thereby SD with the R-GMA plugin, will become trivial.