Development and Implementation of a Service Access Concept

Contents

1 Introduction
1.1 Topic
1.2 Content
1.3 How to Read This Paper

2 General
2.1 Introducing Reflections
2.1.1 A Possible Scenario
2.1.2 Ad Hoc Networking
2.1.3 State of the Art
2.1.4 Future Situation
2.1.5 Reflections About Service Discovery, Description and Access . . .
2.2 The Problem of automated Interaction
2.3 Use Cases
2.3.1 Service Discovery
2.3.2 Service Access
2.4 URLs / URIs / URNs, Namespaces
2.4.1 URI
2.4.2 URL
2.4.3 URN
2.4.4 Comparison URN - URL
2.5 Overview of the Different Techniques
2.5.1 SLPv2
2.5.2 UPnP
2.5.3 Jini
2.5.4 Salutation
2.5.5 JetSend
2.5.6 Inferno
2.5.7 SDP (Bluetooth)

3 Service Description
3.1 SLPv2
3.1.1 The Service-URL, Accessing SLP
3.1.2 Abstract Service Types
3.1.3 Definition of Attributes
3.1.4 Mandatory Attributes
3.1.5 Registration and Standardization of New Service Types
3.1.6 Explanatory Example
3.2 UPnP
3.2.1 Device Description
3.2.2 Service Description
3.2.3 Template Design Process
3.2.4 Example
3.3 Jini
3.3.1 Service Architecture
3.3.2 Remarks
3.3.3 Description
3.4 Salutation
3.4.1 Architecture
3.4.2 Service Description / Capability Exchange
3.4.3 Functional Unit Description
3.4.4 Attribute Description
3.4.5 Description Format
3.5 JetSend
3.6 Inferno
3.7 SDP (Bluetooth)
3.7.1 Structure
3.7.2 Discovery
3.7.3 Service Record
3.7.4 UUIDs
3.7.5 Data Elements
3.7.6 Universal Attributes

4 Service Access
4.1 SLPv2
4.2 UPnP
4.2.1 Control
4.2.2 Example for Control: Action:Invoke
4.2.3 Eventing
4.2.4 Example for an Event:Notify
4.2.5 Security
4.2.6 Summary
4.3 Jini
4.3.1 Considerations
4.3.2 Features
4.3.3 Security
4.3.4 Implementation Example
4.4 Salutation
4.4.1 Open Service
4.4.2 Transfer Data
4.4.3 Close Service
4.4.4 Summary of RPC Calls of the SLM-API
4.4.5 Salutation Architecture
4.5 JetSend
4.6 Inferno
4.6.1 General
4.6.2 External Environment
4.6.3 Styx
4.6.4 Security
4.7 SDP (Bluetooth)

5 Comparison of the Different Protocols
5.1 Features
5.2 (Dis)Advantages of the Protocols
5.2.1 SLPv2
5.2.2 UPnP
5.2.3 Jini
5.2.4 Salutation
5.2.5 JetSend
5.2.6 Inferno
5.2.7 SDP (Bluetooth)

6 Implementation of the SAP Project
6.1 Overview
6.1.1 Motivation
6.1.2 Features
6.1.3 Used Technologies
6.2 SAP Protocol Specification
6.2.1 Common Topics
6.2.2 Answer Message
6.2.3 Features and Limitations
6.2.4 The Tags
6.3 Architecture
6.3.1 External Architecture
6.3.2 Internal Architecture
6.4 Integration with Service Discovery
6.4.1 Common Integration Topics
6.4.2 SLP Integration

7 Conclusions and Outlook
7.1 Conclusions
7.2 Further Development

A Notation and Abbreviations

B Userguide
B.1 User Guide
B.2 General
B.3 Compiling
B.3.1 Compiling the Java Sources
B.3.2 Compiling the C Client
B.3.3 Creating the Documentation
B.4 Running
B.4.1 Easy Approach
B.4.2 Manual Approach
B.5 Usage
B.5.1 Serverside Programs
B.5.2 Clientside Programs
B.6 Usage in External Software
B.7 Module Programming
B.7.1 Modules Written in Java
B.7.2 Modules in Other Languages
B.7.3 Binding Modules to the SAS
B.8 Examples
B.8.1 Addierer
B.8.2 Print
B.8.3 Parport

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.

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

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:

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.

illustration not visible in this excerpt

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

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.

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).

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).

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).

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>

<nid> is the Namespace Identifier

<nss> is the Namespace Specific String

