ABHELSINKI UNIVERSITY OF TECHNOLOGY

Transcription

1 ABHELSINKI UNIVERSITY OF TECHNOLOGY Department of Computer Science and Engineering Telecommunications Software and Multimedia Laboratory Teemu Koponen Service Discovery Solutions Federation: A Service Broker Approach Master s thesis submitted in partial fulfillment of the requirements for the degree of Master of Science in Technology Supervisor: Instructor: Professor Kimmo Raatikainen Kimmo Raatikainen, Ph.D. Espoo, May 24th, 2002

2 TEKNILLINEN KORKEAKOULU Tekijä: Teemu Koponen Työn nimi: Palveluiden löytämisratkaisujen yhteenliittäminen välittäjällä English title: Service Discovery Solutions Federation: A Service Broker Approach Päivämäärä: 24. toukokuuta 2002 Sivumäärä: DIPLOMITYÖN TIIVISTELMÄ Osasto: Professuuri: Työn valvoja: Työn ohjaaja: Tietotekniikan osasto Tik-109 Tietoliikenneohjelmistot Professori Kimmo Raatikainen FT Kimmo Raatikainen Liikkuva tietojenkäsittely ja ns. ubiquitous computing lisäävät tietoverkkojen dynaamisuutta. Sen myötä palveluiden löytämisestä tulee hankalaa niiden asiakkaille. Palvelun löytämiseen (service discovery) tarkoitetut ratkaisut pyrkivät nostamaan paikannuksen abstraktiota selvittääkseen ongelman: palvelut etsitään käyttötarkoitusten perusteella, ei verkko-osoitteiden. Vaikka nykyiset ratkaisut (Bluetooth, Jini, Universal Plug N Play, Salutation ja Service Location Protocol) onnistuvatkin abstraktiotason nostamisessa, ne ovat keskenään rajoitetusti yhteensopivia. Liikkuvan tietojenkäsittelyn ja ubiquitous computingin myötä on kuitenkin havaittu, että ratkaisujen luomien palveluiden löytöpiirien (service discovery domain) liittoutuminen on tarpeen. Kattavaa analyysiä palveluiden löytöratkaisuista ei ole olemassa mutta tämä diplomityö esittää niistä taksonomian. Diplomityössä käytetään ehdotettua taksonomiaa syötteenä vaatimusmäärittelyyn, joka tuottaa vaatimukset löytöpiirien palveluiden välittäjäarkkitehtuuriin. Vaatimuksista johdetaan edelleen suunnitelma arkkitehtuurista, joka kykenee löytöpiirien yhteenliittämiseen. Lopuksi esitellään arkkitehtuurin prototyyppi-implementaatio ja analysoidaan se yhdessä itse arkkitehtuurin kanssa. Avainsanat: Kieli: Bluetooth, Jini, liittouma, palveluiden löytäminen, Salutation, SLP, taksonomia, UPnP, välittäjä Englanti ii

3 HELSINKI UNIVERSITY OF TECHNOLOGY ABSTRACT OF MASTER S THESIS Author: Teemu Koponen Title of thesis: Service Discovery Solutions Federation: A Service Broker Approach Finnish title: Palvelujen löytämisratkaisujen liittäminen välittäjällä Date: May 24th, 2002 Pages: Department: Chair: Supervisor: Instructor: Department of Computer Science and Engineering Tik-109 Telecommunications Software and Applications Professor Kimmo Raatikainen Kimmo Raatikainen, Ph.D. Mobile computing and pervasive computing introduce a more dynamic network environment. As a side-effect, location of services becomes problematic for clients accessing the services. A number of service discovery solutions aim to raise the abstraction level of the location to solve the problem; the trend is to discover services not based on network addresses but based on service usage intentions. Even though the current service discovery solutions (Bluetooth, Jini, Universal Plug N Play, Salutation, and Service Location Protocol) succeed in doing this, they have a limited support for interoperability. Nonetheless, a need for federating service discovery domains is imminent due to the nature of the mobile and pervasive computing. No comprehensive analysis of the service discovery solutions exists. This thesis proposes a taxonomy for the service discovery solutions to fill the gap. The taxonomy then acts as an input to the requirements analysis process, which produces the requirements for a service broker architecture capable of federating service discovery solutions. A design of a proposed service broker architecture is then derived from the requirements. A prototype implementation of the architecture is also presented and analyzed together with the architecture itself. Keywords: Language: Bluetooth, broker, federation, Jini, Salutation, service discovery, SLP, taxonomy, UPnP English iii

4 Preface This thesis was written as a part of Fuego Core: Middleware for Mobile Wireless Internet project at Helsinki Institute for Information Technology. The project is funded by TEKES and several industry partners including MoreMagic Software I work for. The researchers of Fuego Core and employees of MoreMagic all provided great inspiration. However, I m especially grateful to Kimmo Raatikainen, my instructor and supervisor of this thesis. He always found time to meet me and his insightful comments were valuable feedback that helped me shaping this thesis. Although being regularly lost in my thoughts while writing this thesis, my girlfriend Aino provided me her everlasting support. Finally, Sami Mäkeläinen provided me helpful comments and helped me with various aspects of my English. Espoo, May 24th, 2002 Teemu Koponen iv

