Joined effort

Feature December 2000

Joined effort
Service discovery is a critical technology for painless device interaction. How is it progressing?
Nicholas Cravotta, Contributing Editor

Networks are all about connecting intelligent devices. The challenge is that each device has to be able to determine how it can interact with other devices. In a constrained environment like a LAN, an expert person introduces every new device to the network and manages this interaction of services.

But as pervasive computing becomes a reality, portable and wireless devices will shatter the complacency of this traditional network. All kinds of devices, from PDAs to cell phones to cameras, will want to join networks at the drop of a hat. They'll need to interact directly with network-resident devices that provide services like printing or storage. It's a dynamic configuration nightmare that cries out for an automated technology.

That technology, referred to as service discovery, doesn't exist yet—at least not in a form that's up to fulfilling the vision of universal, effortless connectivity described above. But work to perfect service discovery is underway.

Currently, if you want your PDA to connect directly to a printer, you need to load a driver written specifically for that printer and your PDA—if such a driver were available. This is sometimes called the N-times-N problem of device management; when you need a driver for every combination of devices that might interact, the number of drivers quickly becomes unmanageable. Through service discovery, client devices can locate service providers and exchange appropriate drivers automatically, without any human intervention.

Ask why

Why do we need service discovery? Some service-discovery scenarios seem completely over the top. In the distant future, will your coffee maker talk to your alarm clock so it can turn itself on 10 minutes before you're supposed to wake up? Perhaps, but more realistic possibilities include airport or mall scenarios, where someone might require access to print or information services. Beyond that, the applications service discovery could enable are almost limitless (see the sidebar, "True value").

Service discovery, doesn’t exist yet—at least not in a form that fulfills the vision of universal, effortless connectivity.

However, building a universally useful system will take some doing. "You can define service discovery for your particular, narrow paradigm, but the advent of the wireless network means you can't design in a vacuum," says Robert Pascoe, president of the Salutation Consortium. "All sorts of stuff is going to your network that is useful to you. Either you have to discover that stuff or have it discover you."

Today, more than 25 protocols exist that could loosely be defined as providing service discovery. Examples include IrDA (infrared data association), Bluetooth, SLP (service location protocol) for the Internet, SNMP (simple network management protocol), and the HomePNA phoneline-networking technology. But these systems vary widely in the degree to which they achieve automatic operation.

Likewise, many of these schemes focus on specific network segments, such as the home network. Some, like Bluetooth, are tied directly to the physical communication channel used to connect a device to the network (see the sidebar, "Running on Bluetooth").

A few schemes stand independent from the physical channel, allowing them to bridge together the various wired and wireless protocols. Among these, the most prominent—and promising—are Jini, UPnP (Universal Plug-and-Play), and Salutation.

In action

Jini's model resembles a switchboard operator. When a device joins the network, it registers itself with the operator (the Jini lookup service, or LUS), explaining what it is and what it can do. When a device wants to speak to a service provider (such as a printer), it asks the operator for appropriate providers in the area and picks one from the list the operator provides. You can think of the LUS as a kind of yellow pages for services available on the network.

The Salutation service-discovery model resembles a party. A device steps into the room (logs onto the network) and introduces itself (sends out an ID). Everyone else in the room comes by to shake the hand of the new device and exchange business cards (IDs and available services). Salutation has no LUS; each client keeps track of devices and services available on the network.

The UPnP model also doesn't make use of an LUS. When a device connects to the network, it multicasts its identity. When a client wants to take advantage of a service, it multicasts a request, and those devices that can provide that service respond.

While each of these schemes has slight differences—which can result in very different types of interactions between devices—each also relies on device definitions, or profiles, to ease the task of talking about services. For example, each has a "print" class of service, which can be further refined to include characteristics such as "color" or "black and white."

The purpose of these profiles is to abstract data and format from any particular platform (OS and processor). This will allow data to be exchanged between two devices, with the receiving device dynamically formatting the data to whatever format it requires.

UPnP, for example, calls these DCPs (device control protocols). A UPnP steering committee is defining what services these DCPs, written in XML (extended markup language), will describe and support. Jini has its own definitions, as does Salutation. The Salutation group, however, is prepared to modernize from BER (basic encoding rules, an old ANSI standard) to XML and adopt the UPnP DCPs once they become available. While there may be some initial differences between the DCPs and Jini profiles, both will quickly adopt any good ideas the other has, resulting in similar functionality and easier bridging between the two standards.

