Service Discovery Architecture and Protocol Design for Pervasive Computing - Advanced Design Approaches to Emerging Software Systems - page 95

Service Integration Malicious users may listen to communication

channels or even actively attack systems. These
requirements are translated to use of message en-
cryption and message authentication code. Several
service discovery protocols including SSDS and
PrudentExposure use cryptographic approaches
to encrypt and digitally sign the discovery mes-
sages, announcements, and other communication
messages (Czerwinski, et al., 1999; Zhu, et al.,
2003, 2005).
Availability, Non-repudiation, and User
Privacy. Services and directories may be targets
of attackers. Making services and directories
available against attack is similar to other network
applications. We are not aware of any existing
service discovery protocols that explicitly address
the availability issues.
User privacy is always a concern. We want
to use services easily but keep our information
private. A progressive and secure service discov-
ery protocol exposes users' query information
and service providers' service information over
multiple rounds (Zhu, Zhu, Mutka, & Ni, 2007).
In each round, several bits of the information in
an encrypted form are exchanged. If the client
and the service provider find the matches in the
request and reply, they continue interacting with
each other. Otherwise, the interaction is stopped
and not further information is exchanged. The
approach is also limited to users and service pro-
viders who are familiar with each other.
Deploying security in service discovery proto-
cols means more administrative overhead. Proper
permissions need to be set for services and users.
With thousands of services and hundreds of users
in an enterprise, groups or roles need to be created
and privileges need to be assigned. In dynamic
environments, daily administrative tasks may be
overwhelming. Even if service discovery protocols
try to make service usage easier, overwhelming
security administrative tasks may offset some
advantages.

Services provide different functionalities. Taking
services as building blocks, service integration can
build complex and very powerful services. Service
integration is also known as service composition.
Simple Service Integration vs. Complex
Service Integration. Simple service integration
chains services together. One service's output is
another service's input. Ninja Paths is an example
of simple service integration (Gribble et al., 2001).
To get a composite service, a path is created. Along
that path, services are dynamically selected and
connected.
Complex service integration may provide
more complicated services. Two complex service
integration methods are discussed in (Mennie &
Pagurek, 2000). One way is to create a service in-
terface to interact with multiple services. Another
way is to compose services and build a stand-alone
service. Those integrated services may be used as
service components to build other services.
Static vs. Dynamic Service Integration.
Static service integration integrates services before
a client uses the services. If one of the services
fails, service integration needs to start over again.
Dynamic service integration may replace failed
services or add in more services if necessary with-
out starting over the service integration processes.
Dynamic service integration is more difficult to
implement than static service integration since
every service component of the dynamic service
is being monitored and should be replaced im-
mediately in case of failure.
Fault Tolerance and Failure Recovery. In
dynamic and distributed environments, fault toler-
ance and failure recovery for service integration
are two difficult issues. In the Ninja Architecture,
services are monitored and paths are dynamically
changed to guarantee optimal services (Gribble, et
al., 2001). Another example is a service integra-
tion architecture based on software hot-swapping
technology proposed by Mennie and Pagurek
(Mennie & Pagurek, 2000). Dabrowski, et al.