Full text of DOI:10.1109/4236.877482

Service Advertisement
and Discovery:
Enabling Universal Device Cooperation
GOLDEN G. RICHARD III
University of New Orleans
omputer users increasingly face the management of many comput-
ing devices. One reason is the expansion of computing environments
in the home and office, as printers, scanners, digital cameras, and
C
other peripherals are integrated into networked environments. Another rea-
son is the proliferation of mobile devices such as laptop and palm-sized com-
puters, cellular phones, and pagers. Because these devices trade functional-
ity for suitable form factors and low power consumption, they are necessarily
“peripheral-poor” and must therefore establish connections to neighboring
devices for storage, faxing, high-speed network access, and printing.
It is easy to become frustrated when dealing with the configuration and
interaction of such a multitude of devices. Service discovery technologies
were developed to reduce this frustration and to simplify the use of mobile
devices in a network by allowing them to be “discovered,” configured, and
used by other devices with a minimum of manual effort.
Service advertisement and
discovery technologies enable
device cooperation and reduce
configuration hassles, a
This article briefly surveys five of the leading technologies in this area.
Table 1 lists the features of each technology. Although most of these “service
discovery suites” promise similar functionality—namely, reduced configu-
ration hassles, improved device cooperation, and automated discovery of
necessity in today’s increasingly required services—they come at the problem from different philosophical
and technical approaches. Since none of these technologies is a superset of
mobile computing
the others and none is mature enough to dominate the market, interoper-
ation among them will require bridging mechanisms. The survey concludes
with a review of some developments in this area.
environments. This article
surveys five competing but
similar “service discovery
suites” and looks at efforts to
bridge the technologies.
BLUETOOTH: PICONETS FOR
WIRELESS DEVICES
Bluetoothis a low-power, short-range, wireless radio system being devel-
oped by the Bluetooth Special Interest Group, an industry consortium
whose member companies include Ericsson, Nokia, and IBM. The radio
has a range of 10 meters and provides up to seven 1–megabit-per-second
links to other Bluetooth devices. Bluetooth operates in the 2.4-GHz indus-
-
18
SEPTEMBER • OCTOBER 2000 http://computer.org/internet/
1089 7801/00/$10.00
©
2000 IEEE
IEEE INTERNET COMPUTING

S
E
R
V
I
C
E
D
I
S
C
O
V
E
R
Y
trial scientific and medical (ISM)
band to maximize international
acceptance and employs a fre-
quency-hopping system to min-
imize interference. The low-level
communications are detailed in
the Bluetooth specification.1
Bluetooth has a small form
factor; complete systems can be
as small as 2-cm square. The
technology supports both
isochronous and asynchronous
services. A simple isochronous
Table 1. Features of the five leading service discovery suites.
Feature
Bluetooth
Jini
✔
Salutation UPnP
SLP
✔
Service discovery
Service announcement
Service registry
Interoperability
Security
✔
✔
✔
✔
✔
✔
✔
✔
✔
✔
✔
✔
✔
✔
✔
✔
✔
application might link a cellular phone and wire-
less headset, where the headset and base are both
Bluetooth devices. More complicated applications
include automatic discovery of wireless network
connections and automatic synchronization of data
between several Bluetooth devices.
TCP/UDP
AT
vCard,
and so on
IP
TCS
SDP
Figure 1 shows the Bluetooth protocol stack. At
the bottom, the radio and baseband layers provide
the short-range, frequency-hopping radio platform.
The link manager protocol (LMP) handles data link
setup and provides authentication and encryption
services. The logical link control and adaptation
protocol (L2CAP) supports multiplexed connec-
tionless and connection-oriented communication
over the LMP layer. L2CAP is proprietary, but other
network protocols, such as IP, can be built on top
of it. L2CAP is also used by higher level protocols.
For example, Figure 1 shows links to the Hayes-
compatible AT (ATtention) protocol, which pro-
vides a standard interface for controlling remote cel-
lular phones and modems; RFComm, which
emulates an RS-232 serial interface; a simple object
OBEX
PPP
RFComm
L2CAP
Audio
LMP
Baseband
Radio
exchange protocol (OBEX), which enhances Blue- Figure 1. Bluetooth protocol stack. The link manager protocol (LMP)
tooth’s interoperability with IrDA; and Bluetooth’s controls link setup and provides encryption and authentication ser-
service discovery protocol (SDP).
vices. The proprietary logical link control and adaptation protocol
Groups of up to eight Bluetooth devices can (L2CAP) provides multiplexed communication over LMP to higher
form ad hoc networks called piconets to communi- level layers.
cate, share services, and synchronize data. In each
piconet, a master device coordinates the other Blue-
tooth devices (including setting the 1,600–hops-
per-second frequency-hopping pattern). Individ-
ual devices can participate in more than one
piconet at a time and can be in one of several states:
I
I
Connected—the device is connected to anoth-
er Bluetooth device.
Hold and park—the device is participating in a
piconet with varying degrees of power savings.
I
I
I
Standby—the device is conserving power and The Bluetooth SDP provides a simple API for
waiting to connect to another Bluetooth device. enumerating the devices in range and browsing
Inquire—the device is searching for nearby available services. It also supports stop rules that
Bluetooth devices.
Page—the device is connecting to another Blue- devices returned. Client applications use the API
tooth device. to search for available services either by service
limit the duration of searches or the number of
IEEE INTERNET COMPUTING
http://computer.org/internet/
SEPTEMBER • OCTOBER 2000
19

