Excerpt
Technische Universität München
Lehrstuhl für Kommunikationsnetze
Prof. Dr.-Ing. Jörg Eberspächer
Diplomarbeit
Development and Implementation
of a Service Access Concept
Diplomand:
Michael Fischer
Beginn:
16. Juli 2000
Abgabe:
15. Juni 2001
Abstract
Successive to a preceding study about Service Discovery, this thesis covers the topics
Service Description and Service Access. Starting with an analysis and comparison of
existing technologies, a new protocol for the service access was developed and an oper-
ating environment, capable of accessing services of any type was programmed. Thereby
emphasis is placed on high scalability, extensibility, modularity and comprehensive
documentation, to provide easy association with existing or future works.
The first part deals with the various versions of Service Descriptions, followed by a
description of the service access methods and concluding with a comprising compari-
son. All technologies or protocols qualified for Service Discovery and Access discovered
during this diploma thesis are discussed.
The main part comprises the software implementation which was written in Java, in-
cluding a comprehensive documentation containing, among others, the protocol speci-
fication, software architecture, an user guide and proposals for advancements.
Zusammenfassung
Aufbauend auf einer vorangegangenen Arbeit über Service Discovery, werden in dieser
Diplomarbeit die Themen Service Description und Service Access behandelt. Beginnend
mit einer Analyse und dem Vergleich existierender Techologien, wurde ein neues Pro-
tokoll für den dynamischen Dienstzugriff entwickelt und eine funktionsfähige Umge-
bung programmiert, die mittels dieses Protokolls auf Dienste jeglicher Art zugreifen
kann. Dabei wurde das Augenmerk auf eine hohe Skalierbarkeit, Erweiterbarkeit, Mo-
dularität und umfassende Dokumentation gelegt, so daß es nicht schwer fallen sollte,
die Software mit folgenden oder existierenden Arbeiten zu verknüpfen.
Im ersten Teil wird auf die verschiedenen Varianten der Dienstbeschreibungen einge-
gangen, gefolgt von einer Beschreibung der Dienstzugriffe und anschließend einem zu-
sammenfassenden Vergleich. Aufgeführt sind dabei alle für Service Discovery und Ac-
cess geeigneten Technologien, bzw. Protokolle, die im Rahmen der Diplomarbeit aufge-
funden wurden.
Der Hauptteil der Arbeit umfaßt die Implementierung der Software, die in Java ge-
schrieben wurde, inklusive einer umfassenden Dokumentation dazu, die unter ande-
rem die Protokollspezifikation, die Architektur der Software, eine Bedienungsanleitung
und Vorschläge zur Weiterentwicklung beinhaltet.
Contents
1 Introduction
1
1.1
Topic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.2
Content . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1
1.3
How to Read This Paper . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
2 General
5
2.1
Introducing Reflections . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.1.1
A Possible Scenario . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.1.2
Ad Hoc Networking . . . . . . . . . . . . . . . . . . . . . . . . . . .
5
2.1.3
State of the Art . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.1.4
Future Situation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6
2.1.5
Reflections About Service Discovery, Description and Access . . .
8
2.2
The Problem of automated Interaction . . . . . . . . . . . . . . . . . . . . .
9
2.3
Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.1
Service Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.2
Service Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.4
URLs/URIs/URNs, Namespaces . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.1
URI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.4.2
URL . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4.3
URN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
2.4.4
Comparison URN - URL . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5
Overview of the Different Techniques . . . . . . . . . . . . . . . . . . . . . 13
i
ii
CONTENTS
2.5.1
SLPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.5.2
UPnP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.5.3
Jini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5.4
Salutation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5.5
JetSend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5.6
Inferno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
2.5.7
SDP (Bluetooth) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3 Service Description
17
3.1
SLPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.1.1
The Service-URL, Accessing SLP . . . . . . . . . . . . . . . . . . . . 18
3.1.2
Abstract Service Types . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.3
Definition of Attributes . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.4
Mandatory Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.1.5
Registration and Standardization of New Service Types . . . . . . . 20
3.1.6
Explanatory Example . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.2
UPnP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.2.1
Device Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
3.2.2
Service Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.2.3
Template Design Process . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.2.4
Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3
Jini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.1
Service Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.2
Remarks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.3
Description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.4
Salutation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.4.1
Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4.2
Service Description/Capability Exchange . . . . . . . . . . . . . . . 31
3.4.3
Functional Unit Description . . . . . . . . . . . . . . . . . . . . . . . 32
CONTENTS
iii
3.4.4
Attribute Description . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4.5
Description Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.5
JetSend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.6
Inferno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.7
SDP (Bluetooth) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.7.1
Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.7.2
Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
3.7.3
Service Record . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.7.4
UUIDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.7.5
Data Elements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
3.7.6
Universal Attributes . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
4 Service Access
41
4.1
SLPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2
UPnP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
4.2.1
Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
4.2.2
Example for Control: Action:Invoke . . . . . . . . . . . . . . . . 42
4.2.3
Eventing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2.4
Example for an Event:Notify . . . . . . . . . . . . . . . . . . . . 43
4.2.5
Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
4.2.6
Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3
Jini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3.1
Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
4.3.2
Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3.3
Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
4.3.4
Implementation Example . . . . . . . . . . . . . . . . . . . . . . . . 47
4.4
Salutation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.4.1
Open Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
4.4.2
Transfer Data . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
iv
CONTENTS
4.4.3
Close Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
4.4.4
Summary of RPC Calls of the SLM-API . . . . . . . . . . . . . . . . 49
4.4.5
Salutation Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . 51
4.5
JetSend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.6
Inferno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.6.1
General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
4.6.2
External Environment . . . . . . . . . . . . . . . . . . . . . . . . . . 54
4.6.3
Styx . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.6.4
Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
4.7
SDP (Bluetooth) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
5 Comparison of the Different Protocols
57
5.1
Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5.2
(Dis)Advantages of the Protocols . . . . . . . . . . . . . . . . . . . . . . . . 57
5.2.1
SLPv2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.2.2
UPnP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
5.2.3
Jini . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
5.2.4
Salutation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
5.2.5
JetSend . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.2.6
Inferno . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
5.2.7
SDP (Bluetooth) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
6 Implementation of the SAP Project
65
6.1
Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.1.1
Motivation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
6.1.2
Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.1.3
Used Technologies . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
6.2
SAP Protocol Specification . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
6.2.1
Common Topics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
CONTENTS
v
6.2.2
Answer Message . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
6.2.3
Features and Limitations . . . . . . . . . . . . . . . . . . . . . . . . 68
6.2.4
The Tags . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
6.3
Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.3.1
External Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
6.3.2
Internal Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
6.4
Integration with Service Discovery . . . . . . . . . . . . . . . . . . . . . . . 75
6.4.1
Common Integration Topics . . . . . . . . . . . . . . . . . . . . . . . 75
6.4.2
SLP Integration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
7 Conclusions and Outlook
79
7.1
Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
7.2
Further Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
A Notation and Abbreviations
81
B Userguide
85
B.1 User Guide . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
B.2 General . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
B.3 Compiling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
B.3.1
Compiling the Java Sources . . . . . . . . . . . . . . . . . . . . . . . 86
B.3.2
Compiling the C Client . . . . . . . . . . . . . . . . . . . . . . . . . 86
B.3.3
Creating the Documentation . . . . . . . . . . . . . . . . . . . . . . 86
B.4 Running . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
B.4.1
Easy Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
B.4.2
Manual Approach . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
B.5 Usage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
B.5.1
Serverside Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
B.5.2
Clientside Programs . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
B.6 Usage in External Software . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
vi
CONTENTS
B.7 Module Programming . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
B.7.1
Modules Written in Java . . . . . . . . . . . . . . . . . . . . . . . . . 88
B.7.2
Modules in Other Languages . . . . . . . . . . . . . . . . . . . . . . 89
B.7.3
Binding Modules to the SAS . . . . . . . . . . . . . . . . . . . . . . 89
B.8 Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
B.8.1
Addierer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
B.8.2
Print . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
B.8.3
Parport . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Chapter 1
Introduction
1.1 Topic
As computing continues to grow to a network centric model, finding and making use
of services that may be available in the network becomes increasingly important. Ser-
vices can include common ones like printing, faxing, paging and so on, as well as var-
ious kinds of information access such as teleconferencing, network bridges and access
points, eCommerce facilities and so on - most any kind of service that a device or service
provider might offer. In addition to the need for a standard way of discovering avail-
able services, there are other considerations: getting access to the services (by finding
and obtaining the protocols, access methods or "drivers" and other code necessary to
utilize the service), controlling access to the services, advertising the services, choosing
among competing services, billing for services, and so on. This problem is widely rec-
ognized. Many companies, standards bodies, and consortia are addressing it at various
levels in various ways. Service Location Protocol (SLP), Jini, and Salutation, to name
just a few, all address some aspects of service discovery. [SIG01b]
1.2 Content
This paper is divided into 7 chapters.
The first half of this thesis will give an overview of all available technologies that face
the topic of service description and access. It is not dealt with network configuration
and discovery, the latter is already described in the preceding work [Ren00]. The main
part of this thesis is the creation of an access environment, where a new protocol is to
be developed and a running system has to be implemented.
2
CHAPTER 1. INTRODUCTION
Following this chapter, common topics and reflections concerning discovery, access and
their location in today's networking environment are made in Chapter 2.
Service Discovery is not discussed here, as far as the location itself is concerned (there-
fore see [Ren00]). Service description which is usually a part of the discovery protocols
is explained in Chapter 3. The different techniques for service access are described in
Chapter 4.
Chapter 5 contains an overall view and comparison of the different service discovery
and access protocols.
All sections concerning the same protocol have the same minor section number
througout the whole document.
The main focus of this work lies on an implementation of a self-designed access technol-
ogy, which is described in Chapter 6. Besides, this thesis includes the software imple-
mentation described in Chapter 6 and a documentation framework within the software
package. This documentation framework contains everything of Chapter 6 and fur-
thermore a detailed description of the programmed works like APIs, class descriptions,
detailed todo and bug lists, which are only partially included in this paper.
The concluding outlook is to be found in Chapter 7, notations and abbreviations are
found in Appendix A.
1.3 How to Read This Paper
In general, many notions and abbreviations are explained in Appendix A, so if a term
is unfamilar and not explained in the continuous text, check Appendix A first.
If the topics of Ad Hoc Networking, Service Discovery and Service Access are not
familar to you, please read section 2.1 and appendix A, if appropriate.
If you only want to look at problems challenged by Service Discovery and Access with-
out (many) technical details please read Sections 2.1, 2.2, 6.1.1 and the Outlook (Chapter
7).
To engage with the software only, start with Chapter 6 and Appendix B since the
project documentation is a must.
In order to get a deeper taste of the protocols please read Chapters 3 and 4, but they
won't supercede the lecture of the original specification, if you intend to work with or
implement one of these protocols. It might be useful to know something about URLs
and namespaces beforehand, catered to in Section 2.4. To get a quick impression it
is often helpful to look at the examples first which are provided within each protocol
section.
1.3. HOW TO READ THIS PAPER
3
For a short overview of the different protocols have a look in Chapter 5, where some
abilities and (dis)advantages are listed. For a closer overview compare the examples
provided in each section for each protocol in Chapters 3 and 4.
If you intend to deal with different protocols it's recomended to start with Table 5.1 in
Chapter 5 on Page 58. This way one will avoid being puzzled by different diction, as ev-
ery specification of a protocol usually has its own nomenclature. Also, one will be able
to classify things between different techniques faster and an overview is recommended
anyway.
Chapter 2
General
2.1 Introducing Reflections
2.1.1 A Possible Scenario
Suppose you are a consultant, doing your daily duties, visiting customers, serving their
needs, it is often very helpful if you can access to an environment you are used to. Such
a environment might be provided by your notebook which needs access to network
services like the WWW or services provided by your customer, for example a printer.
Of course, you have many various customers possessing different types of networks
and services. After your notebook connected to the customers network wireless and
automatically, you call your service browser and check which services are available to
you. The browser uses a general service discovery method for this purpose. If you like
to have a document printed, it is up to you to select a printer. In further future, your
printing application might check the printers itself and automatically access a printer
which is close to you. This will be accomplished by a common service access method
which is also capable of accessing any other device. Of course, this is only a small
snapshot of our future scenario of life, but it gives a good taste of how future technology,
which is the subject in this thesis, could change our way of life.
2.1.2 Ad Hoc Networking
Mobile computing is an issue which will become more and more important in the fu-
ture, possibly even completely superceeding the wired local network environments.
This is necessary to fulfill the needs for an untethered, ubiquitous communication en-
vironment. Facing the technical constraints of these networks, like the diversity of de-
vices, their capabilities, resources, interfaces, as well as the vast variety of services, new
6
CHAPTER 2. GENERAL
concepts have to be taken into account for these so-called Ad Hoc Networks. These are
"network[s] formed without any central administration which consists of mobile nodes
that use a wireless interface to send package data. Since the nodes in this network can
serve as routers and hosts, they can forward packets on behalf of other nodes and run
user applications." [FJL00] They tag themselves by a dynamic topology, which stands
for spontaneity and quick changes.
In particular, challenges for mobile computing compared to traditional wired networks
(and their protocols) are [Ill00]:
¯
Higher Error Rates
¯
Variable Latency
¯
Frequent Disconnection
¯
Mobility
¯
Speed of Connection and Data Transfer Rate
Besides these low level challenges, needs for new concepts on application levels are
applicable as well. This thesis points out to one of these concepts: Dynamic Service
Discovery and Service Access.
2.1.3 State of the Art
If an user wants to utilize a service, he usually has to initiate several steps manually:
1. Connect to the appropriate network (e.g. connect to ethernet, by plugging in a
cable and configure the IP address).
2. Gain knowledge about the existence and capabilities of a service (e.g. by asking
the administrator).
3. Configure his device for the use of a specific service (by installing a device driver,
loading a program or use a standard protocol if appropriate).
4. Access the service and retrieve an answer in a native (or the driver's) language.
It is obvious that a replacement of this procedure is preferred beyond Ad Hoc Networks
as well, and not restricted to them.
2.1.4 Future Situation
The automated dynamic access procedure comprises four steps:
2.1. INTRODUCING REFLECTIONS
7
1. Network configuration: Establishing a functioning network link.
2. Service Discovery: Discover existing service(s).
3. Service Description: Obtaining the description of a service.
4. Service Access: Access this service.
Ad Hoc Networking affects different layers of the communication hierarchy, such as:
Network layer
This layer is responsible for the low level communication in a net-
work. Zero configuration now affords the automatic assignment of the communication
parameters. For example in TCP/IP based networks it's the IP address, which is as-
signed using DHCP [Dro97].
Infrastructure layer
This layer supports the exchange of information about service
providers (services) and service users (clients). Service description and the protocols
for discovery in general are topic of this layer.
Application layer
Services access is part of this layer, because it normally is an ap-
plication which accomplishes the access. But the utilisation of the service is possibly
influenced by the infrastructure layer on which a previous discovery took place.
Service Broker
Service Offeror
Service User
1) Registration
2) Request
3) Description
4) Access
3
2
4
1
Figure 2.1: Service Discovery/Access Procedure
Figure 2.1 shows the most common procedure of a service mediation. It starts with the
service (provider) registrating itself by a central service repository instance, which will
then answer requests from clients for certain services. The client initiates the access
himself, after receiving the service description (including the necessary information of
how to access the service). Sometimes, service discovery is accomplished without a
8
CHAPTER 2. GENERAL
central repository. In this case, client requests are sent directly to the service (providers)
via broadcasts.
2.1.5 Reflections About Service Discovery, Description and Access
2.1.5.1 Service Description
The purpose of Service Discovery and Access is to provide the capability of using ser-
vices or devices without configuration like networksettings or loading device drivers.
Service Discovery will detect services upon request or availability, whereas Service Ac-
cess will interact with the service independently from native protocols or operating sys-
tems.
The most important features of a discovery protocol are [McG00]:
¯
"Spontaneous" discovery and configuration of network devices and services
¯
Selection of specific types of service
¯
Low (preferably no) human administrative requirements
¯
Automatically adaptation to mobile and sporadic availability
¯
Interoperability across manufacturers and platforms
¯
Interoperatibility across multiple transport mechanisms. Especially embedded
systems or domestic appliances are not usually connected to ethernet or other
TCP/IP capable networks
2.1.5.2 Service Description
The purpose of a service description may vary, depending on the concrete use case. For
example, a human who wants to know the semantics of a service has a different view
from that of a (machine) client who wants to access the service. Even (machine) clients
may have different views, depending on their requests and interfaces. So the idealized
general purpose of a service description is to represent all these possible views. This
also includes views on services, which are not known by clients a priori. A semantic
description is required to enable yet unknown combinations. This is a very difficult
topic, which is treated in AI (Artificial Intelligence), e.g. [AIT], by the use of conceptual
graphs [PG00].
Known services can be described syntactically by specified interfaces. The selection of
a service is easier in this case, simply by finding a fitting interface from the amount of
available interfaces. All discovery protocols work in this manner.
2.2. THE PROBLEM OF AUTOMATED INTERACTION
9
In any case, a good concept of classifying services into different service types is not only
mandatory for a semantic description without a priori knowledge, it also simplifies the
traditional usage. Therefore some protocols allow descriptions inherited from others
and form a hierarchical structure, often represented via URIs for an unique namespace
(see 2.4).
2.1.5.3 Service Access
Access is an issue which, of course, is not new. The problem is not the access to a service,
but the vast variety of ways, the different services can be accessed. Surprisingly most
disquisitions on service discovery do not treat service access, because this seems to be
quite clear and accomplishable by existing protocols. In practice, however, this is not an
approach leading to ubiquitousness, because a client willing to access different services
(that he finds using a discovery protocol) has to be able to understand all protocols
necessary to access these services.
2.2 The Problem of automated Interaction
Automated interaction between devices should reduce user efforts to get a process run-
ning, in the best case, to zero. This requires a notable amount of intelligence, which lies
between the discovery and the access, or the discovery request. It is usually forgotten
within the topic of service access that the client, nevertheless, must always have a clear
idea of the meaning of functionality of a service, otherwise intelligent access will not be
usefully accomplished. This means, although a client (computer) knows the interface
capabilities of a service, it will not be able to reasonably access a service by itself. For
instance a computer (which is a "stupid" machine) won't access a printer, because he
doesn't know what a printer is or its function. The simple description information that
a printer is a device which can receive data is not sufficent for automatic and intelligent
access.
There are three possible approaches to fill this gap:
¯
Invention/Implementation of Artificial Intelligence (AI): The computer now "knows"
the meaning of the services. (Futuristic)
¯
Human Interaction: A human invokes the access, i.e. choosing a service from a
service browser (and providing occurring parameters by hand)
¯
Programmed Structures: The access follows certain rules which have been set up,
i.e. "print" always tries to access the nearest printer (assumed the distance can be
measured or calculated), or an alarm clock starts the coffee machine, every time
the alarm sounds (or some minutes in advance).
10
CHAPTER 2. GENERAL
Obviously, though, automatic connection efforts, which exeeds the bounds are unwel-
come, for example suppose our alarm clock always tries to percolate coffee without
allowing a lowbrow user to easily stop this interaction.
It is misleading, in the authors opinion, to announce devices that will connect and inter-
act with each other without configuration. Somebody must set the rules for interactions.
Conclusion: The benefit from service access technology is vendor and driver indepen-
dence, but not device independence!
2.3 Use Cases
"In essence, a use case is a typical interaction between an user and a computer system."
[Fow97] Appropriate use cases for each part of the service discovery/access procedure
are listed in the following. Of course, this list is not intended to be complete. Also, the
interpretation what is (worth) a use case and what now, depends on ones view. Some
use cases are not applicable on certain services, depending on their business logic.
2.3.1 Service Discovery
¯
Find a specific service type.
¯
Find services with specific attributes.
¯
Retreive a method to access the services.
¯
Obtain service description, determine the capabilities.
¯
Service browsing (means: look what services are there or available).
¯
Catalog available services (by central service repository).
¯
Obtain notification when a new service becomes available.
¯
Check availability of services.
¯
Service leasing.
2.3.2 Service Access
¯
Invoke actions on services (including optional feedback).
2.4. URLS/URIS/URNS, NAMESPACES
11
¯
Data transfer to a service and/or from a service. This includes any parameters,
like ordinary data types, files or streams. (Usually combined with an action invo-
cation.)
¯
Obtain specific state variable of service.
¯
Obtain common state (or description) of service.
¯
Obtain notification on status changes by subscribing to an event.
2.4 URLs/URIs/URNs, Namespaces
The operation of the World Wide Web and its interoperability between platforms of dif-
fering hardware and software manufacturers depend on the specifications of protocols
such as HTTP, data formats such as HTML, and other syntaxes such as the URL or,
more generally, URI specifications. Behind these specifications lie some important rules
of behaviour which determine the foundation of the properties of the web. The web is a
universal information space. It is a space in the sense that things in it have an address.
The "addresses", "names" or, as we call them here, identifiers, are the subject of this
section. They are called Universal Resource Identifiers (URIs) which is a superordinate
concept for URLs, URNs. [Pay96]
2.4.1 URI
The syntax of an URI is defined as follows (see RFC 1630[BL94]):
<uri> ::= <scheme>":"<scheme-specific-part>
<scheme>
specifies the namescheme and namespace for the URI
<scheme-specific-part>
identification according to <scheme> definition
URIs may consist of either:
¯
Names: Uniform Resource Name (URN)
¯
Locations/Adresses: Uniform Resource Locator (URL)
¯
Metainformation/Description: Uniform Resource Characteristic (URC)
In most cases the <scheme> definitions, which is the "protocol" in most cases, are ad-
ministrated by the Internet Assigned Numbers Authority (IANA).
12
CHAPTER 2. GENERAL
XML Namespaces
An XML namespace is a collection of names, identified by a URI reference (see RFC2396
[BLFIM98]), which are used in XML documents as element types and attribute names.
XML namespaces differ from the "namespaces" conventionally used in computing dis-
ciplines in that the XML version has internal structure and is not, mathematically spo-
ken, a set. [BHL99]
2.4.2 URL
Everyone who surfs the web is familar with the term "URL" (Uniform Resource Loca-
tor). Its purpose is to specify the location of a document and to allow access to such a
resource on the net.
Insufficiencies of URLs occur, when:
1. A resource, e.g. an informational text, may have many copies allover the net,
deposited in various types (txt, pdf, doc) and accessible with various protocols
(e.g. FTP, HTTP). Each combination would lead to a new URL, so an URL is not
necessarily unique, and it is not possible to identify a document by its URL.
2. The host address changes, because the (sub)domain name has changed or the site
has moved or is restructured.
3. The access method changes, e.g. from HTTP to HTTPS.
URL <scheme> definitions are available for many protocols (HTTP, FTP, LDAP, ...)
the <scheme-specific-part> has a general form of:
["//"] [user [":"password] "@"] host [":"port] ["/"url-path]
which can be restriced for a specific scheme.
2.4.3 URN
To suit the lacks of URLs, there are different approaches, other than the Dublin Core
Metadata Modell and the Persistent Uniform Locator[Pay96], URNs are evoluting. This
system can be found on other playgrounds too, for instance the ,,Classpath strucure" of
Java.
The Syntax of an URN is defined as follows (see RFC 2141[Moa97]):
URI-scheme: <scheme> ::= "urn"
<urn> ::= "urn:" <nid> ":" <nss>
Excerpt out of 106 pages
- Quote paper
- Michael Fischer (Author), 2001, Development and Implementation of a Service Access Concept, Munich, GRIN Verlag, https://www.grin.com/document/185645
Similar texts
Publish now - it's free
✕
Excerpt from
106
pages
Comments