Diplomarbeit, 2001, 106 Seiten
Abstract Successive to a preceding study about Service Discovery, this thesis covers the topics Service Description and Service Access. Starting with an analysis and comparison of existing technologies, a new protocol for the service access was developed and an operating environment, capable of accessing services of any type was programmed. Thereby emphasis is placed on high scalability, extensibility, modularity and comprehensive documentation, to provide easy association with existing or future works. The ﬁrst part deals with the various versions of Service Descriptions, followed by a description of the service access methods and concluding with a comprising comparison. All technologies or protocols qualiﬁed for Service Discovery and Access discovered during this diploma thesis are discussed.
The main part comprises the software implementation which was written in Java, including a comprehensive documentation containing, among others, the protocol speciﬁcation, software architecture, an user guide and proposals for advancements.
Zusammenfassung Aufbauend auf einer vorangegangenen Arbeit über Service Discovery, werden in dieser Diplomarbeit die Themen Service Description und Service Access behandelt. Beginnend mit einer Analyse und dem Vergleich existierender Techologien, wurde ein neues Protokoll für den dynamischen Dienstzugriff entwickelt und eine funktionsfähige Umgebung programmiert, die mittels dieses Protokolls auf Dienste jeglicher Art zugreifen kann. Dabei wurde das Augenmerk auf eine hohe Skalierbarkeit, Erweiterbarkeit, Modularität und umfassende Dokumentation gelegt, so daß es nicht schwer fallen sollte, die Software mit folgenden oder existierenden Arbeiten zu verknüpfen. Im ersten Teil wird auf die verschiedenen Varianten der Dienstbeschreibungen eingegangen, gefolgt von einer Beschreibung der Dienstzugriffe und anschließend einem zusammenfassenden Vergleich. Aufgeführt sind dabei alle für Service Discovery und Access geeigneten Technologien, bzw. Protokolle, die im Rahmen der Diplomarbeit aufgefunden wurden.
Der Hauptteil der Arbeit umfaßt die Implementierung der Software, die in Java geschrieben wurde, inklusive einer umfassenden Dokumentation dazu, die unter anderem die Protokollspeziﬁkation, die Architektur der Software, eine Bedienungsanleitungund Vorschläge zur Weiterentwicklung beinhaltet.
The ﬁrst 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 conﬁguration 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.
CHAPTER 1. INTRODUCTION 2
Service Discovery is not discussed here, as far as the location itself is concerned (therefore 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 technology, which is described in Chapter 6. Besides, this thesis includes the software implementation described in Chapter 6 and a documentation framework within the software package. This documentation framework contains everything of Chapter 6 and furthermore 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.
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 without (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 speciﬁcation, 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 ﬁrst which are provided within each protocol section.
1.3. HOW TO READ THIS PAPER 3
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 every speciﬁcation 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.
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.
Mobile computing is an issue which will become more and more important in the fu- possibly even completely superceeding the wired local network environments. This is necessary to fulﬁll the needs for an untethered, ubiquitous communication environment. Facing the technical constraints of these networks, like the diversity of devices, their capabilities, resources, interfaces, as well as the vast variety of services, new
CHAPTER 2. GENERAL 6
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.
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 conﬁgure the IP address). 2. Gain knowledge about the existence and capabilities of a service (e.g. by asking the administrator). 3. Conﬁgure his device for the use of a speciﬁc 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.
The automated dynamic access procedure comprises four steps:
2.1. INTRODUCING REFLECTIONS 7
1. Network conﬁguration: Establishing a functioning network link. 2. Service Discovery: Discover existing service(s).
Ad Hoc Networking affects different layers of the communication hierarchy, such as:
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.
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
CHAPTER 2. GENERAL 8
220.127.116.11 Service Description
The purpose of Service Discovery and Access is to provide the capability of using ser- or devices without conﬁguration like networksettings or loading device drivers. Service Discovery will detect services upon request or availability, whereas Service Access will interact with the service independently from native protocols or operating systems.
The most important features of a discovery protocol are [McG00]: ¯ “Spontaneous” discovery and conﬁguration of network devices and services ¯ Selection of speciﬁc 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
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 difﬁcult topic, which is treated in AI (Artiﬁcial Intelligence), e.g. [AIT], by the use of conceptual graphs [PG00].
Known services can be described syntactically by speciﬁed interfaces. The selection of a service is easier in this case, simply by ﬁnding a ﬁtting interface from the amount of available interfaces. All discovery protocols work in this manner.
2.2. THE PROBLEM OF AUTOMATED INTERACTION 9
18.104.22.168 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 ﬁnds using a discovery protocol) has to be able to understand all protocols necessary to access these services.
There are three possible approaches to ﬁll this gap: ¯ Invention/Implementation of Artiﬁcial 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).
CHAPTER 2. GENERAL 10
It is misleading, in the authors opinion, to announce devices that will connect and interact with each other without conﬁguration. Somebody must set the rules for interactions. Conclusion: The beneﬁt from service access technology is vendor and driver independence, but not device independence!
¯ Find a speciﬁc service type. ¯ Find services with speciﬁc 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 notiﬁcation when a new service becomes available. ¯ Check availability of services. ¯ Service leasing.
¯ Invoke actions on services (including optional feedback).
2.4. URLS/URIS/URNS, NAMESPACES 11
¯ Data transfer to a service and/or from a service. This includes any parameters, like ordinary data types, ﬁles or streams. (Usually combined with an action invocation.) ¯ Obtain speciﬁc state variable of service. ¯ Obtain common state (or description) of service. ¯ Obtain notiﬁcation on status changes by subscribing to an event.
The syntax of an URI is deﬁned as follows (see RFC 1630[BL94]): <uri> ::= <scheme>":"<scheme-specific-part> <scheme> speciﬁes the namescheme and namespace for the URI <scheme-specific-part> identiﬁcation according to <scheme> deﬁnition 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> deﬁnitions, which is the “protocol” in most cases, are ad- ministrated by the Internet Assigned Numbers Authority (IANA).
CHAPTER 2. GENERAL 12
An XML namespace is a collection of names, identiﬁed 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 disciplines in that the XML version has internal structure and is not, mathematically spoken, a set. [BHL99]
Everyone who surfs the web is familar with the term “URL” (Uniform Resource Loca- Its purpose is to specify the location of a document and to allow access to such a resource on the net. Insufﬁciencies 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> deﬁnitions 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 speciﬁc scheme.
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 deﬁned as follows (see RFC 2141[Moa97]): URI-scheme: <scheme> ::= "urn" <urn> ::= "urn:" <nid> ":" <nss>
2.5. OVERVIEW OF THE DIFFERENT TECHNIQUES 13
<nss> is the Namespace Speciﬁc String
URNs are resolved to URLs (or URCs) by the principle shown in ﬁgure 2.2, but there isn’t a speciﬁcation for resolving yet.
Figure 2.2: URN Resolving
Table 2.1: Comparison URN-URL
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.
CHAPTER 2. GENERAL 14
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.
Universal Plug and Play (UPnP) is an approach initiated and mainly inﬂuenced by Mi- Nevertheless, it is an open standard and hosted by the UPnP Forum, an industry initiative designed to enable easy and robust connectivity among stand-alone devices and PCs from many different vendors. Vendors are called to become Universal 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 inﬂuenced by Microsoft including the inability to download the UPnP speciﬁcation with Netscape, due to illegal use of plain whitespaces in the URL, instead of URL-encoding them like deﬁned in RFC 1738 [BLMM94]. Hopefully this is not a foretaste of the proposed interoperability and vendor independency! Although the version 1.0 of the speciﬁcation [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 Protocol (SOAP) 5. Events: Notiﬁcation about changes of service parameters by registration of events using the Generic Event Notiﬁcation 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. OVERVIEW OF THE DIFFERENT TECHNIQUES 15
The Java Intelligent Network Interface (Jini) is a Java based solution conceived by Sun Mi- 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 speciﬁcation 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].
The Salutation Consortium, a 30+ member non-proﬁt corporation, announced Saluta- 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, including Java, on the salutation homepage (http://www.salutation.org).
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.
Inferno was originally developed at Bell Labs (the research division of Lucent Tech- 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.
CHAPTER 2. GENERAL 16
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 speciﬁcations is allowed. Included is the obligation to respect the speciﬁcations, 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 discovery speciﬁcally 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 deﬁne 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 18
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 conﬁgured by an operator who registered service attributes in a single language.
In SLP, services are advertised and described by use of a Service URL and a Service Template.
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 information 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 keyword 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 identiﬁed with a particular service agent or resource, and is used when registering or requesting the attribute information. The latter part of the service-URL can specify devicedependent information, whereas the service type’s synax is unitary.
Masterarbeit, 158 Seiten
Diplomarbeit, 160 Seiten
Diplomarbeit, 114 Seiten
Diplomarbeit, 145 Seiten
Diplomarbeit, 66 Seiten
Diplomarbeit, 62 Seiten
Diplomarbeit, 97 Seiten
Diplomarbeit, 308 Seiten
Diplomarbeit, 143 Seiten
Diplomarbeit, 197 Seiten
Diplomarbeit, 87 Seiten
Diplomarbeit, 96 Seiten
Doktorarbeit / Dissertation, 277 Seiten
Masterarbeit, 158 Seiten
Diplomarbeit, 145 Seiten
Diplomarbeit, 66 Seiten
Diplomarbeit, 62 Seiten
Diplomarbeit, 197 Seiten
Doktorarbeit / Dissertation, 277 Seiten
Der GRIN Verlag hat sich seit 1998 auf die Veröffentlichung akademischer eBooks und Bücher spezialisiert. Der GRIN Verlag steht damit als erstes Unternehmen für User Generated Quality Content. Die Verlagsseiten GRIN.com, Hausarbeiten.de und Diplomarbeiten24 bieten für Hochschullehrer, Absolventen und Studenten die ideale Plattform, wissenschaftliche Texte wie Hausarbeiten, Referate, Bachelorarbeiten, Masterarbeiten, Diplomarbeiten, Dissertationen und wissenschaftliche Aufsätze einem breiten Publikum zu präsentieren.
Kostenfreie Veröffentlichung: Hausarbeit, Bachelorarbeit, Diplomarbeit, Dissertation, Masterarbeit, Interpretation oder Referat jetzt veröffentlichen!