5 Contents Tiivistelmä ii Abstract iii Preface iv Contents vii List of figures viii List of tables ix Terms and abbreviations x 1 Introduction Background Research problem Evaluation criteria Organization of the thesis Solutions Bluetooth Jini Salutation Service Location Protocol Universal Plug n Play Taxonomy 11 v

6 CONTENTS vi 3.1 Ontology Functionalities Components Networking Security Miscellaneous Requirements Examples Goals Identified requirements Limitations Design Assumptions Overall architecture Broker engine Jini domain adapter SLP domain adapter Use cases Summary Implementation Overview Broker engine SLP message library Exporting SLP services Finding SLP directory agents Importing services into SLP domain Exporting services from djinn Joining services into djinn Service translation

7 CONTENTS vii 6.10 Summary Evaluation Criteria Architecture Implementation Related work Conclusions 60 Bibliography 62

8 List of figures 1.1 The position of a service broker in the middle of service discovery domains. If a service broker is not present, service A is visible neither to the client 1 or to the client 2. The client 1 is not aware of any services and the client 2 may only access the service 2. Once a service broker is deployed, the clients may discover all the services as the broker federates the domains Nodes and components of the service broker architecture A Jini service registers and de-registers A SLP service registers and updates its registration A SLP client searches services A Jini service subscribes to notifications and receives a notification An UML package diagram of prototype s Java packages and their dependencies An UML class diagram of service classes, which are a part of the broker engine viii

9 List of tables 2.1 The infrastructure, programming model, and service elements Jini adds to Java. [49] The proposed taxonomy of the service ontologies A taxonomy of service discovery solutions functionalities A taxonomy for service discovery solutions components. BA Broker Agent, DA Directory Agent, SA Service Agent, UA User Agent, and DevA Device Agent The taxonomy for the security features of the service discovery solutions A taxonomy for miscellaneous features of service discovery solutions Expected durations of essential service discovery operations, with and without a service broker ix

10 Terms and abbreviations API Application Programming Interface, a standard or non-standard interface provided by a library or a component to an application developer. ASN.1 Abstract Syntax Notation 1, an international standard specifying data used in communication protocols. BER Basic Encoding Rules, an encoding rule of ASN.1. Djinn A distributed system consisting of Jini enabled services and clients. DD Dolby Digital, a standard to encode 6 distinct audio channels into a digital format. DNS Domain Name System, a global de-centralized directory that translates domain names into IP addresses. DNSSRV Domain Name System Service Record Working Group, an IETF working group that specified a DNS extension enabling finding of an IP address of a service based on a protocol and domain. DVD Digital Versatile Disc, an optical disk storage technology capable of storing audio, video, and data. DHCP Dynamic Host Configuration Protocol, an Internet protocol for automating the configuration of devices using TCP/IP. EJB Enterprise JavaBeans, a server-side Java component architecture of J2EE. FTP File Transfer Protocol, an Internet protocol for moving files over Internet. GENA General Event Notification Architecture, a notification architecture transmitting notifications between HTTP resources. HTML Hyper Text Markup Language, a simple data format for creating portable hypertext documents. HTTP Hyper Text Transfer Protocol, an application-level stateless protocol distributed hypermedia information systems. IANA Internet Assigned Numbers Authority, an authority allocating Internet related numbers (e.g. protocol UDP and TCP ports). IETF Internet Engineering Task Force, an open international community concerned with the evolution of Internet architecture. x

11 TERMS AND ABBREVIATIONS xi IP Internet Protocol, a protocol for connecting packet-switched computer communication networks. IrDA Infrared Data Association, an association for defining infrared standards. J2EE Java 2 Enterprise Edition, the Java standard for developing multitier enterprise applications. JNDI Java Naming and Directory Interface, a standard extension to Java platform providing a unified interface to naming and directory services. JTS Java Transaction Service, a specification of the transaction manager implementation that supports Java transaction API. JVM Java Virtual Machine, an abstract computer executing all Java programs. L2CAP Logical Link Control And Adaptation Protocol, a Bluetooth protocol stack layer that provides connection-oriented and connectionless data services. LDAP Lightweight Directory Access Protocol, a protocol for accessing online directory services. LMP Link Manager Protocol, a protocol used by Link Manager that is responsible for establishing Bluetooth links. MADCAP Multicast Address Dynamic Client Allocation Protocol, a protocol that allows host to request multicast address allocation services from multicast address allocation servers. MPEG-2 Motion Picture Expert Group 2, a standard to encode broadcast quality multichannel audio and video into digital format. Ontology defines the terms used to describe and represent an area of knowledge. PnP Device Plug n Play, a Microsoft technology that provides automatic configuration of PC hardware and devices. UPnP Universal Plug n Play, a service discovery solution for home IP networks. RDP Resource Discovery Protocol, a predecessor of SLP. RF Radio Frequency, any frequency within electromagnetic spectrum associated with radio wave propagation. RMI Remote Method Invocation, a set of protocols that enable Java objects to communite remotely with othe Java objects. RPC Remote Procedure Call, a protocol that allows a program to invoke a procedure on a remote server. SDP Service Discovery Protocol, a Bluetooth protocol for service discovery. SHA-1 Secure Hash Algorithm Version 1.0, a standard for computing a condensed representation of data. SIG Special Interest Group, a group of users interested in a particular subject. SLP Service Location Protocol, a service discovery protocol defined by IETF.