F
E
A
T
U
R
E
must negotiate encryption
strength to comply with laws
restricting encryption. Note that
Bluetooth devices must be paired
to provide them with matching
secret keys that will support
authentication. Once paired,
Bluetooth devices can authenti-
cate each other and protect sen-
Client
Lookup server
Service
Java code
(proxy)
Figure 2. Jini service discovery entities: clients, lookup servers, and services. In this sitive data from snooping.
example, a printer service registers a proxy object with a lookup server, which will Regardless of encryption
serve as a remote control for clients that use the service.
strength, Bluetooth’s fast fre-
quency-hopping scheme makes
snooping difficult.
classes, which uniquely identify types of devices
(such as printers or storage devices), or by match- JINI: MOBILE JAVA CODE
ing attributes (such as a model number or sup- Jini is a service discovery and advertisement system
ported protocol). Attributes that describe the ser- that relies on mobile code and leverages the plat-
vices offered by a Bluetooth device are stored as a form independence of the Java language.2 The cur-
service record and are maintained by the device’s rent Jini implementation is based on TCP and
SDP server.
UDP, but implementations based on other network
protocols are certainly possible. The major require-
ments are reliable, stream-oriented communication
and a multicast facility. Jini’s language-centric
approach allows a flexible definition of service; for
example, a service can be implemented entirely in
software and, after discovery, can be downloaded
and executed entirely on the client. Examples of
such algorithmic services might include an imple-
mentation of a proprietary algorithm for shading a
polygon or formatting a document to meet an orga-
nizational standard. On the other hand, Jini also
Jini requires each device either to
run a Java virtual machine or to
associate itself with a device that
can execute a JVM on its behalf.
The distinction between service classes and requires each device either to run a Java virtual
descriptive attributes is not well defined, but ser- machine or to associate itself with a device that can
vice classes generally define broad device categories, execute a JVM on its behalf. For example, a Jini
such as Printer, ColorPrinter, and PostScriptPrint- “device chassis” might Jini-enable a number of
er, while attributes allow a finer level of description. “dumb” devices, making their services available to
Manufacturers must eventually standardize these Jini clients.
service classes for maximal interoperability between
Bluetooth devices.
Jini entities consist of services, lookup servers that
catalog available services, and clients that require
Unlike higher level service discovery technolo- services. A service can also be a client; for example,
gies such as Jini, Bluetooth’s SDP does not provide a telescope might provide pictures to a PDA as a
a mechanism for using discovered services—spe- service and look for printing services as a client. All
cific actions required to use a service must be pro- service advertisements and requests go through a
vided by a higher level protocol. However, it does lookup server. Figure 2 illustrates the discovery and
define a standard attribute ProtocolDescriptorList, registration process for Jini clients and services.
which enumerates appropriate protocols for com-
municating with a service.
To register service availability or to discover ser-
vices, a service or client must first locate one or
Bluetooth devices provide data security through more lookup servers by using a multicast request
unique 48-bit identifiers, 128-bit authentication protocol. This request protocol terminates with the
keys, and 8- to 128-bit encryption keys. Strong invocation of a unicast discovery protocol, which
authentication is possible because no internation- clients and services use to communicate with a spe-
al restrictions prevent it, but Bluetooth devices cific lookup server. The unicast protocol culmi-
SEPTEMBER • OCTOBER 2000 http://computer.org/internet/
IEEE INTERNET COMPUTING
20