Different motives

Different business models drive each standards group. The Salutation organization is a not-for-profit. Members that hope to profit from widespread adoption of Salutation fund the group and direct its agenda. Obviously UPnP receives a great deal of direction from Microsoft, but the group has been set up to be independent of the software giant in an attempt to avoid giving the impression that UPnP isn't the open industry standard Microsoft claims it is. Jini, on the other hand, still has the strong mark of Sun all over it (see the sidebar, "Out of the bottle").

“The advent of the wireless network means you can’t design in a vacuum.”
Robert Pascoe, Salutation Consortium

One weakness attributed to UPnP and Jini is that they require the use of TCP/IP and http-based protocols. Salutation, for example, claims to be "protocol agnostic" because it's not tied to a particular transmission protocol. Thus, Salutation can be implemented directly on top of other protocols, such as TCP/IP, Bluetooth, SLP, and IrDA, without requiring a bridge. More significantly, it means that devices across all protocols can come together on the same network.

Robert Pascoe

Because bandwidth and processing power in wireless devices are relatively limited, TCP/IP, with its hefty overhead requirements and complex stack handling, is burdensome to support. But the importance of this issue goes beyond simple practicality, according to Alex Saunders, director of home networking at Microsoft. "It's not an issue of bandwidth," Saunders says. "It matters whether or not you want that device to participate in the network directly."

Microsoft, he says, wanted to base UPnP on open technologies that would extend application development to a large and already extant talent pool. Additionally, Microsoft isn't so interested in how PDAs will connect to a wireless airport or mall network. "UPnP is probably not going to be targeted at these scenarios. The technology could be, but there are larger problems that need to be solved first. For example, validating yourself publicly on someone else's network is a tough [issue]" (see the sidebar, "Discovering insecurities").

This leaves UPnP really targeted at the LAN, with a backbone such as 802.11b or HomePNA that can support TCP/IP. And for devices that cannot support TCP/IP, the UPnP group is currently developing a bridge to map different protocols onto the UPnP network. Additionally, the group recently released the Simple Control Protocol (SCP), which is like UPnP but was designed to work on "impaired networks."

“The point of Universal Plug-n-Play is to allow interoperability independent of platform and OS.”
Alex Saunders, Microsoft

Another battlefield involves the use of APIs (application programming interfaces)—the hooks software developers use to take advantage of low-level system features. Because the API is the same across different platforms, developers can write applications independent of the actual hardware or operating system in use. Salutation believes that APIs should be used to describe the kind of information to be passed. The APIs won't define how that information is sent, just that it is available, which will allow Salutation service networks to be platform independent. "It isn't ever going to happen that we're going to stay with one OS," says Pascoe. "PalmOS has 74 percent of the market, even after three releases of WinCE."

Alex Saunders

Microsoft disagrees. "The point of UPnP is to allow interoperability independent of platform and OS," Saunders says. He points out that attempts to distribute an API across multiple devices across a network seem to work when the network is homogeneous. Without homogeneity, however, the API starts to break down. "The explosion of the Web taught us a key thing about systems: If you focus on protocols and data formats as opposed to APIs, you can achieve interoperability." And if that's the case, then you don't need an API.

What's real?

The reality is that service discovery is still far from becoming a reality in any of the mall or airport scenarios. Salutation has been shipping since late 1996 in products from companies such as Canon, Ricoh, and Konica, enabling PCs to query copiers and printers with such questions as "are you available?" and "do you support color?" and "can you print 300 DPI in this font?"

However, Salutation plays primarily in the office-automation market, with plans to first move into mobile printing services. After building a following there, Salutation will drop the "print" and just make it mobile services. Salutation has been moving consistently to spread its scope beyond office automation equipment. However, when asked whether the group has been making inroads into markets other than office automation, Pascoe answered, "They're not, just yet."

Jini, for its part, is currently deployed in proprietary pockets. These are typically closed environments, locked behind the firewall because Jini doesn't work well with devices popping in and out of the network. "There are well-known mechanisms for getting devices under the firewall, such as tunneling or VPN [virtual private networks]," says Mark Hodapp, Jini technology engineering manager at Sun. "But that still doesn't get us to the level of what you've heard us talk about for public networks."

UPnP is more or less targeted at the home. Windows ME supports UPnP, but the UPnP devices that have been shown—such as a TCP/IP-based camera or bridge to a legacy lighting-control system—are not yet available for purchase.