12 TERMS AND ABBREVIATIONS xii SOAP Simple Object Access Protocol, a platform independent protocol that provides a way for applications to communicate over Internet. SRVLOC Service Location Protocol Working Group, an IETF working group that developed SLP. SSDP Simple Service Discovery Protocol, a service discovery protocol of UPnP. SSL Secure Socket Layer, a predecessor of TLS. TCP Transmission Control Protocol, an Internet protocol that establishes reliable connections over IP. TLS Transport Layer Security, an Internet protocol that provides secure connections over Internet. UDP User Datagram Protocol, a connectionless Internet protocol running on top of IP. UML Unified Modeling Language, a general purpose notation language for specifying and visualizing software. URL Uniform Resource Locator, a global address of resources on the Internet. UUID Universally Unique Identifier, a globally unique Bluetooth constant value. XML Extensible Markup Language, a language enabling the definition, transmission, validation, and interpretation of data between applications and between organizations.

13 Chapter 1 Introduction 1.1 Background The arrival of fixed computer networks facilicated the emergence of the field of distributed systems. The computer networks date back to the 1970s and thus, the distributed systems have a relatively long history in computer science. Mobile devices, including laptop computers and handheld devices, became popular in the 1990s and the distributed computing faced a whole new set of problems caused by the mobility of the devices. The research field of mobile computing attempts to solve these issues. Mark Weiser envisioned environments filled with discreet computing and communication facilities serving humans in 1991 [56], and the concept of ubiquitous computing emerged. Afterwards the term pervasive computing has been used to capture his vision. Pervasive computing may be seen as a descendant of the distributed systems and mobile computing. In addition to including all the challenges introduced by the distributed systems and mobile computing, it reveals a whole new set of problems [45]. Clearly, the trend is that the network environments surrounding devices are becoming more dynamic; the distributed systems on the fixed networks had a stable environment while the mobile computing introduced dynamics in form of devices moving from an environment to another. As the pervasive computing is essentially about coupling computing and communication facilities and the human, the scale of dynamics it introduces is completely different from the dynamics of the mobile computing. In essence, the computer networks are about using services; multiple users (clients) regardless of their location may use a single service. Hence, the networks connect the users and services. In distributed systems clients use static service locations to discover services before using them, and manually configured network addresses pointing to services are sufficient. In the dynamic network environment of the mobile and pervasive computing, the location of services is no more fixed. If the service is not mobile, clients are subject to move, and if nothing moves, a service might be replaced by another one which provides similar services as the old one. Overall, services are no more coupled to their network addresses and discovering services on network becomes therefore problematic. Although the network environment and available services change, the ultimate cause of using services remains the same; clients aim to accomplish tasks. Hence, if the services have properties describing their capabilities to perform tasks and an architecture connecting 1

14 1.2. Research problem 2 #,+.-0/ ) *! "$# %&('! "$# %&1 # +.-1 ) * Figure 1.1: The position of a service broker in the middle of service discovery domains. If a service broker is not present, service A is visible neither to the client 1 or to the client 2. The client 1 is not aware of any services and the client 2 may only access the service 2. Once a service broker is deployed, the clients may discover all the services as the broker federates the domains. clients with intentions and services exists, finding required services in changing environments becomes possible. Service discovery solutions are exactly these connecting architectures. Before proceeding to the research problem, it should be noted that the services discussed in this thesis are primitive services network components providing e.g. mail gateways, printers etc. the services are not defined e.g. as web services [55]. A typical scenario would be finding a web proxy on a network as a web browser starts without having a pre-configured address of the proxy. The service discovery solutions are positioned to a middleware layer that pervasive computing platforms are likely to need [41], while the web services lie on the application layer. Thus, the concepts of service discovery solutions and web services are completely different. 1.2 Research problem The discussion above implies indirectly at the existence of multiple service discovery solutions. In fact, at the time this thesis is written, 5 major service discovery architectures exist: Bluetooth, Jini, Salutation, SLP, and UPnP. The architectures as such have limited interoperablity and their common properties are unknown; a taxonomy of the service discovery solutions does not exist. A service discovery solution forms a domain on a network; services of a domain are available for clients of the domain. However, as stated above, no single service discovery solution exists and the solutions have limited interoperablity. Hence, if multiple service discovery solutions are deployed on a network, services of a domain are not visible to clients of the other domains. While the problem is present on the fixed networks, it becomes more concrete once the clients and services start to move from a network to another. On ad-hoc networks, common in the mobile and pervasive computing, the problem is obvious; the presence of multiple service discovery domains on networks is inevitable.