S
E
R
V
I
C
E
D
I
S
C
O
V
E
R
Y
nates in the transfer of an instance of the Ser-
viceRegistrar class, a “remote control” for the
lookup server. A lookup server can use the multi-
cast announcement protocol to announce its pres-
ence on the network. When a lookup server
invokes this protocol, clients and services that have
registered interest in receiving announcements of
new lookup services are notified.
Service
Service
Service
Client
Client
Salutation manager
Transport manager
Salutation manager
Transport manager
Salutation
manager protocol
These three protocols are encapsulated in a set
of Jini classes. For example, to find lookup services,
a client or service need only create an instance of Figure 3. Salutation architecture. Salutation managers are service
LookupDiscovery. brokers, isolated by transport managers from the details of specific
Jini uses Java’s remote method invocation (RMI) network transport protocols.
facility for all interactions between either a client
or a service and the lookup server (after the initial
discovery of the lookup server). Once a lookup ServiceTemplate constructor takes several arguments.
server has been discovered and an instance of Ser- The first is the service identifier. If the service iden-
viceRegistrar is available, services can register their tifier is null, then arrays of types (Java classes, typ-
availability, and clients can search for needed ser- ically interfaces) and attributes (attribute objects)
vices by invoking ServiceRegistrar methods.
are used to match services. A service matches if its
Jini associates a proxy, or remote control object, class matches one of the classes in the types array
with each service instance. A service advertises its and if, for each of the attribute objects, all non-null
availability by registering its object in one or more members match one of the service’s registered
lookup servers via the register() method. This attributes. The return value from lookup() is an
method takes several arguments, including an instance of ServiceMatches, which contains an array
instance of ServiceItem, which contains a univer- of remote control objects for the services that
sally unique identifier for the service, its attribute match. Finally, the notify() method allows a client
set, and its remote control object. This object may to request an asynchronous notification when ser-
either implement the service entirely (in the case vices matching a ServiceTemplate instance become
of an algorithmic service such as the implementa- available. This method uses Jini’s distributed events
tion of a polygon-shading algorithm), or provide mechanism, which extends Java’s infrastructure for
methods for accessing the service over the network. eventing across JVMs.
The leaseduration parameter of register() specifies
Jini depends on Java’s security model, which
the service’s intended lifetime. The service is provides tools like digital certificates, encryption,
responsible for renewing the lease within the time and control over mobile code activities such as
specified to maintain its listing. The lookup serv- opening and accepting socket connections, reading
er is free to adjust the lease time, which is returned and writing to specific files, and using native meth-
in a ServiceRegistration object.
ods. Systems administrators can establish different
When a service first contacts a lookup server, the policies depending on where the Java code origi-
server generates a unique identifier for it; the ser- nated (for example, the local file system or a remote
vice uses this ID in all future registrations. The ser- machine).
vice identifier lets clients request a specific service
explicitly and recognize when services reported by SALUTATION: A NETWORK-
different lookup servers are identical.
INDEPENDENT ARCHITECTURE
To use a service, a device must first secure an Salutation is an architecture for service discovery
instance of the proxy object for it. From a client under development by the Salutation Consortium,
point of view, the location of the service proxied by which includes members from both industry and
this remote control object is unimportant, because academia.3 The consortium’s goal is to build a roy-
the object encapsulates the location of the service alty-free architecture for service advertisement and
and the protocol necessary to operate it.
discovery that is independent of a particular net-
Clients use the lookup() method in ServiceReg- work transport.
istrar to discover services. This method takes a sin-
Figure 3 shows the three fundamental compo-
gle argument, an instance of ServiceTemplate. The nents in the Salutation architecture: functional units,
IEEE INTERNET COMPUTING
http://computer.org/internet/
SEPTEMBER • OCTOBER 2000
21