URNs are resolved to URLs (or URCs) by the principle shown in figure 2.2, but there isn’t a specification for resolving yet.

illustration not visible in this excerpt

Figure 2.2: URN Resolving

2.4.4 Comparison URN - URL

illustration not visible in this excerpt

Table 2.1: Comparison URN-URL

2.5 Overview of the Different Techniques

2.5.1 SLPv2

SLP is a protocol invented by Sun Microsystems and now hosted and developed by the Internet Engineering Task Force (IETF) Srvloc Working Group (http://www.srvloc.

org). Version 2 is available since June 1999. The goal is a precise description of elements of service advertisements (i.e. the service type and attributes). The discovery mecha- nisms and capabilities are specified in RFC 2608 [GPVD99], how services are described and classified in RFC 2609 [GPK99]. SLP’s messages and descriptions all rely on the basis of a text format.

The preceeding thesis [Ren00] deals mainly with this technology. Industrial products are already being shipped using SLP version 1 and other access protocols, because SLP is not capable of service access.

2.5.2 UPnP

Universal Plug and Play (UPnP) is an approach initiated and mainly influenced by Mi- crosoft. Nevertheless, it is an open standard and hosted by the UPnP Forum, an in- dustry initiative designed to enable easy and robust connectivity among stand-alone devices and PCs from many different vendors. Vendors are called to become Univer- sal Plug and Play Forum members and participate in the process of designing schema templates for their device classes.

Although it is said that UPnP is developed by an independent consortium, it seems to be mainly influenced by Microsoft including the inability to download the UPnP specification with Netscape, due to illegal use of plain whitespaces in the URL, instead of URL-encoding them like defined in RFC 1738 [BLMM94]. Hopefully this is not a foretaste of the proposed interoperability and vendor independency!

Although the version 1.0 of the specification [Mic00] is out foremost since june 2000, UPnP is already included in Windows ME.

Service discovery and access with UPnP consists of six steps:

1. Addressing: Obtaining an IP address with DHCP or AutoIP.
2. Discovery: Finding services using the Simple Service Discovery Protocol (SSDP).
3. Description: Describing the attributes and capabilities of a service or device.
4. Control: Accessing services and trigger actions with the Simple Object Access Pro- tocol (SOAP)
5. Events: Notification about changes of service parameters by registration of events using the Generic Event Notification Architecture (GENA)
6. Presentation: Simply a HTTP based documentation of the service or device.

UPnP uses XML for its messages and descriptions, which allows nested structures, e.g. interleaved attributes instead of a plain enumeration and an easy processing of its con- tent in following applications.

2.5.3 Jini

The Java Intelligent Network Interface (Jini) is a Java based solution conceived by Sun Mi- crosystems designed for dynamic service mediation. Therefore, all devices supporting Jini have to run a Java Virtual Machine (JVM). Jini was presented in January 1999 and, because of Sun’s advertising, is the most widely known technology of today. The spec- ification is open and may freely be used under the Sun Community Source License; however, Sun charges a licensing fee for usage of Jini in commercial products.

Another master thesis at the Institute deals with Jini in detail [Leg00].

2.5.4 Salutation

The Salutation Consortium, a 30+ member non-profit corporation, announced Saluta- tion Architecture V2 in June 1996. The Salutation Architecture eases the exchange of information regarding Internet peripherals and devices, and is independent of network transport, hardware platform and operating system software.

