Information Technology Reference
In-Depth Information
protocols and become transparent to the service
discovery protocols. Our discussion first focuses
on design issues and solutions at the application
layer protocols. Towards the end of the chapter,
we discuss a set of service discovery protocols
that choose to use cross-layer design to integrate
service discovery protocol with lower network
layers for performance reasons. Cross-layer design
violates the network design principle and trades
clean design for performance improvements.
Often, software functionality is the first prior-
ity, whereas security and privacy are the second
priority. Such software design and development
practice is the case for service discovery protocols.
Once devices run service discovery protocols
and communicate over wireless networks, they
may easily be found and accessed by any other
devices without the devices owners' knowledge.
For instance, a person may walk by a house and
discover and control devices in the house. Secu-
rity and privacy remain to be a serious challenge.
Figure 2 shows the main components for the
service discovery architecture and protocol design.
The following sections analyze various design
choices made by service discovery protocols and
point out remaining issues.
Defining services in SLP should follow a service
template (Guttman, Perkins, & Kempf, 1999).
It is likely that many service discovery proto-
cols co-exist. When a mobile client moves from
one service discovery domain to another service
discovery domain, the mobile client needs to un-
derstand different service protocols and use differ-
ent vocabularies, for example saying print service
at one time and printing service at another time.
The other problem is how to support new
services. Although it is easy to add a new service
name to a service protocol standard, it is difficult
for users and client programs to know it automati-
cally. Very likely, users need to browse for service
names and then learn the new terms.
Service Attributes.
A service usually has
many attributes. To avoid conflicts, service at-
tributes also have standard naming conventions
as service names. A client's request is matched
against services' attributes. When a client supplies
more precise query requirements, fewer services
will be selected. As a result, less network traffic
is generated and fewer services are involved. If
a query is too strict, no services may be matched
and then the client needs to query again with fewer
constraints. In addition to search functionality,
most service discovery protocols provide wild
card searches, which let clients examine all the
available services.
Service Invocation.
After discovering the
service, a client invokes the service through a
service interface. Some protocols such as the
Bluetooth Service Discovery Protocol leave the
service interface for applications to define. Some
protocols base on Remote Procedure Call (PRC).
Salutation is such an example. Some protocols use
downloadable code. For example, Jini uses down-
loadable Java code. Other service protocols only
transfer data. UPnP achieves service invocation
based on eXtensible Markup Language (XML),
Simple Object Access Protocol (SOAP), and
Hyper Text Transform Protocol (HTTP).
Service invocations in Jini and UPnP need
TCP/IP protocols, HTTP servers, or Java Virtual
Service Designs
We describe a service as some computing resource
used by users, user programs, or other services.
For example, printing services, location based
information, and wireless network connections
are services.
Service Naming.
A service has a name. Sup-
pose Bob uses a printer. Printing is the name of
the service. Nevertheless, the problem is when
Bob looks for a printing service, a printer calls
itself a print service. Then Bob is unable to find
the printer. Most protocols solve this problem by
defining a service naming standard, which avoids
the naming conflict (Kindberg & Fox, 2002).
Bluetooth maps service names to 128-bit numbers.
Search WWH ::
Custom Search