Creating zero-configuration service discovery is far from simple. Even beyond the technological issues, we'll have to grapple with plenty of social issues. For example, current Palm devices will ask you whether you want to accept a message that gets pushed to you. In this sense you're protected, since you have the choice. However, you might get hit with hundreds of messages when you walk into a wireless-enabled mall. "We have a resistance to having data beamed at us," says Salutation's Pascoe. "Certainly there will be filters developed to protect us, but that's a problem for the next generation."

Service-discovery technology promises to let us accomplish a lot with a lot less hassle. Now we just have to figure out a way to use it that doesn't drive us all crazy.

True value

Many proposed user scenarios focus on supplying information that's already available. For example, you don't need a PDA to find out about flight delays; the airport freely distributes this information over monitors. So how does an airport make money by installing wireless transponders to offer this information as a service to its customers?

Some suggest that advertising will support the wireless infrastructure. In a mall scenario, where ads can reach customers as they walk in and when they're already pre-disposed to buy, that may be true.

However, the real value of a wireless network comes from simple yet advanced services. If you've ever been through the Dallas airport with a 40-minute layover, you know what kind of running is required to catch that connecting flight. You also know what kind of food (can it be called food?) is waiting for you. Imagine being able to determine which fast-food restaurant you'll have to run past on the way to your connection, placing and paying for your order as you step off your plane, and then grabbing the food ready-to-go on your way by, without waiting in line. This is no longer a matter of rehashing information in a different format. This is a service that has "need this" value.

For all this to materialize, however, service discovery is necessary. If a PDA won't work in every airport or an airport won't support every PDA, the model won't be able to support itself. Service discovery enables devices that have never interacted before to automatically and quickly establish a relationship of exchangeable services.

Instead of using bandwidth to simply push a name in the consumer's face (and annoying the consumer), supplying information becomes the first step to actually generating a sale. ATMs, possibly the best candidate for information kiosks next to PDAs, could serve as a local source of information, supplying not just the name of a Chinese restaurant, but a Chinese restaurant within walking distance. Robert Pascoe, president of the Salutation Consortium, calls this geographic computing or "information I need when it's at the top of my head." The idea is that information is pre-filtered based on one's location, and therefore, interest.

The scope of a LAN becomes fluid, and service discovery is the means by which devices join the LAN on a temporary basis.

Pascoe sees the concept of geographic computing moving into even the vending-machine market. "I'm not sure it's so far away," he says. Today many vending machines have a network connection for remote monitoring and (soon) to allow the use of credit cards. Once you've got the pipe in place, you can pump information through it. Add a wireless interface and you've just potentially connected every portable device that comes along. "The key is that the wireless network is really just an extension of existing databases," Pascoe says. "The data is already there. The question is how you get it out to the end user."

Running on Bluetooth

With so many different standards competing for the same market space, there are bound to be interoperability problems. The point of seamless wireless connectivity, however, is the ability to bring a device into a network and not have to worry about issues such as platform, OS, or whether your UPnP device can access Jini or UPnP services.

Bluetooth is the strongest contender to provide the backbone for personal area networking, which will constitute the "last foot" connection for handheld, portable, and peripheral devices. Service discovery is built directly into the Bluetooth specification. However, if Bluetooth already has its own service-discovery mechanism, the question becomes, how will Bluetooth interact with Jini, UPnP, and Salutation?

Each of these three standards has recognized the importance of working with Bluetooth, and all the relevant groups are developing bridges to the protocol. Within the Bluetooth service-discovery protocol (SDP) itself lies a mechanism to discover higher-layer discovery protocols. At the level of SDP discovery, two devices may notice that they both support a higher-layer discovery protocol. The Bluetooth SDP then establishes a link to use that protocol and steps aside.

Out of the bottle

Sun originally envisioned Jini as a truly universal technology that would enable devices of all kinds to become useful members of a network. Jini would facilitate everything from factory floors to home-appliance networks that control the coffee pot and dim the lights.

However, Jini runs on Java. A device capable of using Jini therefore requires a JVM (Java virtual machine)—software that allows it to run Java applications. Moreover, it also requires a TCP/IP connection. Together, these requisites add up to the need for more than 1 Mbyte of memory and a lot of processing power.

Now, Sun has finally pulled its head out of the sand and acknowledged that appliances like light bulbs and hotel door locks don't require full Java capabilities. Moreover, even reasonably powerful devices like PDAs and cell phones lack the needed resources. So Jini now offers three modes of connectivity: native mode, device architecture, and surrogate architecture.