15 1.4. Organization of the thesis 3 The research community has already recognized the need for service discovery domain federations (see e.g. [45]). A federation of the service discovery domains extends the reach of both services and clients. A service is no longer only for clients of its domain. Instead, clients may discover services across domain borders. A middleware component, service broker is an option to build the federation; the service broker connects domains into a single logical domain. Figure 1.1 illustrates the relation of the service broker and service discovery domains. This thesis has two major goals. First, I endeavor to propose a taxonomy for the service discovery solutions in order to clarify their divergence. Second, I aim to design a service broker architecture capable of connecting the service discovery domains the current solutions create. The proposed taxonomy shall be used as a tool in the process. A prototype implementation shall verify the feasibility of the architecture. The proposed architecture and prototype implementation shall be evaluated using criteria discussed in Section 1.3. The focus of the thesis shall be strictly in the service discovery. Hence, for example, sessions users establish to services after service discovery are not discussed. Protocols used to establish the sessions are not discussed either. 1.3 Evaluation criteria The taxonomy proposed in Chapter 3 is not evaluated directly. Instead, it s implicitly evaluated since the foundations of the proposed architecture lay on the taxonomy. The architecture shall be evaluated using the following criteria: Functional requirements are the requirements for federating service discovery domains fulfilled? Simplicity how simple (or even transparent) the architecture is to a service and client agent developers? Clarity how well is the complexity partitioned? Are component dependencies minimized? Universality how tightly coupled is the architecture to specific protocols? Chapter 4 will identify the functional requirements, and Chapter 7 will describe the criteria in more detail while evaluating the architecture. 1.4 Organization of the thesis Chapter 1 presented the research problem and high level criteria to evaluate a proposed architecture. Chapter 2 introduces the current service discovery solutions, and Chapter 3 proposes a taxonomy for them. The taxonomy then acts as an input for the requirements analysis presented in Chapter 4 while Chapter 5 then derives an architecture based on the identified requirements. Chapter 6 discusses the implementation of the architecture. The architecture and its prototype implementation are evaluated in Chapter 7. Finally, Chapter 8 concludes the thesis and presents conclusions.

16 Chapter 2 Solutions The chapter briefly introduces the service discovery solutions discussed and analyzed in the thesis. Chapter 3 then proceeds by proposing a taxonomy for the service discovery solutions. 2.1 Bluetooth Bluetooth is not just a service discovery solution; it s a complete set of specifications starting from the air interface (Radio Frequency (RF)) and extending to the application level service discovery and link establishing. Bluetooth Special Interest Group (SIG) maintains Bluetooth specifications. The Bluetooth SIG is a consortium of over 2000 companies, including 3Com, Ericsson, IBM, Intel, Lucent, Microsoft, Motorola, Nokia, and Toshiba. A Bluetooth protocol stack consists of a baseband layer, Logical Link Control And Adaptation Protocol (L2CAP) layer, Service Discovery Protocol (SDP) layer, and RFCOMM layer. The baseband layer is a physical layer i.e. it s responsible for short-range radio communications operating at 2.4 GHz unlicensed band 1. The layer provides both synchronous (voice) and asynchronous (data) channels. The data channels have a maximum speed of approximately 800 kilobits per second, divided either asymmetrically or symmetrically between the up and down links. Link Manager Protocol (LMP) operates on the top of the baseband layer, and is responsible for link establishment and controlling. L2CAP also resides on the top of the baseband layer and forms the Bluetooth LMP data link together with LMP. L2CAP provides (a list from [4]): world. Protocol multiplexing for higher level protocols, Connectionless data services, Connection-oriented data services, Segmentation and reassembly of large data packets exceeding the limitations of baseband protocol, and 1 The 2.4 GHz band is globally unlicensed i.e. Bluetooth devices do not require licenses anywhere in the 4