Different scenarios are presented on the salutation homepage (http://www.salutation. org/scenario).

A maintained Salutation-Lite implementation is freely available for some platforms, in- cluding Java, on the salutation homepage (http://www.salutation.org).

2.5.5 JetSend

JetSend is a “dead” technology, because it is no longer supported by HP, which invented and maintained JetSend. Products have already been shipped in combination with SLP version 1, because JetSend is not capable of service discovery.

2.5.6 Inferno

Inferno was originally developed at Bell Labs (the research division of Lucent Tech- nologies) and is now shipped by Vitanuova. It is a well designed, economical operating system particularly suitable for use in networked devices such as advanced telephones, hand-held devices, TV set-top boxes and many other embedded applications. Due to its common interface concept appliances for service access could be accomplished with Inferno as well. License fees are charged for some core parts of Inferno, otherwise it is freely available.

2.5.7 SDP (Bluetooth)

The expression Bluetooth is already a well known term to the public, more because of the inconvenient parentage of its name (an ancient Danish king) and its proposed revolutionary power, although commercial products are only announced till now. The foundation of the Bluetooth Special Interest Group (SIG) in 1998 (about 2000 members today) aimed at creating a de facto standard, to serve new communicational needs of mobile devices. The reason for the large number of memberships is mainly because only by this membership the use of technical informations and specifications is allowed. Included is the obligation to respect the specifications, which the vendor has to prove in tests, what is elementary necessary for a trouble and constraint free interaction of devices [Irr00].

The Bluetooth protocol stack builds the basis for different technologies serving different layers, its core being the Service Discovery Protocol (SDP) which addresses service discov- ery specifically for the Bluetooth environment. It is optimized for the highly dynamic nature of Bluetooth communications. SDP focuses primarily on discovering services available from or through Bluetooth devices. It does not define methods for accessing services. This has to be accomplished by accessing the service directly, or via another service access protocol. Service discovery within Bluetooth devices is not restricted to SDP, other discovery protocols can also (co)exist.

Chapter 3 Service Description

Content

Service discovery includes not only the discovery of a service, but usually the retrieval of a service description as well. Contents of these descriptions mostly include the ser- vice’s:

Capabilities

Verbal description

Information and parameters necessary to access

Templates

Often services are described in form of a template, which will be filled in with the con- crete service information. In the following, it is explained how each protocol defines its service templates and descriptions.

Templates are used for the following distinct purposes:

1. Standardization: The template will be reviewed before it is standardized by any authority who it concerns, thus creating a service type classification.
2. Service Registration: Services participating in a service discovery environment have to be registered by a central repository (if applicable). They use the templates to generate the service registrations. In registering the service must use the specified values for its attributes.
3. Client presentation of Service Information: Client applications may display service information. The template provides type information and explanatory text which may be helpful in producing user interfaces.
4. Internationalization: Entities with access to the template for a given service type in two different languages may translate between the two languages. A service may register itself in more than one language using templates, though it has been configured by an operator who registered service attributes in a single language.

3.1 SLPv2

As specified in RFC 2609 a service template is: “A formal description of the service attributes and service scheme, associated with a particular service type.” [GPK99] It might be helpful to have a look at the trailing example simultaneously while reading this chapter, which has mostly been taken from this RFC. Reading the RFC for designing own templates is recommended, because all subjects. are not dealt with in detail here.

In SLP, services are advertised and described by use of a Service URL and a Service Tem- plate.

3.1.1 The Service-URL, Accessing SLP

It might be helpful to read something about URL’s in common, see Section 2.4. According to explanations in this former section, SLP-URLs have the following scheme:

<scheme> ::= "service". The service <scheme-specific-part> provides in- formation necessary to access the service. The form of a service-URL is as follows:

service-URL = "service:" service-type ":" site url-path [attr-list]

Whereas the attr-list is not mandatory and can be composed as a list of semicolon separated attribute assignments of the form: attr-id "=" attr-value or for key- word attributes: attr-id

An example for a service-URL might look like:

service:printer:lpr://server.sun.com/public-printer;

printer-color-supported=true

Attributes associated with the service-URL are not typically included inside of it. They are stored and retrieved using other mechanisms. The service-URL is uniquely iden- tified with a particular service agent or resource, and is used when registering or re- questing the attribute information. The latter part of the service-URL can specify device dependent information, whereas the service type’s synax is unitary.

3.1.2 Abstract Service Types

Abstract service types are comparable to superclasses in Object Orientated Languages. Common attributes in a class of services can be defined and summarized here. Usually abstract types are not used for concrete services. It is possible to search for an abstract service type in order to receive all subsidiary (concrete) ones.

3.1.3 Definition of Attributes

All attributes inside a service description document are separated from each other by having a blank line in between.

A normal attribute looks like the following:

id "=" type [flags] [\CR default-value-list] [\CR Help-text]

[\CR Allowed-value-list]

The id functions is the name of the attribute and is restricted to characters considered for inclusion of a URL according to RFC 2396 [BLFIM98]. "\CR" means Carriage-Return (=newline).

The type might be either “string”, “integer”, “boolean”, “opaque” (for binary data, ex- pressed by escaped byte values) or “keyword” (valueless (and flagless) attribute)

The flags consist of the (multiple) entries: “O” (Optional), “M” (Multiple values possi- ble), “L” (attr. is literal and should not be translated), “X” (indicates that clients should include this attribute).

3.1.4 Mandatory Attributes

The attributes template-type, template-version, template-description and

template-url-syntax are mandatory:

Template-type defines the service type name.

Template-version specifies the version number of the template, where major num- bers with 0 are draft proposals, minor number differences show (upward) compatible changes, where usually only an addition of optional attributes takes place. Additionally, a naming authority can be applied, default would be IANA.

Template-description is a block of text readable by people in the language of the template.

Template-URL-Syntax is the syntax of the service type specific URL part of the ser- vice URL, for instance a lpr printer template should force a statement for the printer queue here.

3.1.5 Registration and Standardization of New Service Types

When the development of a new service template reaches the step to the first release version 1.0, it has to be submitted to a mailing list: srvloc-list@iana.org, where the tem- plate is reviewed by the Service Working Group. Once consensus is achieved and the template is corrected, the template is submitted to IANA (Internet Assigned Numbers Authority) for registration. This is done by an appointed reviewer, who has to con- firm that all clarification requests are satisfied. For more details about writing IANA considerations see RFC 2434 [NA98] .

The service template submission must be of the form:

Name of submitter:

Language of service template:

Security Considerations: Template Text:

---------------template begins here---------------

. . .

---------------template ends here-----------------

The service template file has a naming convention:

<service-type> "." <version-no> "." <langtag>

3.1.6 Explanatory Example

The files for the following example templates in this chapter are called:

"Net-Transducer.0.0.en"

"Net-Transducer:Thermometer.0.0.de"

"Net-Transducer:Thermomoter.0.0.en"

To get a better impression of how a service template looks, an example is given. The example designs templates for a thermometer transducer.

First an abstract service type template for transducers in general is designed.

-------template <Net-Transducer.0.0.en> begins here--------- template-type=Net-Transducer

template-version=0.0

template-description=

This is an abstract service type. The purpose of the Net- Transducer service type is to organize into a single category all network enabled Transducers which have certain properties.

template-url-syntax=

illustration not visible in this excerpt

sample-units= string L

# The units of sample that the Transducer provides, for instance

# C (degrees Celsius), V (Volts), kg (Kilograms), etc. sample-resolution= string L

# The resolution of the Transducer. For instance, 10ˆ-3 means

# that the Transducer has resolution to 0.001 unit. sample-rate= integer L

# The speed at which samples are obtained per second. For

# instance 1000 means that one sample is obtained every

# millisecond.

-----------------template ends here-----------------

A deducted template for a concrete service type, a thermometer, might look like the following:

-----------------template begins here--------------- template-type=service:Net-Transducer:Thermometer

template-version=0.0 template-description=

The Thermometer is a Net-Transducer capable of reading temper-

ature. The data is read by opening a TCP connection to one of the ports in the service URL and reading an ASCII string until an NULL character is encountered. The client may continue reading data at no faster than the sample-rate, or close the connection.

template-url-syntax=

url-path = "ports=" ports-list port-list = port / port "," ports port = 1*DIGIT

; See the Service URL <port> production rule.

; These are the ports connections can be made on. location-description=string

# The location where the Thermometer is located.

operator=string O

# The operator to contact to have the Thermometer serviced.

-----------------template ends here----------------

This template can be internationalized by registering another version, eg. in German:

----template <Net-Transducer:Thermomoter.0.0.de> begins here---

template-type=service:Net-Transducer:Thermometer template-version=0.0

template-description=

Das Thermometer ist ein Netz-Meßwertgeber, geeignet zum Temperaturmessen. Daten können ausgelesen werden, indem einer der Ports, die in der Service-URL angegeben sind gelesen wird, bis ein NULL-Zeichen erscheint.

Der Client kann dann weiter Daten mit maximal der Sample-Rate

auslesen, oder die Verbindung abbauen. template-url-syntax=

url-path = "ports=" ports-list

port-list = port / port "," ports port = 1*DIGIT

; See the Service URL <port> production rule.

; These are the ports connections can be made on. location-description=string

# The location where the Thermometer is located.

operator=string O

# The operator to contact to have the Thermometer serviced. localize-location-description= string

Ortsbeschreibung

localize-operator= Betreiber

-----------------template ends here----------------

The last two localize- attributes are optional in order to define additional interna- tionalized attribute names.

3.2 UPnP

After addressing devices and their discovery (or that of their services) a detailed de- scription is needed to check suitability and enable control. Different from most other Service Location techniques, UPnP does not allow searching for services with specific attributes (e.g. a “color” printer), so this information has to be obtained from the service description. UPnP description templates are based on XML. This description language is not explained here, information can be obtained from the World Wide Web Consor- tium [W3C00].

The description for a device is partitioned into two parts: first a device description de- scribing device dependent data including a service list of one or more services provided by the device, and second the service description(s) themselves, whereas each single de- scription is retrieved by HTTP requests separately.

The difference between templates and descriptions - these terms may be mixed up in the following - is that descriptions belong to an (real) implemented device or service

which is written by a UPnP vendor, whereas a template pretends structure and par- tially content for an (abstract) type of device / service and is written by a UPnP Forum working commitee. Coded in XML, both look very similar, whereby all data elements are specified in the description. After all there is a UPnP Template Language, which is a XML schema and is directly mappable to a DTD.

This section should only give a general survey and is not designated for descrip- tion design. A more detailed example template can be found in section 3.2.4, fur- ther explanations, especially for development should be retrieved from the original specification[Mic00].

3.2.1 Device Description

The structure and content of a device description and a device template is shown in Figure 3.1 schematically:

illustration not visible in this excerpt

Figure 3.1: UPnP: Device Description

The general information contains the URN for the device template specification used, optionally a base URL and other things. The ultimate information about the device is found in the device block, which consists of informations, such as device type, man- ufacturer, name, informational URL s and a UDN (Unique Device Name). The latter is a universal unique identifier for the device. Actually there are discussions on the UPnP mailing list, how to use this UDN. A service list follows, which contains a number of services, and a list of device for possibly existing embedded (nested) devices.

The service type contains a URN for its template specification, the service ID, which

identifies the service and contains a URN as well. Finally there are 3 URL ’s for ser- vice description (described in the next paragraph), control and eventing (described in Chapter 4.2 about service access).

3.2.2 Service Description

The structure and content of a service description and service template is shown in the following Figure 3.2 schematically:

illustration not visible in this excerpt

Figure 3.2: UPnP: Service Description

The general information here is nearly the same as in the device description. Only the URN points out to a service template specification which is used. A service is specified by a list of actions which can be carried into execution and a table with the service’s state variables. Each service may have zero or more actions. Each action must have a name and may have zero or more arguments listed in the argument list. An argument consists of a name, a direction information, whether the argument is an input- or output parameter, and behind a related state variable.

The latter are included in the service state table. A state variable consists of a name, its data type, and optionally a default value and allowed values.

In order to see, how all of this works, please read Section 4.2 about accessing services with UPnP.

3.2.3 Template Design Process

The UPnP device description is written by a UPnP vendor in XML, following a UPnP device template which is produced by a UPnP Forum working commitee. To fulfill the need of standardization and development of new devices and access points, working committees are established. The working committees include the Appliances Working Committee, the Audio / Video Working Committee, the Home Automation and Security Working Committee, the Imaging and Printing Working Committee, the Internet Gate- way Working Committee and the Mobile Devices Working Committee. [Abi00] These committees define about 30 device standards in the first generation. A technical com- mitee is covering all working commitees, assisting and combining them.

UPnP templates are developed and approved, starting with assigning an author, achiev- ing Template Preliminary Design (TPD) status and ending with Template Design Com- plete (TDC) status.

To begin, within each working committee, authors are assigned to draft templates for device and service descriptions based on product scenarios and submit them to the com- mittee for design review. Initial reviews focus on device modeling and, in particular, on the definition of services, service state variables and action sets. After incorporating committee feedback, draft designs are given Template Preliminary Design (TPD) status. Once template designs reach TPD status, vendors can begin sample implementations. Early implementations help prove the completeness of a design.

The next step focuses on confirming device and service model usability and testability. For example, the committee ensures that the XML template allows vendors to specify appropriate device specific parameters at implementation time, and that the device is factored into appropriate device and service modules. The committee makes sure in- teractions between services within a device are specified in the test portion of the tem- plate. After completing this phase according to a consensus of the committee, a design is considered Template Design Complete (TDC). At Template Design Complete (TDC), a device or service design includes the completed XML template. Sample implementers use the templates to create the XML code for the XML device description, including messaging for the device’s discovery and control servers. [Ste]

The committee is currently responsible for ensuring the completeness of the device ar- chitecture; overseeing the creation of device and service templates; understanding and tracking all technical issues raised by committees and members; helping committees identify common solutions, services and conventions; providing complete requirement documents and prioritizing feature requests for the evolving device architecture; and managing Internet Engineering Task Force (IETF) submissions. [Jef]

[...]