Native mode refers to a full Jini-enabled client. The device architecture allows devices that are severely resource-limited, such as light bulbs, to act through a proxy, as well as use a proprietary protocol to communicate with the proxy.

The surrogate architecture, still being defined, will probably best serve the wireless market. The surrogate sits between the client and a full Jini-device. The problem with proxies in the device architecture is that they have to know all and see all in order to bridge between the two devices. Surrogates address this by letting the proxy participate on a sliding scale. The client still has to be able to at least identify itself and send a proxy device that can act on its behalf, but the surrogate can accommodate the client by taking over some of the processing load. The client can still have its own communications protocol, but after empowering the surrogate host to execute on its behalf, other devices on the network can interact with the client without realizing they are actually interacting with a surrogate.

One of the driving forces behind the surrogate architecture is the need to enable non-Jini devices to interact with the Jini architecture. "Having a VM on every device is a bit expensive," says Mark Hodapp, Jini Technology Engineering Manager at Sun. "We'll be able to expand out the network with surrogates. They make the architecture that much more flexible." Additionally, supporting surrogates "acknowledges the great variety of devices out there."

Sun plans to release Jini 1.1 soon. The enhancements focus on making software services—such as banking services—easier to implement. Part of the challenge presented by software services—for any service-discovery scheme—is that there may be a multitude of software services, many of which are not in use at the same time. For example, a function that processes billing transactions for mobile printing services doesn't need to be running all day long, although it does need to be a registered service so it can be called at the end of day to generate a report.

The server housing these software functions has to be able to share and scale resources among the various functions. However, registered services have to occasionally check in to say "I'm still here, is there anything you want me to do?" and renew leases on memory and processor resources.

With many idle services, a network could be drowned in constant lease renewals for services that aren't currently doing anything. Version 1.1 will alleviate this problem by allowing services to register with a Lease Renewal Service that will manage this task. The service itself can stay "quiet", thus preserving resources, until its services are required again.

Discovering insecurities

Security is a key issue, especially if financial or personal information is going to be exchanged. For the most part, security is not part of a service-discovery scheme; it is assumed that the platform, particular wireless interface, and application in use will protect data as appropriate.

In one respect, security seems to be contrary to service discovery. After all, the idea is for devices to find each other so they can interact. As a consequence, service discovery schemes tend to be fairly open and loose with ID information. Thus, passwords will probably protect against unauthorized utilization but not against discovery.

This openness, however, leads to an "ID problem" that can potentially compromise encryption keys as well as user privacy. In the Bluetooth world, for example, any device can ask a Bluetooth device for its ID. This is known as a purely passive transaction. The ID is only used to establish the initial connection between two devices, after which the two devices will communicate (or not) however they want. However, this function can also be misused to follow users around by tracking their ID number. Thus, a user's privacy can be violated by being able to determine where a user is. The ID can also be used to track transactions and build up a list of encrypted messages that can then be used together to break a key.

Note that this is not purely a Bluetooth problem but one that any wireless device that carries a unique address faces, including mobile phones and wireless LAN cards. Bluetooth has a means for overcoming the problem through the Generic Access Profile, which defines both discoverable and non-discoverable modes for devices. The Bluetooth SIG (special interest group) recommends that all devices be shipped preset to non-discoverable mode. Their expectation is that most personal devices will remain in non-discoverable mode and that public devices will remain in discoverable mode. However, one repercussion of this recommendation is that now a user must initiate a connection with the network, rather than have it happen automatically as the person walks into the network's sphere.

Security is also in jeopardy with the addition of proxy services. Proxies are, in essence, authorized spoofing of devices that for some reason cannot connect directly to the network. However, once you introduce the concept of proxy, you introduce the additional difficulties of managing, authorizing, and authenticating them. Jini has begun to address the issue in JSR 76 (Java specification request) for defining an API for remote authorization and authentication.

Once such abilities are built into the JVM, security can be supported on a per-object basis, allowing devices to move objects through the network on their behalf. According to Mark Hodapp, Jini Technology Engineering Manager at Sun, however, "We're not 100 percent clear of how we're going to do this." Options include supporting these features in the lookup services or by having a separate security service devices could use. In a public network, however, there's still the question of who is authorized to do what and how you determine that. Currently, security is left up to the individual devices.