17 2.2. Jini 5 Quality of service for reserving and monitoring network resources. Thus, LMP establishes and controls the data links and L2CAP provides the data transfer functionalities for higher protocol layers. As Bluetooth is often a wireless replacement for serial cables, a serial port emulation protocol is practical. After all, serial port is the interface the most of the existing wired mobile data applications use. Bluetooth SIG has defined RFCOMM for this purpose; it provides emulation of the serial ports over Bluetooth. RFCOMM is a layer on top of L2CAP in the Bluetooth protocol stack. Since LMP is only capable of establishing data links between peers, a protocol is needed to discover Bluetooth services in RF proximity. SDP operates on top of L2CAP providing the discovery functionalities. The focus of this thesis is on the service discovery. Hence, when Bluetooth is mentioned, its service discovery aspects are meant. Despite its wide acceptance as a technology, Bluetooth enabled devices have not yet conquered the markets. In 2002/Q1 Bluetooth SIG listed only approximately 500 Bluetooth qualified devices. 2.2 Jini Jini is a network independent but a Java dependent solution for distributed computing. Jini extends the Java application environment from a single Java Virtual Machine (JVM) [35] to a network of virtual machines. Sun Microsystems created Jini to achieve three goals [49]: 1. To enable users to share services and resources. 2. To provide access to resources without depending on the network location. 3. To simplify the task of building, maintaining, and altering a network of devices, software, and users. Jini is an infrastructure, programming model and set of services for building distributed systems. Jini infrastructure consists of the standard building blocks provided by Java and a set of new blocks which Jini introduces: discovery, distributed security (actually part of Remote Method Invocation (RMI)), and lookup. The discovery and lookup together form service discovery. For distributed security RMI provides only Secure Socket Layer (SSL)/Transport Layer Security (TLS). The key concepts of Jini as a programming model are leases, transactions, and distributed events. Jini leases enable reliable resource allocation in a distributed environment, while transactions enable atomic data modifications spanning over multiple components. With the help of Jini events, components may register for specific events and receive notifications once such events occur. Java 2 Enterprise Edition (J2EE) features a rather rich set of services for building distributed systems. Jini enhances the set by a tuple space implementation, JavaSpaces [48], and a transaction manager. The manager does not assume transactions to occur in a transaction processing system as Java Transaction Service (JTS) does. In addition, Jini provides a

18 2.3. Salutation 6 Infrastructure Programming Model Services Java JVM Java APIs JNDI a RMI b Java Beans EJB c Java Security JTS d Jini Discovery & Join Leasing Printing Distributed Security Transactions Transaction Manager Lookup Events JavaSpaces a Java Naming and Directory Interface (JNDI) b Remote Method Invocation (RMI) c Enterprise JavaBeans (EJB) d Java Transaction Service (JTS) Table 2.1: The infrastructure, programming model, and service elements Jini adds to Java. [49] printing service. Table 2.1 summarizes the enhancements Jini architecture has to Java. As the table indicates, the service discovery has a key role in Jini. Jini has three types of components: clients, services, and lookup services. The clients use functionalities the services provide, and the services register themselves to the lookup services, which are directories of Jini enabled network. Hence, Jini networks must have lookup services in place. They provide the service discovery and registering functionalities for Jini entities. Jini separates the directory discovery and service discovery; Jini components discover directories and lookup services from the directories. A lookup occurs based on the interface a service implements and attributes it was registered. Jini has no set of standard interfaces or entries. As a service joins to network, a component registers the service to directories. Jini is closely coupled to Java. In fact, Jini defines no new protocols besides the discovery protocol; instead, Jini specifications define only the Application Programming Interface (API)s, and do not define how the functionalities should be implemented. The directory discovery is the only exception. If Jini specifies no implementations, how is it then possible to integrate components from multiple vendors? Jini solves the problem by utilizing mobile Java code. In fact, even service queries return Java code that acts as a proxy for the real service implementation. 2 As a proxy exists for each service, the communication between the proxy and the service is an implementation specific issue. 2.3 Salutation Salutation architecture [43] is a free service discovery and utilization architecture of Salutation Consortium [44]. The consortium is a group of companies and organizations, including for example Canon, Fuji Xerox, and IBM. The Salutation architecture aims to provide a standard method for service description, discovery, and utilization regardless what the underlying networking technology is [43]. Salutation is operating system, programming language, and network independent. The first Salutation architecture was presented to public in 1995 and after its introduction two enhanced major protocol versions have been introduced. 2 A proxy may be a complete service in itself too.