F
E
A
T
U
R
E
salutation managers, and transport managers. From a
client’s point of view, a functional unit defines a ser-
vice. Functional units already specified or under
consideration by the Salutation Consortium include
printing, faxing, and document storage. There is
also work on a functional unit specification to allow
discovery of Hewlett-Packard JetSend-enabled
devices. The specifications define attributes that
I
I
In native personality, Salutation managers are
used only for discovery. They establish a con-
nection between a client and service but per-
form no further operations on the data stream.
The emulated personality is similar to the native
personality in that Salutation managers set up
the connection, but in this case they transfer
native data packets encapsulated in Salutation
manager protocol format, providing a bridge
when no common message protocol exists
between client and service. The Salutation man-
ager is ignorant of the semantic content of the
data stream between client and service.
Salutation requires a network
transport protocol that supports
reliable, stream-oriented
communication.
I
In Salutation personality, Salutation managers
establish the connection between client and ser-
vice, and they also mandate the specific format
of the data transferred. The Salutation archi-
tecture defines the data formats.
characterize a service (for example, in the case of a A transport manager isolates the implementation
printer, double-sided capability, color, and so on). of the Salutation manager from particular trans-
The functional unit Doc Storage defines file port-layer protocols and thereby gives Salutation
attributes that can be used to find information in network transport independence. To support a
temporary or long-term storage. For example, a new network transport requires a new transport
client can search for operating system-specific dri- manager to be written, but does not require mod-
vers or software necessary to interact with a newly ifications to the Salutation manager. Like Jini (and
discovered device. The client simply queries a Salu- UPnP), Salutation requires a network transport
tation manager for the necessary Doc Storage func- protocol that supports reliable, stream-oriented
tional unit, extracts the application or device driver, communication. Initial implementations are based
and installs it, thus providing limited code mobility. on IP and IrDA because of their widespread use.
Salutation managers function as service brokers;
Transport managers also locate the Salutation
they help clients find needed services and let ser- managers on their respective network segments via
vices register their availability. Services can register either multicast, static configuration, or reference
and unregister functional units with the local Salu- to a centralized directory. Discovery of other Salu-
tation manager by using the API calls slmRegister- tation managers allows a particular Salutation man-
Capabilities() and slmUnregisterCapabilities(), respec- ager to determine which functional units have been
tively. A client can use the slmSearchCapability() call registered and to allow clients access to these remote
to determine if Salutation managers have registered services. Communication between Salutation man-
specific functional units. Under the current version agers is based on remote procedure call (RPC). This
of the architecture, applications can query only the interaction between remote Salutation managers
local Salutation manager. Future versions will allow contrasts with other registry-based service discov-
remote Salutation managers to be specified. Once a ery mechanisms (for example, Jini and Service
functional unit is discovered, slmQueryCapability() Location Protocol), where clients would be respon-
can be used to verify that a functional unit has cer- sible for locating remote registries.
tain capabilities. The API also includes calls for ini-
The Salutation specification currently does not
tialization/version checking, availability checking, address security issues.
and communication between clients and services.
A lightweight version of Salutation, called Salu-
(An API simulator is available at http://www.salu- tation-Lite, has been developed for resource-limit-
tation.org/simulate.htm.)
ed devices. It is based primarily on IrDA to leverage
Salutation managers fill a role similar to lookup the large number of infrared-capable devices. Salu-
servers in Jini, but they can also manage the con- tation-Lite focuses primarily on service discovery. It
nections between clients and services. A Salutation uses the functional units OpEnvironment and Dis-
manager can operate in one of three “personalities”: play to describe the operating system, processor
SEPTEMBER • OCTOBER 2000 http://computer.org/internet/
IEEE INTERNET COMPUTING
22

