Introduction to pervasive service discovery

Interoperability is important not only between the different networks in a coalition force, but also between all the operational levels used within a nation. This means that we must be able to discover Web services across different networks in a coherent manner, i.e., we need support for pervasive service discovery. Furthermore, we must solve pervasive discovery in a manner that can function in a federation of systems, which is an important premise from our requirements analysis (see Section 3.5). This is illustrated in Figure 6.1.

Zhu et al. [146] state that:

Existing protocols have various design goals and solutions. Each has its advantages and disadvantages in different situations, so it seems unlikely that a single protocol could dominate in pervasive computing environments. With current protocols, this means clients and services can’t discover each other if they don’t use a common protocol. We

Figure 6.1: Pervasive service discovery in a federation of systems. Here two different networks are interconnected, and clients in one network should be able to discover and invoke services in the other. To achieve interoperability, both networks could use the same discovery mechanism. However, this may not be possible due to policy or hardware limitations. Thus, we must find a means of achieving interoperability between discovery mechanismsAandBwhich is suitable in a federation of systems (here illustrated by administrative domainsXandY).

should therefore establish a common platform to enable interoperability among service discovery protocols.

Thus, after we find a protocol (or set of protocols) to use in the different military networks, we need to find a means of interconnecting the service discovery mechanisms across the heterogeneous networks.

6.2 Related work

As we have seen in Chapter 5, existing discovery protocols are very diverse, and different networks require different protocols. This means that there is a need for pervasive service discovery. In recent years, several experimental solutions have appeared which attempt to address the challenge of service discovery across different network domains. Lacking a standardized solution, we explore which solutions the research community has identified:

Some protocols are adaptive and can be used in different domains simultaneously. A design for such an adaptive protocol is discussed by Gagnes et al. in [47] and [46]. Bethea et al. [13] investigate the use of ontology-based reasoning for the purpose of developing a general service discovery capability in multi-provider tactical networks.

Another approach involves creating a layered structure that can allow different legacy protocols to coexist by adding a service discovery abstraction layer above the others [18]. Raverdy et al. [111]

have implemented MUSDAC, a middleware platform addressing the lack of interoperability between existing discovery protocols in a pervasive environment. MUSDAC achieves service

(a) Adaptive service discovery

(b) Layered service discovery

(c) Service discovery gateways

Figure 6.2: The three ways of achieving pervasive service discovery

discovery interoperability through "manager" and "bridge" components: A manager handles discovery requests within the network for local clients. Service discovery plugins implement specific service discovery protocols, and connect to the manager which forms an abstraction layer above the plugins. Finally, bridges assist the manager in expanding service discovery to other networks, by forwarding data to corresponding managers there.

It is also possible to implement service discovery gateways to support transparent interoperability between different protocols. Allard et al. [2] create a gateway which allows Jini clients to use UPnP services and UPnP clients to use Jini services transparently and without modification to service or client implementations. A similar suggestion is that of Kang et al. [74], who present an architecture to provide simple interoperability among various service discovery protocols using a dynamic service proxy. Gateways are considered more efficient than a layered architecture, and also make it possible to use legacy client applications and services unmodified in the network [18].

6.2.1 Classifying the approaches

We can classify the different ways of achieving pervasive service discovery in these three categories that we discovered in the literature review:

1. Adaptive service discovery, meaning that one single service discovery protocol is used across all network domains. The chosen protocol must be able to adapt its behavior according to the limitations and capabilities of each underlying network. All applications in the network must be able to interact with this protocol. Going from a network with high capacity to a network with low capacity, a filter is needed that discards excess information. This is illustrated in Figure 6.2(a).

2. Layered service discovery, meaning that each network domain can use a dedicated protocol, but an overlaying protocol controls and connects the different service discovery protocols.

Here, a network local protocol is translated to the abstraction layer model and offered to the client (e.g., MUSDAC’s manager). Interoperability across networks is handled by the abstraction layer, in that it can disseminate its model to other instances in other networks (e.g., MUSDAC’s bridge). This case is shown in Figure 6.2(b).

3. Service discovery gateways. Using this method, each network domain can choose the most suitable protocol, and interoperability is ensured by using service discovery gateways between the domains (see Figure 6.2(c)). Irrespective of the chosen architecture, interoperability is ensured by the creation and interpretation of service descriptions in clients, servers and in gateways. The structure of the different service descriptions determines whether interoperability is fully, or only partially possible.

All these approaches can solve the pervasive service discovery requirements for heterogeneous networks. However, some of these approaches have been developed for civil networks and may not

be suitable for use in military networks. We investigate these techniques in the context of military networks next.

6.2.2 Discussion

Comparing Figure 6.1 with Figures 6.2(a), 6.2(b), and 6.2(c), we can see that a gateway is the only of the three approaches that is suitable in a federation of systems. This is because it is the only approach that does not require changes within each respective administrative domain — each domain can use the discovery protocol of their choice. Instead, a gateway must be inserted between the networks in order to translate between protocols. Conversely, an adaptive protocol requires every network to adopt this protocol, requiring that all clients in every network are modified to support this adaptive protocol. The same is true for a layered discovery protocol, where every client must support the common abstraction layer.

Thus, considering the three techniques identified above, we argue thatthe gateway approach is best suited for military networks. The gateway approach will keep costs and complexity low, since the only modification needed is a gateway deployed between networks. NATO has specified the need for network level interoperability points between heterogeneous networks anyway, so that could be a convenient spot for deploying such gateways. Having identified an approach which can enable pervasive service discovery in military networks, we investigate the feasibility of implementing this solution below.