19 2.4. Service Location Protocol 7 The current Salutation version is 2.1. Salutation has only a single component, Salutation manager, which is a service broker. Services and clients are connected to a service broker, Salutation manager. The tasks of a service broker are (as [43] lists them): 1. Service registering, 2. Service discovery, 3. Service availability, and 4. Service session management. Service registry, discovery, and availability tasks are common for all service discovery solutions. However, as Salutation aims to unify not only service discovery but also service utilization, it includes a comprehensive set of session functionalities. In addition to the fact that Salutation Consortium has defined new universal protocols for different service types, Salutation managers can convert on-the-fly protocols for clients. As each Salutation manager maintains a set of service registrations, Salutation managers on a network must be interconnected; the managers form a full mesh. Salutation architecture has transport managers responsible for managing the connections to other Salutation managers, and a transport manager exists per a transport media. The salutation manager uses the services of transport managers, and is thus unaware of underlying different network and service discovery technologies. Salutation Consortium has specified mappings (transport managers) from Bluetooth [4], Infrared Data Association (IrDA) [27, 28, 29, 30] and Service Location Protocol (SLP) [19, 20] to Salutation. Salutation manager only requires the underlying transport media to support is reliable the capability of bi-directional communications [43]. Thus, the Salutation is a service discovery solution, which is rather interoperable and easy to integrate. Quite a few Salutation Consortium member companies and organizations have a background of office automation. Hence, it s not a surprise that the focus of the Salutation architecture is on traditional office computing. However, the consortium has recognized pervasive computing 3 as a service discovery will have a significant role. The consortium has proposed a light version of Salutation, Salutation Lite [39], containing only the service discovery functionalities of Salutation. 2.4 Service Location Protocol On IP networks, Domain Name System (DNS) has traditionally provided the mapping from names to Internet Protocol (IP) addresses which are needed in connection establishment. DNS may be seen as the first, although simple, step toward service abstraction. In 1995, Internet Engineering Task Force (IETF) recognized the need for more advanced service location mechanism and two working groups were eventually formed: 3 Salutation Consortium advocates pervasive computing, but a correct term would be mobile computing not pervasive computing.

20 2.4. Service Location Protocol 8 1. Domain Name System Service Record Working Group (DNSSRV) investigated the possibility to enhance DNS with service records. 2. Service Location Protocol Working Group (SRVLOC) defined a completely new service discovery protocol, SLP, which also incorporates the ideas of Resource Discovery Protocol (RDP) [40]. The DNS service record is an extension to DNS allowing a client to locate a service in a domain based on a protocol the service is accessed. Resolving of a domain name having a service name and protocol as prefixes provices the service s IP address as a result. For example, the following domain name specifies a Lightweight Directory Access Protocol (LDAP) server example.com supporting Transmission Control Protocol (TCP) protocol. _ldap._tcp.example.com As the example above shows, DNS service records are closely coupled to the protocol clients use to access the service. The main motivator for service records is load-balancing and the ability to relocate servers in a domain [18]. Thus, the work of DNSSRV supports limited mobility of services, but it lacks the support for mobile clients. SLP is a more complete solution for service discovery, as we ll see next. SLP consists of three types of components: user agents, service agents, and directory agents. The service agents provide a set of functionalities for the user agents. The optional directory agents are service registries of networks. A service type defines the set of attributes a service has, and a service description contains the attributes. IETF standardizes the services types; each standardized service type has a service template, which is a formal definition for service descriptions of the specific type. The Service Location Protocol (SLP) provides a flexible and scalable framework for providing hosts with access to information about the existence, location, and configuration of networked services. As the quote above from [20] says, SLP is only used for discovering services. Hence, SLP does not include functionalities for session establishment once a service is discovered. As the directory agents are optional in SLP, the user agents can discover service agents by themselves; a user agent may perform a multicast service request and service agents respond if a matching service is found. Service agents can also send advertisements about themselves user agents may learn of services on the network by listening for advertisements. Despite its young age, SLP is already in version 2. The second major version focuses on enhancing the scalability of SLP. SLP version 2 supports protocol extensions, both proprietary and standardized. In fact, notifications were not part of the version 2 but were later added as a standardized extension [34]. The notification extension supports subscribing of events, which are sent as changes occur in services specified subscriber. IETF designed SLP to scale; SLP is intended to remain operational even on the smallest networks without directories (directory agents) and on the largest corporate intranets with directories (directory agents) and service partitioning (scoping). SLP requires a consistent

21 2.5. Universal Plug n Play 9 security policy, multicast routing, and scoping of agents, which are not practical requirements on the Internet scale. Thus, SLP is only for networks under cooperative administrative control [20]. Today, both DNS service record extension [18] and SLP [19, 20] are in the state of proposed standard Internet protocol [42] on Internet standard s track [7]. 2.5 Universal Plug n Play Device Plug n Play (PnP) is an operating system extension simplifying device installation. Universal Plug n Play (UPnP) does the same for networked devices. It simplifies installation, configuration, and control of devices on networks. As UPnP Forum [52] puts it, UPnP is universal because of: Media and device independence. UPnP technology can run on any medium including phone line, power line, Ethernet, RF, and Platform independence. Vendors use any operating system and any programming language to build UPnP products. Internet-based technologies. UPnP technology is built upon IP, TCP, UDP, HTTP, and XML, among others. UI Control. UPnP architecture enables vendor control over device user interface and interaction using the browser. Programmatic control. programmatic control. UPnP architecture also enables conventional application Common base protocols. Vendors agree on base protocol sets on a per-device basis. Extendable. Each UPnP product can have value-added services layered on top of the basic device architecture by the individual manufacturers. Microsoft leads the UPnP forum [52], which is a group of over 440 companies formed in While the forum coordinates UPnP device specifications, the UPnP architecture itself is a contribution of Microsoft for the forum. The UPnP Forum summarizes the UPnP architecture as follows (a quote from the UPnP forum web site [52]). The Universal Plug and Play architecture offers pervasive peer-to-peer network connectivity of PCs of all form factors, intelligent appliances, and wireless devices. The UPnP architecture is a distributed, open networking architecture that leverages TCP/IP and the Web to enable seamless proximity networking in addition to control and data transfer among networked devices in the home, office, and everywhere in between. An UPnP capable network has three types of components: devices, services, and control points. A device is a container for services. For example, printers and network switches are devices. A service in a device may be seen as a set of functionalities available for a control