S
E
R
V
I
C
E
D
I
S
C
O
V
E
R
Y
Multicast discovery
Discovery
server
Presentation
server
Service
Control point
Application
The discovery server sends the URL for
the device's description document
in response to the client's multicast
discovery message.
Commands
Rehydrator
SCP
The control point generates the service control protocol
from information in the description document.
Figure 4. Interaction between a client (control point) and a service in UPnP. The control point discovers the
device by sending a multicast message. The device responds with a URL pointing to its description doc-
ument, which the control point can download for pertinent information, including a URL to which con-
trol messages can be sent and the protocol for interacting with the device through this control URL. The
“rehydrator” converts generic commands into device-specific control messages.
class, amount of memory, and display characteris- in the device act as entry points for interacting with
tics of palm-sized devices. By noting the particular and controlling it. Devices that don’t speak UPnP
characteristics of the device, servers can provide directly are called bridged devices. They can be inte-
appropriate drivers and software wirelessly.
grated into a UPnP network in a manner similar to
Salutation-Lite implementations can be down- the integration in a Jini device chassis: A bridge maps
loaded free from the Salutation website at between UPnP and device-native protocols.
http://www.salutation.org.
The UPnP specification describes device
addressing, service advertisement and discovery,
device control, eventing, and presentation. The
eventing facility allows clients to watch for signifi-
UPnP: XML FOR A
WEB-BASED ARCHITECTURE
UPnP is a proposed architecture for service adver- cant changes in the state of a discovered service. It
tisement and discovery supported by the UPnP functions similarly to Jini’s distributed event facil-
Forum, headed by Microsoft. Unlike Jini, which ity. Presentation allows a client to obtain a GUI for
depends on mobile code, UPnP aims to standardize a discovered device through one of the device’s vir-
the protocols used by devices to communicate, tual Web servers. Several protocols support these
using XML. The UPnP specification4 is still in a functions:
preliminary stage; major issues like security have
not yet been addressed.
I
AutoIP,5 a simple protocol that allows devices
to dynamically claim IP addresses in the
absence of a DHCP server;
Simple service discovery protocol (SSDP), the
UPnP mechanism for service discovery and
advertisement;
UPnP’s device model is hierarchical. In a com-
pound device (for example, a VCR/TV combo), the
root device is discoverable, and a client (called a con-
trol point) can address the individual subdevices (for
example, a tuner) independently. Virtual Web servers
I
IEEE INTERNET COMPUTING
http://computer.org/internet/
SEPTEMBER • OCTOBER 2000
23

F
E
A
T
U
R
E
I
I
A control URL is the entry point to the device’s
control server, which accepts device-specific
commands to control the device.
An event subscription URL can be used by
clients to subscribe to the device’s event service.
The client provides an event sink URL in the
subscription request. Significant state changes
in the device result in a notification to the
client’s event sink URL.
Server
agent
Server
agent
Network
SD
User
agent
User
agent
I
A service control protocol definition describes the
protocol for interacting with the device.
Macintosh
Classic II
Directory agent
The service control protocol (SCP) definition
allows APIs to be converted to device-specific com-
mands, shielding the application level from details
of particular devices. After retrieving the descrip-
tion document, a UPnP component on the control
point called the rehydrator is “plumbed” with a def-
inition of the device’s SCP. This component then
sends device-specific commands via the device’s
SD
Workstation
Figure 5. SLP entities: user agents, directory agents, and service control URL. SOAP is used for this interaction.
agents. UAs discover services on behalf of applications, either via a SSDP is similar to the Internet Engineering Task
DA or directly through an SA. In this example, a laptop and desktop Force’s service location protocol, but it lacks a query
are clients seeking services. A plotter and LCD projection system are facility that can search for services by attributes. Fur-
services advertising their availability.
ther, SLP incorporates security measures and can
interact with the IETF standards-track dynamic host
configuration protocol (DHCP)7 and the lightweight
I
I
Simple object access protocol (SOAP),6 a pro- directory protocol (LDAP).8 Finally, SSDP specifi-
tocol for remote procedure calls based on XML cations currently limit discovery to a single subnet.
and HTTP that is used for device control after Since UPnP does not use a registry, it is also likely to
discovery; and
Generic Event Notification Architecture
generate significantly more network traffic than SLP.
(GENA), a UPnP subscription-based event SLP: A PROPOSED IETF
notification service based on HTTP.
STANDARD
Service location protocol is an IETF protocol for
When devices are introduced into a network, they service discovery and advertisement.9 It is current-
multicast “alive” messages to control points. When ly at the “proposed standard” stage along the IETF
they wish to cancel availability of their services, they standards track. Unlike Jini, Salutation, and UPnP,
send “byebye” messages. In SSDP, each service has which all aspire to some degree of transport-level
three associated IDs—service type, service name, independence, SLP is designed solely for IP-based
and location—which are multicast when services networks. It provides a set of C and Java bindings
are advertised. Any of these IDs can also be used to that provide service discovery and advertisement
search for services.
functions to application software.
To search, a control point sends a UDP multi-
SLP comprises three entities: service agents
cast request to the network, as shown in Figure 4. (SAs), user agents (UAs), and directory agents (DAs).
Matching services send unicast responses to the SAs advertise the location and attributes of avail-
client. These responses contain URLs, each point- able services, while UAs discover the location and
ing to an XML description document that describes attributes of services needed by client software.
a service. A description document contains several UAs can discover services by issuing a directory-
important items:
like query to the network. DAs cache information
about available services. Unlike Jini, SLP can oper-
I
A presentation URL allows entry to a device’s root ate without directory servers. The presence of one
page, which provides a GUI for device control. or more DAs can substantially improve perfor-
SEPTEMBER • OCTOBER 2000 http://computer.org/internet/
IEEE INTERNET COMPUTING
24

