Let’s communicate

Networking disparate systems requires close 
attention to service discovery.

Implementing ever-advancing networking technologies to connect varieties of systems and subsystems can present daunting challenges. Wireless devices, for example, allow users to enter and leave multiple networks at will. These become personal area networks that enable users to connect to remote databases, update remote files, transfer or print files, trade voice mails and swap video files, even with portable and wireless devices, such as personal digital assistants (PDAs).

Wired networks present similar capabilities—and challenges. These networks, which can be local, wide area or even ad hoc, also span multiple platforms interconnected via various nodes. For maximum efficiency, such networks should configure themselves so that they are effectively transparent to consumers. Connections should work immediately without online settings to worry about, or set-up wizards to fuss with, or hard-to-fathom manuals to read.

How does a network implementer or user get different computing platforms to communicate over different networks when they have different specifications and protocols?

An important technology to provide users with connectivity, flexibility and interoperability among networks is a “middleware” architecture called service discovery. Service discovery is designed to allow two disparate devices, such as a printer and a PC, to communicate their functional capabilities to one another to determine whether one can use the other. This middleware also may search for a device on a network that meets specific requirements, such as document finishing.

For example, a PC in a basic service-discovery technology might poll the network’s devices and services, asking “Tell me all about yourself.” An advanced service discovery, on the other hand, would let the PC say, “I need a printer with a specific set of capabilities,” to which the “right” printer would respond, “Here I am.” The advanced service discovery would then let the PC use that printer.

Unfortunately, not all service-discovery protocols are compatible. Sun’s Jini cannot interact with Universal Plug and Play, the Microsoft offering, for example.

Consequently, for best results, system implementers should look for service-discovery protocols that have several important criteria. One is the ability to describe a device’s class or a service’s functionality. Secondly, a service discovery must support the various network models. Thirdly, it should have the capability to search for and find the device needed. Finally, the service-discovery technology must be independent of operating systems and protocols.

An example of such a service-discovery technology is the Salutation Architecture, offered free by the industry-wide, not-for-profit Salutation Consortium, a cooperative, standard-proposing group of participating members. A reference model of the architecture is available from the consortium in open source.

The Salutation Architecture was specifically developed to solve the problems of service discovery and usage among a broad set of appliances and equipment in a network environment of spreading interconnectivity and mobility. It provides a standard method for applications, services and devices to describe and publicize their capabilities to their counterparts on networks, so that those capabilities can be accessed and used in interoperable sessions.

This architecture is designed to meet the criteria sought by network system implementers. For example, it enables a PC to do more than merely find a printer. In identifying itself, a printer would report its color capability, the various resolutions it supports, whether a document finisher and collator are available, and the contents of its input drivers to help make the proper match.

The Salutation Architecture also supports various network models. In traditional networks, a central directory contains detailed records about the network elements. In less formal networks, a surrogate directory or look-up table may be constructed, with one of the nodes acting as the repository of the details about the devices and services in a temporary network. Ad hoc or peer-to-peer do not need a directory because the devices determine each other’s capabilities through direct interaction.

The Salutation Architecture is designed to be independent of processor, operating system and communications protocols. The architecture also allows for scalable implementations, even in small portable devices that are resource-constrained.

To aid application of the Salutation Architecture, the Bluetooth Special Interest Group (SIG) has defined a process that enables system developers to employ the architecture for service-discovery and utilization functions in Bluetooth short-range radio frequency networks. Similar processes are being followed with the Infrared Data Association and the Video Engineering Standards Association.

Pascoe is president of the Salutation Consortium, Highland, UT.