22 2.5. Universal Plug n Play 10 point i.e. a service type equals to a known set of functionalities. The device templates UPnP forum has defined standardize associations between the functionalities and the service types. For example, Digital Versatile Disc (DVD) [12] standalone devices are all known to offer Motion Picture Expert Group 2 (MPEG-2) [38] video decoding service while not all offer Dolby Digital (DD) [13] audio decoding service. In this manner, control points can control variety of devices as long as they recognize the service type. Operation of an UPnP enabled network device has six phases: addressing, discovery, description, presentation, event listening, and control. In addressing devices configure network addresses for themselves. On IP networks, the Dynamic Host Configuration Protocol (DHCP) [14] is a solution for the address configuration. If no DHCP is present, manual address configuration is also a valid option for the address configuration. Once the address is known, the device discovers services on network. UPnP defines Simple Service Discovery Protocol (SSDP) [17] for the service discovery process, which Chapter 3 describes in more detail. UPnP devices periodically advertise their services to control points on a network. Thus, the control points may learn of services on network by listening for notifications (advertisements). In addition to listening, a control point may search services on the network; a new control point on a network may quickly discover services without waiting the periodical notifications. After the service discovery, UPnP capable devices learn the properties of devices and services they found by fetching and reading device and service descriptions. Now a control point can control services i.e. change state variables of a service and affect its operation. The control point can also listen for notifications services send. The control point knows the location of presentation Web pages the service has i.e. it may show the Web pages to an end user and the user use the service. Service control, event listening and presentation of services are the last steps following the service discovery process. These UPnP functionalities are discussed in more detail in Chapter 3.

23 Chapter 3 Taxonomy A taxonomy is a classification of specific systems. Applying a taxonomy to a set of systems instantiates it. An instantiated taxonomy enables comparison of the systems and identifying their common and unique properties. Thus, taxonomies are essential tools for understanding complex systems. No detailed service discovery solution comparisons exist. The existing comparisons [3, 25, 36] are incomplete; they lack e.g. ontology, even modest security, or network requirements analysis. Solving the research problem represented in Section 1.2 requires a comprehensive comparison of the solutions, however. The existing taxonomies are not sufficient and a new taxonomy is required. The new taxonomy I propose consists of ontology, functionalities, components, networking, and security parts. The taxonomy is introduced and instantiated one part at a time in the following sections. The sections begin with a general analysis and then proceed to a comparison of the service discovery solutions. Each section has a taxonomy proposal for the specific part. 3.1 Ontology The term ontology has plenty of meanings, and even more shades of meanings. In this thesis I define the ontology as W3C [57] defines it in Requirements for a Web Ontology Language [22]: An ontology defines the terms used to describe and represent an area of knowledge. Hence, a service ontology defines how a service is represented in the area of service discovery. Fortunately, the interpretation of a term service is common for all service discovery solutions; a service is an entity that clients on network use to accomplish a task. The solutions have disparate service ontologies they represent services in a different manner. Hence, the service ontology is an essential part of the taxonomy. In essence, the taxonomy must answer to the following question. How is a service represented in a service discovery solution? 11

24 3.1. Ontology 12 Device description Service description Type Abstract type Keywords Attributes Description templates Standardized Versions Extensions Bluetooth Jini Salutation SLPv2 UPnP Table 3.1: The proposed taxonomy of the service ontologies. Table 3.1 is a concise representation of the proposed taxonomy for the service ontologies discussed in this section Bluetooth In Bluetooth, a service description is a service record, which consists of an attribute collection, service identification, and service handle. The service handle is unique in the context of a Bluetooth device. The service description is an instance of a service class, which defines the service description record. The Bluetooth attribute is an attribute identification type value tuple. The service class defines the attribute identifications, which are unique in a service record. The service identification identifies the service class which the record instantiates. A service class may inherit another service class. However, no abstract classes exist i.e. all service classes are instantiable. An Universally Unique Identifier (UUID) is a special attribute value, which is globally unique [4]. The UUIDs represent characteristics of services; they may be interpreted as a global standardized pool of constants. For example, UUIDs for protocols such as File Transfer Protocol (FTP), Hyper Text Transfer Protocol (HTTP), TCP, and User Datagram Protocol (UDP) exist. The UUIDs have an important role in the capability exchange discussed in Section Bluetooth Forum [5] maintains a set of standard service classes and attribute definitions called universal attributes. The universal attributes are common to all service records e.g. they contain documentation Uniform Resource Locator (URL), icon URL, and protocol information attributes. The universal attribute set is subject to expand Jini A Jini service description consists of a Java interface and entries. The interface is a service type, which may be an abstract type. The abstract types enable a single service type to have a common interface even though several service implementations exist. Furthermore, a service interface may inherit interfaces as Java specification [33] allows. A Jini service interface is a complete service usage description, in addition to being a service type. As the Java interfaces can t have attributes, Jini has the entries. An entry is an instantiated