S
E
R
V
I
C
E
D
I
S
C
O
V
E
R
Y
mance, however, by reducing the number of mul- tion effort, but the effort can be well worth it, par-
ticast messages and the amount of network band- ticularly in open environments.
width used. In fact, if DHCP is used to configure
SLP agents with the location of DAs, then multi- BRIDGING THE TECHNOLOGIES
cast is completely unnecessary. SLP also interop- For service discovery to become pervasive, either
erates with LDAP, so services registered with an a single service discovery technology must domi-
SLP DA can be automatically registered in an nate or the most commonly used technologies
LDAP directory. This eliminates the need to must be made interoperable. Currently, bridging
reconfigure clients that already discover services seems to be the most promising prospect for inter-
using LDAP.
operability.
SLP has several mechanisms for discovering DAs:
I
I
In passive discovery, SAs and UAs listen for
multicast announcements from DAs, which
periodically repeat these advertisements.
In active discovery, SAs and UAs multicast SLP
requests or use DHCP to discover DAs. When
a DA is present, SAs and UAs use unicast com-
munication to, respectively, register their ser-
vices and find appropriate services.
Implementations of certain
low-level functions of service
discovery (such as discovering
registries) are interchangeable.
In the absence of DAs, UAs multicast requests for
Implementations of certain low-level functions
service and receive unicast responses directly from of service discovery (such as discovering registries)
the SAs that control matching services. This tends are interchangeable. For example, the Salutation
to increase bandwidth consumption, but provides Consortium uses SLP for service discovery beyond
a simpler model, appropriate for small networks the local subnet. This lets the Salutation Manager
(such as a home LAN).
SLP services are advertised through a service functional units and search for requested services.
URL, which contains all information necessary to A Jini-SLP bridge has also been developed,
search for SLP DAs, and then use SLP to register
contact a service. Clients use the service URL to which allows services lacking a JVM to participate
connect to the service. The protocol used between in Jini systems.11 The heart of the Jini-SLP bridge is
the client and server is outside the scope of the SLP a special SLP UA that registers the availability of
specification. This separation is similar to Blue- “Jini-capable” SLP SAs. To do this, Jini-capable
tooth, where the SDP does not specifically address SLP services advertise the availability of a Jini driver
how devices will communicate.
factory. The UA discovers all SAs with driver fac-
Service templates define an attribute set for each tories and registers them with one or more Jini
service type (a printer, for example).10 The attrib- lookup services. When a Jini client needs one of the
utes include a specification of the attribute types registered SAs, it downloads the driver factory from
and information about default and allowed values; the lookup server and uses it to instantiate a Java
they are used to differentiate between services of object to drive the service. Note that the SLP SAs
the same type and to communicate configuration are not required to host a Java virtual machine—
information to UAs.
the Java code installed on the SAs is static. Similar
SLP doesn’t define the protocols for communi- schemes are possible for the other technologies; for
cation between clients and services, and so its secu- example, it should be possible to Jini-enable UPnP
rity model concentrates on preventing the mali- services in this way.
cious propagation of false information about
Miller and Pascoe12 describe mapping Saluta-
service locations. SAs can include digital signatures tion to Bluetooth SDP to take advantage of Blue-
when registering so DAs and UAs can verify their tooth’s wireless capability. Two approaches are con-
identity. Digital signatures can also be required sidered: The first maps the Salutation APIs to
when DAs advertise their availability, allowing UAs Bluetooth SDP by implementing Salutation on
and SAs to avoid rogue DAs (that is, those without top of Bluetooth; the second uses a Bluetooth
a proper signature). As with Jini, setting up the transport manager and essentially replaces Blue-
security features of SLP requires some configura- tooth SDP with Salutation. This approach will also
IEEE INTERNET COMPUTING
http://computer.org/internet/
SEPTEMBER • OCTOBER 2000
25

