Achieving eventual leader election in WS-discovery

The Devices Profile for Web Services (DPWS) provides the foundation for seamless deployment, autonomous configuration, and joint operation for various computing devices in environments ranging from simple personal multimedia setups and home automation to complex industrial equipment and large data centers. In particular, WS-Discovery provides dynamic rendezvous for clients and services embodied in such devices. Unfortunately, failure detection implicit in this standard is very limited, both by embodying static timing assumptions and by omitting liveness monitoring, leading to undesirable situations in demanding application scenarios. In this paper we identify these undesirable outcomes and propose an extension of WS-Discovery that allows failure detection to achieve eventual leader election, thus preventing them. I. DPWS AND WS-DISCOVERY Th OASIS Devices Profile for Web Services (DPWS) standard [1] specifies a minimal set of requirements that a Web Service implementation must comply with to provide secure messaging, dynamic discovery and description, and simple event notification. Its goal is to bring Service Oriented Computing (SOC) to devices such as small sensors and common appliances, without constraining the behavior and features of richer service implementations on more powerful devices. As protocols and standards that meet these goals for Web Services already exist, this profile defines some constraints and adaptations for their applicability in resourceconstrained machines. In particular, DPWS is interesting as the base for self-configurable data centers by building it in management consoles that exist in server hardware. DPWS builds on standard Web Services concepts of Client and Message and introduces the definition of a Device and Hosted Service. A Device, also known as Hosting Service, handles Messages specifically belonging to the standards comprising DPWS, for discovery and description. A Hosted Service handles application specific messages and can be addressed directly, i.e., without encapsulation. A core feature of the DPWS Hosting Service is compliance with WS-Discovery [2], which allows services to be located dynamically. Briefly, it assumes that (i) services send an announcement when joining or leaving the network in order to minimize the need for polling and repeated searches; and that (ii) Clients can probe for services by type or scope and resolve a service by name. It provides various modes of operation, depending on the availability of a Discovery Proxy and to adapt to different scale and resource availability scenarios. In the Ad-Hoc Mode, entities on the network should make no assumption on the existence of a Discovery Proxy. Hence, discovery messages are multicast to the entire network while responses are unicast to the inquiring entity. In Managed Mode, every Target Service and Client must know the address of a Discovery Proxy to enable successful discovery using unicast messages exchanges. Consequently, discovery messages are unicast to a Discovery Proxy, which also responds through unicast messages to the enquiring entity. The way that different entities become aware of the Discovery Proxy can be made through different means, such as explicit configuration or even dinamic discovery of the d:DiscoveryProxy type itself. This last option paves the way for dynamic mode switching. The Discovery Proxy continuously listens to the well known WS-Discovery multicast group in order to capture any Hello and Bye messages from other Target Services, in order to store or update information on them, and Probe and Resolve messages from Clients looking for other Target Services, to whom the Proxy sends a unicast Hello message. This configuration option is clearly the most desirable. The use of a Discovery Proxy reduces the amount of messages that are multicast, thus reducing network and Device resources consumed in scenarios with large number of Devices. By dinamically discovering the Discovery Proxy itself, it avoids the need for a centralized a priori configuration, that defeats the purpose of WS-Discovery. Unfortunately, as we describe in Section II coping with failure of Service, and in particular of the Discovery Proxy, according to the standard is much less graceful than startup and discovery, as there is no provision for liveness monitoring or operation of multiple Proxies concurrently. We address this in Section III by introducing a small set of changes that allows for eventual leader election, thus providing the key building block on which arbitrary services can provide stability guarantees.