25 3.1. Ontology 13 serializable 1 Java class, which inherits a net.jini.core.entry class. The entry has fields, each representing an attribute, which may be any serializable Java class. No organization defines standard service types i.e. the interfaces of common Jini services. Jini has a small set of basic entries, including e.g. address and comment entries. As no set of standard service types or entries exists, very much of Jini is deployment-specific Salutation A Salutation service description consists of a functional unit identification (service type), functional unit handle, and functional unit s attributes (service attributes). Salutation managers are functional unit (i.e. service) containers. The managers create the functional unit handles, which are valid for the life time of service registrations. The service descriptions contain no information about accessing services. The functional unit identification is universally unique, and it defines the attributes a service may have and information on how to compare them. A comparison function defines the comparison. The function is an implicit attribute type it defines how the attribute value is interpreted. In addition to the function, an attribute may store the result of the comparison. In the functional unit attribute identification identifies an attribute, which is a tuple identification comparison function result value. Salutation Consortium [44] maintains standard functional unit identifications, which are a part of Salutation specifications [43]. For example, service types for printers, scanners, and fax machines exist. Salutation has no public documented process to define new functional units. Instead, the consortium defines the new functional units as part of the specifications Service Location Protocol A Service Location Protocol (SLP) service description consists of a service type and service attributes. The SLP service type is either abstract or concrete. The abstract type does not define a service access protocol, while the concrete type defines the protocol to access the service. A service description containing an abstract type can not exist, as the service description must define a service access protocol. Hence, the abstract types must be inherited by the concrete types. The access protocol is either a name of a known port or protocol name [24] assigned by Internet Assigned Numbers Authority (IANA) [26]. A service URL represents the service access information, while the type defines the attributes a service has and URL s syntax. A service type template is a formal description of a type. As concrete types inherit abstract types, they also inherit the attributes of the abstract types. Similar services having no common access protocol may have a shared abstract type; after all, the access protocol is the only differentiating factor. The abstract types enable the definition of general services; agents discovering services may use general service attributes without understanding any service specific attributes. IETF maintains an official set of service type templates. A documented process requiring community review and comments for submitting a new type exists. The process and templates support evolving templates i.e. multiple versions of a template may co-exist. 1 Java object marshaling process is called serialization.

26 3.2. Functionalities Universal Plug n Play UPnP has device and service descriptions. Unlike the other service discovery solutions described above, it distinguishes the container of a service and the service itself. The device description contains information about a physical device e.g. vendor s identification and hardware information. It also includes service description location URLs of services the device hosts. A UPnP service type is a single string. In addition to the type, the service description contains a service control description and representation URL. The control description defines variables, states variables can have, and invocable actions to change states. UPnP is not involved in the service representation at all, it merely provides the URL. UPnP forum maintains a set of schemas, standard templates, for the device and service descriptions. In fact, all devices and services are assumed to instantiate a standard template. However, custom template extensions are possible, although, the extensions are not compulsory. A service must be usable by clients not understanding its proprietary extensions. 3.2 Functionalities Section 3.1 taxonomized the ontologies, and this section proceeds with functionalities the service discovery solutions provide for processing the service information. The solutions have a goal; they attempt to enable using of services on network with minimal efforts. Although the service discovery solutions share a goal, the functionalities they provide to achieve the goal differ. Clearly, a taxonomy of service discovery solutions must include the functionalities the different solutions have. The functionalities are categorized to registering, scoping, querying, sessions, notifications, service controlling and presentation parts. The representation order of the parts will vary depending on the solution. Table 3.2 represents the proposed functionality taxonomy Bluetooth Bluetooth service registration occurs completely in a device as there are no directory components. Once registered, the device responds to service requests. The registration does not produce an identifer. Bluetooth implicitly assumes services are closely coupled with its protocol stack; expiring registrations are not supported. As no independent directories exist, there s no need for directory discovery or dynamic service registration updates. The Bluetooth service discovery supports only UUID based searching; attribute search criteria may include only fixed constants. For service browsing a special attribute, BrowseGroupList, exists. Every service class has it, and its value is a list of browsing group UUIDs. A service may belong to multiple browsing groups. If the number of services is limited, all services may exist in a root browsing group with a globally standard UUID. For large systems, Bluetooth supports a hierarchy of services; the root group has special service records that merely contain list of child browsing groups. The browsing groups enable the service browsing. Bluetooth defines new protocols for service access, but the service discovery only locates