F
E
A
T
U
R
E
work with other schemes, like Jini. Bluetooth is a
particularly attractive target for interoperability,
primarily because of its wireless capability. Because
of this, additional interoperability efforts between
Bluetooth and other service discovery technologies
seem inevitable.
Each service discovery technology has advan-
tages and disadvantages. Currently, interoperabili-
ty efforts are perhaps the most important force in
service discovery, since it is very unlikely that device
manufacturers will embrace multiple service dis-
Hoc IPv4 Network,” IETF Internet draft, work in progress,
Mar. 2000.
6. Simple Object Access Protocol (SOAP) 1.1, W3C Note;
available online at http://www.w3.org/TR/SOAP.
7. R. Droms, “Dynamic Host Configuration Protocol,” IETF
RFC 2131, Mar. 1997; available online at http://www.
dhcp.org/rfc2131.html.
8. M. Wahl, T. Howes, and S. Kille, “Lightweight Directory
Access Protocol, version 3,” IETF RFC 2251, Dec. 1997;
available online at http://www.rfc-editor.org/rfc/rfc2251.txt.
9. E. Guttman, “Service Location Protocol: Automatic Dis-
covery of IP Network Services,” IEEE Internet Computing,
vol. 3, no. 4, July/Aug. 1999, pp. 71-80.
covery technologies on low-cost devices.
I
ACKNOWLEDGMENTS
Thanks to Sumi Helal of the University of Florida for sparking
10. E. Guttman, C. Perkins, and J. Kempf, “Service Templates
and Service: Schemes,” IETF RFC 2609, June 1999; avail-
able online at http://www.rfc-editor.org/rfc/rfc2609.txt.
my interest in this area. Much of the material in this article is
derived from a tutorial he invited me to create for IPCCC 2000 11. E. Guttman and J. Kempf, “Automatic Discovery of Thin
in Phoenix. Many thanks to Erik Guttman of Sun Microsystems
for clarifying the differences between SLP and SSDP and going
way beyond the call of duty in critiquing early versions of this
Servers: SLP, Jini and the SLP-Jini Bridge,” Proc. 25th Ann.
Conf. IEEE Industrial Electronics Soc. (IECON 99), IEEE
Press, Piscataway, N.J., 1999.
article. David La Motta and Kirk Perilloux were kind enough 12. B. Miller and R. Pascoe, “Mapping Salutation Architec-
to read early versions and offer suggestions. Finally, my person-
al editor (and mate) Christine Ciarmello-Richard was gracious
enough to lend her critical eye, as always.
ture APIs to the Bluetooth Service Discovery Layer,” white
paper; available online at http://www.salutation.org/
whitepaper/BtoothMapping.pdf.
REFERENCES
Golden G. Richard III is an assistant professor of computer sci-
ence at the University of New Orleans in Louisiana. His
research interests include mobile computing, wireless net-
working, operating systems, and fault tolerance. He is on
the executive committee of the IEEE Technical Commit-
tee on the Internet, a member of the IEEE and the ACM,
and liaison to the University of New Orleans for Usenix’s
Educational Outreach Program.
1. Specification of the Bluetooth System; available at http://www.
bluetooth.com/developer/specification/specification.asp.
2. K. Arnold et al., The Jini Specification, Addison-Wesley
Longman, Reading, Mass., 1999.
3. Salutation Architecture Specification; available online at
http://www.salutation.org/specordr.htm.
4. Universal Plug and Play specification v1.0; available online
at http://www.upnp.org/.
5. R. Troll, “Automatically Choosing an IP Address in an Ad- Readers may contact the author at golden@cs.uno.edu.
How to Reach IC
Writers
We welcome submissions about Internet application technologies. For detailed instructions and information on peer
review, IEEE Internet Computing’s author guidelines are available online at http://computer.org/internet/edguide.htm.
Letters to the Editor
Please send letters via e-mail to internet-computing@computer.org.
Reuse Permission
For permission to reprint an article published in IC, contact William J. Hagen, IEEE Copyrights and Trademarks Manager,
IEEE Service Center, 445 Hoes Lane, Piscataway, NJ 08855-1331; w.hagen@ieee.org. Complete information is available
at http://computer.org/permission.htm. To purchase reprints, visit http://computer.org/author/reprint.htm.
SEPTEMBER • OCTOBER 2000 http://computer.org/internet/
IEEE INTERNET COMPUTING
26