Service Discovery in Peer-to-Peer Networks. Daniel Elenius

Transcription

1 Examensarbete Service Discovery in Peer-to-Peer Networks av Daniel Elenius LiTH-IDA-EX--03/060--SE

2

3 Examensarbete Service Discovery in Peer-to-Peer Networks av Daniel Elenius LiTH-IDA-EX--03/060--SE Handledare: Magnus Ingmarsson Examinator: Henrik Eriksson

4

5 Abstract Service discovery is necessary to enable computers to interact with each other through heterogeneous wired and wireless networks in a seamless way. In this work, we show how the JXTA Peer-to-Peer networking infrastructure can be extended and integrated with current technologies for advanced service discovery and interaction: The DAML-S service ontology for service description, WSDL for interface descriptions, and SOAP for remote invocation. Our approach allows platform-independent interaction between devices represented by JXTA peers, and the ability to describe services with rich semantic information to enable advanced service discovery. The inference engine JTP (Java Theorem Prover) is used to reason about (evaluate) services. We have demonstrated our work by providing a simple graphical user interface to our service discovery framework.

6

7 Table of Contents 1. Introduction A Brief Background Goals Limitations Related Work This Work Background Ubiquitous Computing and Service Discovery Peer-to-Peer Networks and JXTA XML, XML Namespaces, and XML Schema XML XML Namespaces and XML Schema The Semantic Web: RDF, RDFS, DAML+OIL RDF RDFS DAML+OIL Web Services: WSDL, SOAP WSDL SOAP Semantic Web Services: DAML-S Reasoning Engines: JTP Other related technologies Bluetooth UPnP Salutation SLP Jini Implementation Design Overview Technologies Used Our Design What needs to be done Languages, Libraries and Tools used The JXTA peers Modifying JXTA-SOAP...23

8 3.5 Writing the ontologies Working with JTP The client-side support framework The GUI Running the GUI Adding more devices Future Work Conclusions...36 References...38

9 1. Introduction 1.1 A Brief Background Since its conception, the World Wide Web and the Internet has been dominated by the client-server paradigm of distributed computing. For example, clients ask a server for database records, and servers answer HTTP requests to serve web pages. The client-server model offers simplicity of programming since the client-server interactions are usually rather straight-forward and easily understood, and this model will continue to be an important way to lay out networked computer systems. Recently, peer-to-peer (P2P) networking has grown as an alternative to the common client-server model. In P2P, interactions are side-to-side rather than top-down peers are juxtaposed as compared to servers superimposed over clients. Each peer is (potentially) both a client and a server. Many applications, such as collaborations between academics within a certain field world-wide, or as we have seen with Napster and Gnutella, MP3 file sharing, are ill-suited to the classical clientserver model. Another important field where a P2P approach is needed is Ubiquitous Computing, or ubicomp for short. Ubicomp can be explained as the vision of having computers embedded everywhere, all offering and consuming each others services over both wired and wireless networks in a seamless way. Examples of such services are printers with wireless connections offering print services to nearby hand-held computers, or a wall-mounted screen where customers can get an enlarged image of the person they re talking to on a 3G mobile phone with video telephony. Computers and devices that are moving around cannot depend on a fixed network and pre-configured service providers to meet their needs. A dynamic P2P network, where peers providing and consuming services come and go, is better suited to these needs. One promising technology for P2P networking that is being developed is JXTA, which was initially released under an open source license by Sun, and is now being developed by an active on-line community. A prerequisite for ubicomp to work is that peers are able to search for each others services in way that is uniform, flexible, and powerful, yet simple enough for the required protocols to fit in resource-constrained embedded devices such as hand-held computers or mobile phones. If computing is to become ubiquitous, users cannot be expected to manually configure their computers and devices for different networks. Research in the so-called Semantic Web field is useful for this service discovery. Ways are being innovated for describing web content and web services with semantically rich information, as opposed to the more-or-less brute force keyword searches or plain interface descriptions that have been used so far. Specifically, languages have recently appeared that allow us to write ontologies of devices, services and properties. An ontology is a set of concepts (such as things, events, or relations) in some language, that form an agreed-upon vocabulary for exchange of information within a certain field. This looks like a promising paradigm for describing services in ubicomp environments. One popular ontology language is DAML+OIL. 1.2 Goals The goal of this work is to develop a service discovery system for ubiquitous peer-to-peer networks that is: 1. Programming language independent. It should be possible to write peers in different languages. 2. Network independent. We should make no assumptions about network topologies or protocols, since these factors are likely to be highly variable in real life ubicomp situations. 3. Flexible. It should be possible to use any sort of device or service with our system. 1

10 Points 1 and 2, which together could be called platform independence are achieved by JXTA, which we have already mentioned. We decided to build on that, and what remains is to implement flexible service discovery for JXTA. We will build on existing network protocols and ontology languages to achieve this, and our analysis of such technologies is described in chapter 2. We will write a few sample devices, producing and consuming services of some kind. Finally, a graphical user interface (GUI) will be written that shows how the mechanism works, and provides easy access to detailed technical information about the devices that are running. 1.3 Limitations First of all, we do not intend to implement our system on real-life devices at this point. We are satisfied to run all peers on one workstation/pc, or on a local area network. We feel that our work will still illuminate important issues about service discovery in peer-to-peer networks. It is of course a long-term goal to develop a service discovery system for portable devices. We will comment on this in chapters 4 and 5. This work is not about defining advanced ontologies for all imaginable purposes. The ontologies created will be reasonably simple. Their purpose is to show that the our service discovery mechanism works. Neither is it about creating an all-purpose simulation for all ubiquitous computing applications. The GUI, too, will be very simple, and only used to show the results, and some possible uses, of the service discovery mechanisms that will be developed. Finally, we will not concern ourselves with low-level protocol details. In OSI s layered network model terminology, this work stays almost exclusively in the application layer. 1.4 Related Work Service discovery is mostly about protocols and description languages, so the work that this work builds on is in large part work done by organizations like the W3C (the WWW Consortium, which create various standards for networking and communications) and Sun Microsystems (inventors of JXTA). There has also been a certain amount of work on service discovery of a more academic character, and we will give a quick overview of some of the work most closely related to this one. In [1], a service discovery method for multi hop, ad hoc wireless networks is proposed, which uses something called configuration distribution to increase the number of discoverable services. It is one of a number of articles on how to improve and optimize the low-level routing, caching, and layout of peer-to-peer networks. Another interesting one is [2], which proposes a way to organize service providers according to their category, using globally known ontologies. In our work, we just use whatever infrastructure JXTA uses, since we are concerned more with higher-level details (description and reasoning). Nonetheless, these works and others in their reference sections can be of interest. The basics of the semantic web and the technology of using an intelligent agent to retrieve information from it (which is what we do in this work as well) is covered by [3]. An architecture for service discovery and provision for 3G mobile users is described by [4]. This work uses a service registrar where service providers register their services, and which mediates these to the clients. This kind of architecture is often deemed to be too inflexible for the kind of ad hoc networks that are usually envisioned in ubiquitous computing environments (for reasons explained well in e.g. [2]), so we will say nothing further about it. A method of using mobile agents in conjunction with web services (UDDI, WSDL and SOAP) is proposed by [5]. In this work the JAIN PARLAY APIs are used to provide client location 2

11 information. The agents mediate the users needs by searching the UDDI register for services, and interacting with the services using WSDL and SOAP. The specifics of the interaction will be based on the user s location, allowing more intelligent services than otherwise possible. Like [4], this has the drawback of using a central (UDDI) register. Nonetheless, it is similar to what we do in this paper, in that it is concerned with using web services and intelligent agents on mobile platforms. The Edutella [6] project is about enhancing the JXTA P2P network with metadata ( data about data, e.g. information about the contents of a web page) in the RDF language. As such, it is also similar to what we are doing, but we have several reasons for not using Edutella in our work: 1) It uses RDF, which is much too limited to write service ontologies; 2) It is a work-in-progress and may not be sufficiently ready for use; 3) It uses centralized hubs, so the advantages of a distributed P2P network are somewhat lost. A way to enhance the Bluetooth SDP (Service Discovery Protocol) that allows the use of semantic matching using RDF or DAML+OIL instead of the SDP s normal UUID (Universally Unique Identifier) matching is proposed by [7]. This places the service discovery and matching at a rather low level in the protocol stack, and limits it to the Bluetooth technology. In our work, we have chosen to use JXTA for transport and discovery, and place the service matching at the application layer, which we feel is a more general solution. Still, this work is closely related to ours, and we will have reason to return to it later on in this paper. 1.5 This Work This chapter (1) has given a brief background of the subject of this work. We have also defined what our goals are, and mentioned some other work related to ours. An extensive background of the technologies we use, as well as some we chose not to use, is found in chapter 2. Chapter 3 describes our design and implementation, and chapter 4 discusses some future work that could (and should) follow this project. Finally, chapter 5 discusses what conclusions we can draw from this work. The reader is assumed to have good knowledge of HTML, Java, and computer networks. 3

12 2. Background This chapter provides background and descriptions of technologies used in this project. Motivations on why we decide to use the different technologies are mostly found in section 3.1 (the design overview). Readers familiar with the technologies described here can skip some or all sections, others should read this chapter carefully, and return to the relevant section to remember what the different protocols and formats do, when reading later chapters. 2.1 Ubiquitous Computing and Service Discovery According to [8], Ubiquitous computing has as its goal the nonobtrusive availability of computers throughout the physical environment, virtually, if not effectively, invisible to the user. This sounds very visionary and will probably remain a dream for a long time to come. On a more modest scale, [9] says that One of the visions of ubiquitous computing is the ability to use arbitrary devices such as cell phones and hand held computers to interact with arbitrary remote networked appliances such as TVs, printers, and EKG machines. This is more close to what we are doing, and in order to use and interact with arbitrary devices, we need a way to find them. This is where service discovery comes in. An article with good coverage of this subject, [10], says: Future computing environments will consist of a wide range of network based appliances, applications and services interconnected using both wired and wireless networks. In order to encourage the development of applications in such environments and remove the need for complex administration and configuration tasks, researchers have recently developed a range of service discovery and interaction platforms. [...] The key function of such service location and device interaction technologies is to allow users and applications to deploy, discover and interact with the services provided by devices and software components on the network. This interaction is required to occur without the users, the applications, or the service providers needing detailed knowledge of the local network configuration. This gives us all the rationale we need to motivate investigations into service discovery. The key concepts here are to do as much as possible automatically and nonobtrusively. Doing things automatically requires machine reasoning, and we will examine how this can be done in sections 2.7 and 3.6. Finally, we note that another term for ubiquitous computing is pervasive computing. 2.2 Peer-to-Peer Networks and JXTA To quote [8] again, A [...] challenge of the mobile infrastructure is mobility itself. Networking developed over the past 20 years with the assumption that a machine s name and its network address were unvarying. However, once a computer can move from network to network, this assumption no longer holds. Existing protocols such as TCP/IP [...] need to be redesigned to handle machine mobility. In this project, we use the P2P (Peer-to-Peer) infrastructure called JXTA [11], [12] (short for juxtapose ), which was released by Sun Microsystems in 2001, to meet the abovementioned needs. This section will describe the architecture of JXTA, as it is of central importance to our project. The article [11] states the goals of JXTA as being interoperability, platform independence, and 4

13 ubiquity. In short, all JXTA peers are supposed to be able to interoperate with each other regardless of which programming languages they are written in, what underlying transport protocols they utilize, and what platform they are running on. At the time of writing, JXTA has a reference implementation (version 2.0) for Java, and a number of other implementations in development: A J2ME (Java 2 Micro Edition) version that will enable JXTA to run on mobile phones, C, Perl, Python and Ruby version, and others. Currently, there are JXTA transport bindings only for TCP/IP and HTTP (the latter enabling JXTA to work through firewalls), but if a new transport binding is defined and implemented, all JXTA peers will be able to communicate with peers running on that transport. This is one of the big advantages of using JXTA. If someone creates a Bluetooth binding for JXTA, our project will run on Bluetooth-enabled JXTA peers. We use JXTA to place ourselves above the transport abstraction layer. Furthermore, the TCP/IP transport is very handy for simulations, because it is possible to run several peers on the same computer by just using different port numbers for them, avoiding the hassle of setting up a real network environment. The most important concept in JXTA is the peer. A peer is the smallest addressable entity in a JXTA network. As such, it is often equivalent to a device or a program, but note that the same device or program can run several peers if it wishes to (similar to how a single program can have several network sockets opened in TCP/IP). Peers reside in a peergroup. A peergroup can represent anything that makes peers want to collaborate or interact with each other: Types of service, physical location, current state of some sort, and so on. For example, all astronomy professors in Stockholm who have files relating to a new astronomical phenomenon could have a peergroup in common, or each room in an office could be a separate peergroup. In the latter case, all peers would need to be either 1) stationary and preconfigured with the correct peergroup, or 2) have some sort of location hardware (such as GPS) to determine which peergroup to join depending on their current location. Communication between peers is done through pipes. A JXTA pipe is an asynchronous, unidirectional communication channel. A single pipe can have several endpoints, and endpoints can be added or removed from a pipe even after it has been established. To find other peers, peergroups, and pipes, a peer issues a search for JXTA advertisements. An advertisement is a small piece of XML that announces the existence, and some properties of, such a resource (i.e. a peergroup, pipe, etc). Exactly how this search happens depends on the underlying transport bindings. For example, on a TCP/IP network a simple broadcast to the local subnet is done, and any peers running on the same subnet will be found (unless there is a network problem, of course). On a Bluetooth transport, a peer would probably just find whatever other Bluetooth devices are within its 10-meter communications range. There s also a concept of rendezvous points, which are special peers that can propagate discovery requests to more remote locations and other networks. To find services on other peers, a search for a type of advertisement called Module Specification Advertisement is done. The contents of such an advertisement remain very open. In this project, we have used them to advertise vital information about our services. This is described in detail in section JXTA is a very open standard many things are left undefined. For example, it does not prescribe a specific RPC (Remote Procedure Call) mechanism or interface definition language (we use WSDL and SOAP, respectively, see section 2.5). Chapter 3 has detailed information on how we use JXTA in this project. 5

14 2.3 XML, XML Namespaces, and XML Schema XML (extensible Markup Language) and related technologies are fundamental to modern network programming, and several of the technologies we will describe in the following sections are based on XML. All these XML-based technologies are summarized in figure 2-1. This section gives a basic introduction to what XML, XML Schema, and XML Namespaces are XML XML is an open standard defined by the World Wide Web Consortium (or W3C for short). In W3C terminology, it is a recommendation. Currently, the recommendation is at version 1.0 (Second Edition), and the official definition is [13]. XML is a language for describing data. Its syntax is very similar to HTML, but the two languages are very different in scope. HTML is about displaying information, while XML is about describing information. XML can be used to describe any information, for any purpose, whereas HTML is strictly for describing web pages. A short example of XML code follows: <?xml version="1.0" encoding="iso "?> <note> <to>tove</to> <from>jani</from> <heading>reminder</heading> <body>don't forget me this weekend!</body> </note> Any tags can be defined in XML (using DTDs or XML Schema, see 2.3.2, or not strictly defined at all). XML is case-sensitive (and usually written in small case) unlike HTML. XML can also have so-called empty tags. For example, if the <note> tag was defined to have attributes for to, from, heading and body, then the above XML could be written as: <?xml version="1.0" encoding="iso "?> <note to= Tove from= Jani heading= Reminder body= Don't forget me this weekend! /> Note the / before the ending right angle bracket. Any tag which does not have a closing tag must be closed with a / character in this way in XML (again, unlike HTML). XML was designed to be both machine- and human-readable (although in our opinion, the humanreadability of XML quickly deteriorates as the XML becomes more complex). For machine reading, one needs an XML parser. Java programs usually use an XML parser that follows the Java API for XML Processing (JAXP) standard 1. One popular JAXP-compliant XML parser is Xerces 2, which we use in this project XML Namespaces and XML Schema XML Namespaces is another W3C recommendation [14]. It is a way to define unique names of XML elements. To achieve this, elements are prefixed with a URI [15], preferably belonging to the organization defining the XML element. For example, take a look at the following code from our project: <xsd:schema xmlns:xsd= > <xsd:simpletype name= PaperSizeType > <xsd:restriction base= xsd:string > <xsd:enumeration value= A4 /> <xsd:enumeration value= Letter /> <xsd:enumeration value= A3 /> 1 specification downloadable at 2 available at 6

15 XML Basic syntax (tags, elements, attributes) Platform-independent text format XML technologies XML Schema XML language for defining XML languages XML Namespaces URIs as unique identifiers of XML elements Semantic web technologies RDF Metadata Predicates, Subjects, Objects - triple format RDFS Type system Classes, inheritance, instances, properties DAML+OIL More expressiveness e.g. Union, Intersection, Inverse Web services technologies WSDL Web Services Description Language Describes programming interface to services SOAP Simple Object Access Protocol Remote invocation of services Semantic web services technologies DAML-S Services Ontology Concepts for e.g. inputs, outputs, service parameters Service, Profile, Grounding, Process OWL-S Successor to DAML-S W3C Standard Figure 2-1: XML-based Technologies 7

16 </xsd:restriction> </xsd:simpletype>...more XML schema code... </xsd:schema> Here, all elements have the prefix xsd:, which is defined as by the xmlns attribute. We could have written this code using this whole URI at each place instead of xsd:, but this would clearly be a bad choice. It is important to realize that an XML Namespace URI does not necessarily have to be a working web address, or point to any information at all. It is a common misconception that the XML Schema (see below) that elements are defined in must be at this address, but this is not necessary. It is often the case, however, and in the above case it is true. XML Schema is also a W3C recommendation, available at [16]. XML Schema is an XML language for defining XML elements, and it is the successor of DTDs (Document Type Definitions). It is also used to define new data types, and it has a number of built-in data types for strings, integers, etc. The code example above is an example of XML Schema code that defines a new data type called PaperSizeType that is a string with one of the values A4, Letter, or A The Semantic Web: RDF, RDFS, DAML+OIL The Semantic Web is an extension of the current web in which information is given well-defined meaning, better enabling computers and people to work in cooperation. [17] The idea of the semantic web was launched by the person originally behind the World Wide Web, Tim Berners-Lee. The idea is that people (and machines) should be able to find information on the web more systematically, using predefined tags and ontologies instead of brute-force searches and web crawlers like Google, which are indexing an ever decreasing percentage of the web. Interest for the semantic web is strong, especially in the research community, and several technologies have been invented and standardized to enable this vision. For this project, we are not interested in finding information on the web, but semantic web technologies can also be useful to describe information about devices and services, as we shall see RDF The language RDF (Resource Description Framework) [18] is strongly associated with the semantic web. It is formally a W3C Working Draft, which for all practical purposes means that it is a standard. To quote the RDF Primer [18]: The Resource Description Framework (RDF) is a language for representing information about resources in the World Wide Web. It is particularly intended for representing metadata about Web resources, such as the title, author, and modification date of a Web page RDF data can be expressed in three different formats: Its XML syntax. This is the format used when sending RDF data between different computers, and the format most commonly seen, but it is also the least intuitive to understand. An example of RDF code (from [18]) follows: <rdf:rdf xmlns:rdf=" xmlns:contact=" <contact:person rdf:about=" <contact:fullname>eric Miller</contact:fullName> <contact:mailbox rdf:resource="mailto:em@w3.org"/> <contact:personaltitle>dr.</contact:personaltitle> </contact:person> </rdf:rdf> 8

17 The above piece of code defines a contact, a person called Eric Miller, who is a doctor with the mail address em@w3.org. Note that the contact namespace, and the Person, fullname, mailbox, and personaltitle tags are not defined in RDF. The only RDF-specific things in the above code are the tags prefixed with rdf:. Its triple representation. This consists of triples of the form (Subject, Predicate, Object). Sometimes a different order and different names for the three parts are used, for example JTP (see section 2.7) uses (Predicate, Subject, Object), and the Predicate is often called Verb. Therefore the term VSO triples is sometimes used. The following was produced using a program called RDF Validator 3 from the above XML-encoded RDF data: Number Subject Predicate Object /People/EM/contac t#me /People/EM/contac t#me /People/EM/contac t#me /People/EM/contac t#me 02/22-rdf-syntaxns#type 10/swap/pim/contact#ful lname 10/swap/pim/contact#mai lbox 10/swap/pim/contact#per sonaltitle /10/swap/pim/contact#P erson "Eric Miller" mailto:em@w3.org "Dr." Subjects, predicates, and objects are described by URIs (such as Just as with XML Namespaces, these URIs do not need to actually point to a source of information. The URIs are the information themselves. Objects can also be constant string values (like Eric Miller above). Any URI can appear as the subject, predicate or object of many different triples, thus allowing chains of relations, and many 3 9

18 statements about the same resource (as seen above, where we have four triples with the same subject). Its graph representation. The above XML code and triple representation is equivalent to the graph in figure 2-2 (again, from [18]) RDFS RDFS (RDF Schema, also described in [18]) is an extension to RDF that adds a type system to it. It allows the expression of classes and subclasses, class instances, properties and subproperties, etc. An example of a class definition (from [18]): <rdf:description rdf:id="motorvehicle"> <rdf:type rdf:resource=" </rdf:description> And an instance of this class: <rdf:description rdf:id="companycar"> <rdf:type rdf:resource= " </rdf:description> This is where XML starts to look less than perfectly human-readable DAML+OIL DARPA (Defense Advanced Research Projects Agency) started the DAML (DARPA Agent Markup Language) project 4 in August 2000 in order to develop a language and tools to facilitate the concept of the semantic web. The current version of the language is called DAML+OIL (the reason for the name is that the original DAML language was combined with another language called OIL). DAML+OIL is an extension of RDF and RDFS, which means that everything that has been said about RDF(S) above also applies to DAML+OIL. However, DAML+OIL adds many important concepts to that language that add more expressiveness for the writing of ontologies. For example, it allows classes/properties to be defined as the union/intersection/inverse of other classes/properties. Here is an example DAML+OIL class, that is not possible to express only using RDF(S), 5 which shows an example of how the DAML+OIL intersectionof property can be used: <daml:class rdf:id="marriedperson"> <daml:intersectionof rdf:parsetype="daml:collection"> <daml:class rdf:about="#person"/> <daml:restriction daml:cardinality="1"> <daml:onproperty rdf:resource="#hasspouse"/> </daml:restriction> </daml:intersectionof> </daml:class> This class describes a MarriedPerson as a Person (a class declared elsewhere) with exactly one hasspouse property (this property would also be declared elsewhere). The DAML+OIL language also has a FOL (First-Order Logic) semantics for those who are interested. For example, see [19]. DAML+OIL is also the basis for the upcoming W3C standard OWL (Ontology Web Language) [20], which is currently in Last Call Working Draft (which is W3C jargon for almost finished ). This is very similar to DAML+OIL from the DAML+OIL walkthru at 10

19 2.5 Web Services: WSDL, SOAP Web services is a term that is used to denote the current trend of doing application-to-application communication over HTTP, using XML-based protocols. Using HTTP has the advantage of being able to use standard web servers to serve the information, and being able to cross firewalls. XMLbased protocols provide interoperability between different platforms and languages since only the on-wire format is standardized, not the languages used to create the XML messages or the platforms used. Less importantly, it also means that on-wire messages can easily be debugged since they are in human-readable XML. Unlike the semantic web, which is very research-oriented, interest in web services is mostly from the industry, since it is something that can give immediate benefits by connecting enterprises and their customers in ways that add value for these businesses. Three protocols currently form the core of standard web services: UDDI, WSDL and SOAP. UDDI (Universal Description, Discovery and Integration 6 ) is a standard based on an industry initiative to create registries where web services can be registered and found. As such, it is of little interest to us because we are concerned with serverless P2P systems that cannot depend on such centralized registries. WSDL and SOAP, however, are central to our work, and are discussed in the following sections WSDL WSDL (Web Services Description Language [21]) is an XML format. A WSDL document is used to describe a web service. More specifically it describes the service s programming interface in order to enable other entities to communicate with it. It defines the service s ports (methods or functions), their messages (input and output parameters), the types of these parameters, and bindings to the concrete protocol used to invoke the service (usually SOAP, see section 2.5.2). A WSDL file follows the following structure 7 : <definitions> <types> definition of types... </types> <message> definition of a message... </message> <porttype> definition of a port... </porttype> <binding> definition of a binding... </binding> </definitions> The main uses of a WSDL file are: Documentation. Developers can see how a web service works. Interface generation. Automated tools can be used to generate stubs that invoke the web service. For example the utility WSDL2Java, which is a part of the Apache Axis project 8, generates client from the web site W3Schools at

20 Java code that can be called just like a local method, but which invokes the remote web service. This is exactly like stubs for RPCs 9. In a more advanced scenario, the stub generations could be done dynamically, e.g. using reflection in Java, creating new classes and methods at run-time. Server skeleton generation. If a top-down design methodology is used, the WSDL file is written first, and then a so-called skeleton is created (this can be done using the same WSDL2Java tool). This is then filled in with the actual server functionality. If a bottom-up design is used, the server code is written first, and a WSDL file is generated from this (e.g. using Axis Java2WSDL tool if the server code is in Java) SOAP SOAP [22] is short for Simple Object Access Protocol. While it is a W3C Candidate Recommendation, it is widely used and can be considered a standard for all purposes. According to [22], SOAP is fundamentally a stateless, one-way message exchange paradigm, but applications can create more complex interaction patterns (e.g., request/response, request/multiple responses, etc.) by combining such one-way exchanges with features provided by an underlying protocol and/or application-specific information. SOAP is silent on the semantics of any application-specific data it conveys, as it is on issues such as the routing of SOAP messages, reliable data transfer, firewall traversal, etc. However, SOAP provides the framework by which application-specific information may be conveyed in an extensible manner. Also, SOAP provides a full description of the required actions taken by a SOAP node on receiving a SOAP message. SOAP is both an XML format (describing the syntax of SOAP messages), and a communications protocol, similar to RPC or RMI, 10 stating how such messages are sent and received. The SOAP messages convey information about which function/method to invoke and its parameter values, as well as any return values from such calls. An example SOAP invocation can look like this 11 : <?xml version="1.0"?> <soap:envelope xmlns:soap=" soap:encodingstyle=" <soap:body> <m:getprice xmlns:m=" <m:item>apples</m:item> </m:getprice> </soap:body> </soap:envelope> This invokes a GetPrice method with the value Apples for the Item parameter on the web server it is sent to. For information on how we use SOAP in this project, see section Semantic Web Services: DAML-S Combining the ideas of the semantic web and web services, the idea of semantic web services has emerged. The idea is that if web content can be described semantically to provide easier access to the information, then web services could be described semantically as well, in order to provide better access to the services. The idea behind semantic web services is summarized by [23]: 9 Remote Procedure Calls 10 Remote Method Invocation 11 again, from W3Schools ( 12

21 Users and software agents should be able to discover, invoke, compose, and monitor Web resources offering particular services and having particular properties. [...] The major project in this area is DAML-S 12. DAML-S is an ontology written in DAML+OIL, which is used to describe web services. It adds concepts such as input and output parameters, service parameters, textual service descriptions, and so on, to DAML+OIL. Actual web services can use the concepts in the DAML-S ontology to define their characteristics. The main parts of the DAML-S service ontology (see figure 2-3) are: [...] the service profile for advertising and discovering services; the process model, which gives a detailed description of a service s operation; and the grounding, which provides details on how to interoperate with a service, via messages [23] The last part, the grounding, requires a further comment. It is divided into 1) the DAML-S Service Grounding, which is more abstract, and 2) the WSDL Grounding 13 (WSDL is described in section 2.5.1). In this work, we are mostly concerned with the Service Profile (or just Profile ) and the WSDL Grounding. The profile is used to describe the properties of services or devices that are used by clients to evaluate them, and the WSDL grounding is needed to interoperate with the service at all, since it describes the programming interface to the service. See section 3.5 for more details on how we use DAML-S in this project. Service presents supports described by How to access it Service Profile What the service does Process Model How it works Service Grounding WSDL Grounding Programming interface Figure 2-3: Layout of the DAML-S ontology Actually, it doesn t have to be WSDL. The concrete part of the grounding can be written in other languages as well. In the examples on the DAML-S web page it is in WSDL, however, and we use WSDL in this work as well. 13

22 2.7 Reasoning Engines: JTP The web site semanticweb.org gives a good overview of the issue of reasoning for the semantic web 14. In its words: For the processing of the knowledge available in the Semantic Web are inference engine necessary [sic]. Inference engines deduce new knowledge from already specified knowledge We need such processing of knowledge to reason about our semantic services described in some ontology language such as DAML+OIL. Several inference engines are available: FaCT, Jess, and JTP seem to be the most popular. We chose JTP (Java Theorem Prover 15 ) because others recommended it, it is open source, and has a helpful (if small) online community. JTP can easily be used programatically from Java programs, or interactively using the so-called DAML Query Answerer, which proved to be very useful to try things out. To use JTP (whether programatically or interactively), its knowledge base is first loaded with DAML+OIL files. The knowledge base stores all the triples from the DAML+OIL data (in Predicate, Subject, Object order). Queries can then be asked, like this (from the README file in the JTP archive): (rdf:type?person daml+oil-ex:person) Assuming a knowledge base of Person items has been loaded, and the daml+oil-ex namespace has been defined, the answer could look something like: Bindings 1:?person = :: Ian Bindings 2:?person = :: Santa Bindings 3:?person = :: Peter Bindings 4:?person = :: Adam So, queries are written in triple format, with unbound variables named and preceded with?. Bindings for all unbound variables are returned as the answer, if JTP s inference engine can resolve such bindings. It is also possible to write conjunctive queries, such as (and (rdf:type?person daml+oil-ex:person) (some-ontology:haschildren?person true)) to find all people with children (assuming that some-ontology defines a haschildren property). See section 3.6 for information on how JTP is used in our project. 2.8 Other related technologies Here we will briefly mention a few related service discovery technologies. The reasons why we have chosen not to use them are given under the specific sections. This section is not necessary to read in order to understand this work, but it places our work in a context, and motivates some of our design decisions Bluetooth Bluetooth 16 is a short-range wireless technology for PCs and devices. It is essentially used for cable replacement. Bluetooth was invented by Ericsson, and the SIG (Special Interest Group) now includes hundreds of companies, including 3Com, IBM, Intel, Microsoft, Motorola, Nokia and

23 Toshiba. To date, Bluetooth has been used mostly to provide wireless headsets for mobile phones, but many other applications are possible, and are expected to emerge as prices go down. Bluetooth uses its own protocol stack, which we will not go into here. Its service discovery protocol is simply called SDP, and is based on simple UUID matching. It is expandable, however, as a couple of projects have shown. In [7], service discovery based on RDF or DAML+OIL is integrated with Bluetooth, and there is a paper on how to integrate the Salutation Architecture (see section 2.8.3) with Bluetooth. The approach we have chosen in this project is independent of network technology (e.g. Bluetooth, IrDA, TCP/IP), but could work on Bluetooth if a JXTA transport is implemented for Bluetooth, as mentioned in section UPnP Universal Plug n Play (UPnP) is a technology developed by the UPnP forum 17 led by Microsoft. The forum currently has over 500 member companies. UPnP is mostly a way to make home networking easier. Different devices and computers in a home environment are able to automatically discover and utilize each other using UPnP. UPnP is based on existing protocols: TCP, UDP, IP, SOAP, HTTP, DHCP and XML. The UPnP architecture defines six phases of interaction [24]: Addressing. If one is available, UPnP devices use a DHCP [25] server to obtain their IP address. If not, they use something called AutoIP. This means that the device randomly selects an IP address from a restricted range of addresses that are link-local (i.e. non-routable). It then issues an ARP [26] probe to see if this address is used, and if not it uses it. Otherwise, it chooses a new address and tries again, and so on. Discovery. When entering a network, devices broadcast a short message containing its type, unique identifier, and a pointer (URL) to more information. Entities called control points store these advertisements. Searching for a device is done by broadcasting a request for the desired device type. This is intercepted by all control points, and responses are sent back to the requester (only). This discovery mechanism is called SSDP (Simple Service Discovery Protocol), and it is based on XML messages sent over HTTP. Description. When one or more devices have been found as a result of an SSDP search, the requesting entity uses the URLs contained in the advertisements to get full device descriptions and service descriptions for the devices. These are also in an XML format, and templates for descriptions of specific classes of devices or services are being defined by the UPnP forum. The descriptions can include information about the device, actions it supports, state variables, and a presentation page. Control. Control is done by issuing SOAP requests to the methods described by the description document. Eventing. UPnP supports events, using a protocol called GENA (Generic Event Notification Protocol). This allows the device to be notified when one of its state variables have changed. Presentation. The description document can also contain an URL to a HTML page which can be used to interactively control the device (using HTML forms or whatever method the device vendor chooses). There are lots of SDKs (Software Development Kits) for UPnP 18, but few which are free-of-charge, and only two which are open source: see 15

24 The UPnP SDK for Linux 19, which is based on Intel s UPnP SDK that was released to the open source community. This supports C and C++. The CyberLink development package 20 which was only recently released. This supports Java. UPnP is nice in that it supports the whole range of device interaction, including discovery, eventing, control and presentation. Also, it would probably not be too hard to integrate e.g. DAML-S with it since it already uses XML formats for device descriptions. Its main drawback is that it depends on a specific network technology (TCP/UDP and IP), and until recently that it lacked an open source SDK for Java Salutation According to the homepage of the Salutation Consortium 21, the Salutation Architecture is a service discovery and session management protocol [...] The Salutation Architecture is independent of operating system, communications protocol or hardware platform. It provides information exchange among and between different wireless handheld devices and office automation equipment. Members of this consortium include IBM, lots of printer and digital camera manufacturers, and a large number of academic professionals. Specifications for the Salutation Architecture can be downloaded from their web page after a free registration. The following description is based on the Salutation Architecture Specification 2.1 found there. Figure 2-4 shows an overview of the Salutation Architecture (from the specification). The central piece here is the Salutation Manager (SLM). SLMs are service brokers that handle searches for services. Each device or networked entity has at most one SLM. If it doesn t have one of its own, it can use a remote SLM. Interaction with the SLM is done through the platformindependent SLM-API. When invoked, the SLM contacts remote SLMs through its Transport Managers (TMs). This is done through the SLM-TI (SLM Transport Interface). This abstracts details specific to different networks, in order to make the Salutation Architecture independent of what type of network it is running on. The SLM performs four basic tasks: Service Registry Service Discovery Service Availability Figure 2-4: The Salutation Architecture 16

25 Service Session Management Devices or entities that provide services through Salutation must describe these using Functional Units (FUs). So far, the FUs defined are Print, Fax Data Send, DOC Storage, Fax Data, Voice Message Storage, Address Book, and Schedule. FUs define attributes that devices can have. For example, a device supporting the Print FU has attributes saying whether it supports color and double-sided printing. A device registers itself and these attributes with its SLM. A discovery request is then performed by matching requested attributes with the attributes provided by any devices found in local or remote SLMs. The SLM-API and the FUs also define how the service is actually invoked (using Sun Microsystems Open Networking Computing RPC version 2 protocol). The Salutation web page has a white paper describing work that is being done to run Salutation over Bluetooth, which is very interesting. Interaction with many other technologies is also mentioned. So far, the only implementation available for download is a Windows version of Salutation-Lite, a light-weight version for resource-constrained devices such as handheld computers. Java and Windows CE versions are to come shortly. The main drawback of the Salutation Architecture is that it doesn t support DAML-S or similar intelligent techniques of reasoning about services, since service matching is purely based on simple pre-defined attributes. Nonetheless, it would be an interesting exercise to write a JXTA Transport Manager for Salutation, allowing Salutation-enabled devices to run over JXTA P2P networks SLP The Service Location Protocol is defined by [27]. The abstract of this document says: The Service Location Protocol provides a scalable framework for the discovery and selection of network services. Using this protocol, computers using the Internet no longer need so much static configuration of network services for network based applications. SLP is purely IP-based, like UPnP, but more limited in scope: It does not support eventing, control, presentation, etc just discovery. It uses proprietary formats for its messages rather than the XML that UPnP uses, so it is more limited than UPnP. For these reasons, we won t say anything more about it, except that there is an open source implementation of SLP 22 for those who are interested Jini Jini 23 is Sun s Java standard for service discovery. Unlike JXTA, which has a Java reference implementation, Jini is required to use Java under all circumstances. To make a service available, a server registers an object with an object registry. This object implements the service API using whatever technology is desired (RMI, CORBA, etc). The client searches for the specific invocation object at one or more object registries and downloads it in order to use the remote service. This is a very limited approach. It is restricted to Java, and it doesn t support any type of semantic matching. 22 at

26 3. Implementation This chapter describes how the implementation of our service discovery framework was done. First, there is a design overview which is our plan on how to meet the goals of the project (which were outlined in section 1.2). Then we discuss what languages, libraries and tools we used. After that, we go into the different phases of the implementation more or less chronologically. We try to outline important considerations, tricky problems, and the solutions we found. In real life, most of the work described under the specific sections was intertwined. All the Java classes and DAML-S files mentioned in this chapter are available on the project web page: Design Overview Technologies Used To reiterate what has already been said (in section 1.2) we base our system on JXTA. It gives us a flexible, platform independent P2P infrastructure, which we can add our service discovery mechanism to. We need three things to achieve our goal of performing service discovery with JXTA: 1. Description: A way to describe services/devices. 2. Reasoning: A way to make decisions from these descriptions. 3. Invocation: A way to perform remote communication (method/function calls). All three need to be platform independent and flexible in order to meet our goals. Chapter 2 has described such technologies: For (1) we decided to use DAML-S. There does not seem to be anything else of its kind that gives us the same expressiveness 24. Since we want to be able to describe any kind of device or service, (see section 1.2) we need this expressiveness. Using DAML-S also means that we need to use WSDL for our groundings, as explained in section For (2), a reasoning engine is required. If we were working only with name-value pairs or some similar simple matching technique, we could do without a dedicated reasoning engine. But in order to take full advantage of DAML-S, we do need one. We chose JTP, for reasons explained in section 2.7. For (3), we chose SOAP. An alternative would have been CORBA 26, but this is much more complex and heavy-weight than SOAP. Also, SOAP integrates very nicely with WSDL service descriptions, (the two are often used together) so the choice was an easy one Our Design We will start the implementation by writing a number of peers to serve as examples, and to see what is needed to implement the service discovery framework between them (while keeping in mind that the framework needs to be generalizable to any type of services and devices). These peers are: PDA Printer1 24 The upcoming OWL-S standard would be an alternative if it had been complete when we first started the project. Still, it does not have the same tool support as DAML-S, and is not as proven in implementations. 25 We could have used some other language for the grounding, but we chose WSDL because it is platform independent (one of our goals) and used in the DAML-S examples on 26 The Component Object Request Broker Architecture, see 18

27 Printer2 In our code, PDA represents a Personal Digital Assistant, a small hand-held computer, while Printer1 and Printer2 are simply printers offering print services to devices such as the PDA. Here, the printer peers are strictly service providers, and the PDA is strictly a service consumer. This looks like a client-server architecture, but it would present no problem to have all peers both consuming and producing services. All three peers will be placed in a single peergroup called Office. We first intended to have different rooms in an imaginary office, represented by different peergroups, and with different devices in them, but we simplified the design somewhat due to lack of time. We have decided on the convention that all peers that are providing services must follow a certain naming scheme. Each JXTA peer has a name given as a : -separated list. We use this to represent a hierarchy of devices. At the top level, there is Device ; at the second to last-but-one levels, there are subclasses of device (such as Printer ); and at the lowest level there is the actual instance of the device (e.g. Printer1 ). So, a whole device name has the form Device:Printer:Printer1, to follow the same example. Further considerations on the JXTA peers are found in section 3.3. All services provided by JXTA peers should be described by WSDL interface descriptions (see section 2.5.1), and (optionally) some or all of the following DAML-S files: Service. General information about the service, using concepts from the file Service.daml in the DAML-S ontology. The device-specific service file should have the form printer1-service.daml. Process. Information about how the service performs its work, using concepts from the file Process.daml in the DAML-S ontology. The device-specific file should have the form printer1- process.daml. Grounding. Abstract information about the programming interface to the service, using concepts from the DAML-S file Grounding.daml. This is the DAML-S side of the WSDL interface description mentioned above. The device-specific file should have the form printer1- grounding.daml. Profile Implementation. An implementation of a profile in a DAML-S profile hierarchy, based on the DAML-S file Profile.daml. This is explained in more detail below. The device-specific file should have the form printer1-profile.daml. (again, the above are conventions that we decide on for this project, but these conventions are also used in all the examples on the DAML-S web page 27 ). The profile hierarchy mentioned above requires a further comment. Each type of device is placed somewhere in a hierarchy of DAML-S profiles, with Profile as the root class. We have decided on a naming scheme for these profiles, summarized in the table below, that mirrors the naming for the JXTA peers that represent the devices. For example, the above printer1-profile.daml would be an implementation of the DAML-S class Profile->DeviceProfile->PrinterProfile. JXTA Name DAML-S Hierarchy Java Class Hierarchy Device:Printer:Printer1 Class Profile ->DeviceProfile ->PrinterProfile, with an implementation called Printer1_Profile Device->Printer, with an instance called Printer1 Peers that wish to use services provided by other peers need to have the four DAML-S files (Service.daml, Process.daml, Grounding.daml, and Profile.daml) pre-loaded on them. Furthermore,

28 for each type of device that the client peer want to be able to use, it must have the files in the appropriate profile hierarchy pre-loaded. So, a peer that may potentially want to use printer services needs to have the DAML-S files where DeviceProfile and PrinterProfile are defined (these files are called deviceprofile.daml and printerprofile.daml, respectively). In other words, the client must know a little bit about the kind of devices it is to deal with in advance. The profile implementation however, is not pre-loaded on the client. This represents the fact that the client does not know about specific services/devices. Section 3.5 discussed the writing of these DAML-S ontologies in some more detail. The third line in the above table will be discussed next. Apart from having the relevant DAML-S files to deal with a service or device, the client also needs some Java support classes. These classes form a class hierarchy that, again, mirrors those of the JXTA names, as well as the DAML-S profile hierarchy. The root class is called Device, and contains lots of functionality (these client-side support classes are discussed in more detail in section 3.7). This class can be subclassed to provide specific functionality for different device types. For example, the Printer class inherits the Device class to add some printer-specific functionality. Note that this is optional, however. In any case, an instance of the Device class (or a subclass of Device) is created for each other device the client deals with, and the instance is named after the JXTA name of the other device. Consult the table above for an example. Now, we need to explain how a client receives the WSDL and DAML-S files from another device. As we mentioned in section 2.2, we use JXTA s Module Specification Advertisement to announce services. This advertisement, like all JXTA advertisements, is a small XML-formatted message, that any peer wishing to announce the availability and properties of its services sends out to other peers. Arbitrary tags can be added to this advertisement, and we have used this in two ways, summarized by figure 3-1: The WSDL file describing the programming interface to the service is added as a whole under a <WSDL> tag. This WSDL data is Base64-encoded. This means that we only use the first six bits in every byte. With this encoding, we will not have any special characters, like < and &, which can otherwise confuse JXTA. If the service-providing peer has DAML-S files describing its services, the Module Spec Advertisement will contain pointers to these files. These take the form of tags called <hasretrievable...>, where... is one of DAMLSProcess, DAMLSGrounding, DAMLSService, or DAMLSProfileImpl. The content of the tags will be the actual file names of the files in question. We considered putting the DAML-S files directly in the advertisement, along with the WSDL file, but we realized that JXTA advertisements are limited in size. Also, all clients may not be interested in the DAML-S data, whereas they must have the WSDL data in order to use the service at all, so we save some network bandwidth by not including the DAML-S data directly in the advertisement. To fetch the files, the client invokes a method called getfile, with the filename of the requested file as a parameter. This is a SOAP method (like all other methods in our framework), and it should always be described by the WSDL data embedded in the Module Specification Advertisement under the <WSDL> tag. Note that the Module Spec Advertisement has a <Name> tag, containing the JXTA name of the peer. If the client is only looking for e.g. printers, it will only request advertisements from peers with names starting with Device:Printer. JXTA has * as a wild-card, so the peer will search for Device:Printer:*. After a client has fetched the DAML-S files from the other devices it is interested in, it loads these into its JTP knowledge base. The client then uses this reasoner to evaluate the services in order to decide which one to use. Using JTP efficiently from Java requires some work, described in section 3.6. We invent a method using priorities selectable by the client for the services attributes (see 20

29 Printer1 peer 1. Generates MSA semi-automatically 2. Broadcasts it so that all other peers can find it DAML-S files available for downloading Module Spec Advertisement <Name> Device:Printer:Printer1 </Name>... <WSDL> WSDL interface description here </WSDL>... <hasretreivabledamlsprocess> printer1-process.daml </hasretreivabledamlsprocess>.. PDA peer 3. Broadcasts a search for Device:Printer:* 4. Retreives the MSAs for all peers found 5. Fetches the DAML-S Files pointed to in the MSAs. Figure 3-1: How we use the Module Specification Advertisement section 3.7). Apart from all of the above, we need to decide how the construct the GUI to the system. This design is rather simple and straightforward, and is be covered in section What needs to be done In order to fulfill the goals given in section 1.2, using the design outlined in the previous section, what we need to do more specifically is the following: Writing the JXTA peers for PDA, Printer1, and Printer2. See section 3.3. Enabling communication between peers by using JXTA over SOAP. See section 3.4. Writing the DAML-S profile hierarchy for printer devices (i.e. deviceprofile.daml and printerprofile.daml). Writing DAML-S descriptions of the printer peers (i.e. printer1-profile.daml, printer1- service.daml, and so on). See section 3.5 for this and the previous point. Working with JTP to allow easy access from Java and manipulation of DAML-S files. See section 3.6. Writing the client-side support classes (e.g. the Device and Printer classes) and inventing an evaluation system for services with priorities. See section 3.7. Writing the GUI. See section Languages, Libraries and Tools used First of all, we chose to use Java. We had three main reasons for this: Ease of development. Java provides a solid software engineering platform with excellent object orientation, exceptions, easy memory management with a garbage collector and so on. Libraries. Java is one of the most popular programming languages, so there is an enormous amount of freely available libraries for all sorts of purposes, that one can use. 21

30 JXTA s stable reference implementation is written in Java. After the decision to use Java had been made, it was relatively easy to find appropriate libraries to do some of the things we needed to do: JXTA has already been mentioned, for our P2P infrastructure. See section 3.3 for more information on how we used JXTA. WSDL4J (WSDL for Java 28 ) was used for some additional WSDL functionality. Log4J 29 was useful for logging. There are advantages of using a generic logging tool instead of printing all the debug information to the console (e.g. using println() statements throughout the code). We can format all the printouts in a common, centralized way, and direct the output to different targets. We used an existing piece of code that outputs Log4J output to a Java Swing JTextArea object to do our log windows. Ant 30 is something like Java s equivalent of the Make tool that is almost always used in C/C++ projects to simplify the compile/build process. Java can also use Make, but Ant has several advantages: It is platform-independent (like Java), which means that platform-specific commands (e.g. normal UNIX tools that are often invoked from Make-files) are replaced with pre-defined, platform-independent tasks. These are a huge plus for Ant. Making Ant targets to build or rebuild the binaries, creating tar archives of the source tree, creating Javadoc documentation, and so on, is all very easy to do. We had great use of Ant to simplify the day-today chores in this project. JTP is the inference engine we chose to do the reasoning on our DAML-S data. See section 3.6 for more information. To write the DAML files, we could have used a graphical ontology editor. The most prominent choices that support DAML+OIL are Protégé 31 and OilEd 32. However, we wanted to learn and fully understand DAML+OIL, and felt that this would be easier if we wrote the files by hand. Also, we had the feeling that our files would not be unreasonably large, in which case using a graphical editor might have been more worthwhile. Instead, the DAML emacs mode 33 was very useful when writing and modifying the ontology files. The DAMLValidator 34, although behaving somewhat strangely, was useful to catch simple bugs in the DAML+OIL files. Further problems were caught when loading the files into JTP (see section 3.6). 3.3 The JXTA peers The first step was to create a few JXTA peers to represent different devices, and have them communicate over the network. This was no problem. We quickly got the peers programmed, configured, running, and happily talking to each other. [28] was a good help. As has been mentioned, there are currently three example peers: Two printers, called Printer1 and Printer2, and one client that can look for any provided services, such as these printers, called Pda (representing a PDA, a Personal Digital Assistant). These peers are Java classes in the se.liu.ida.sim

31 package 35. To better understand JXTA concepts, here follows an outline of what the PDA peer does in terms of JXTA: 1. It tries to retrieve the Net Peergroup, using the following code: netpg = PeerGroupFactory.newNetPeerGroup(); A peer must have the net peergroup in order to find and/or create other peergroups. The net peergroup is always the starting point for any peer. It contains services for the most basic functionality. A peer does not normally need to do any remote communication do retrieve this, but resource-constrained embedded devices could use a remote proxy that provides them with the basic services. 2. The PDA tries to find an existing Office peergroup. It looks both in its local cache, and issues a remote request, for the peergroup advertisement advertising this peergroup. It does this a number of times to overcome any network problems. In JXTA s TCP/IP transport, UDP datagrams are used for all advertisements and advertisement requests, so it is unreliable. More generally, P2P programming should always be done with an unreliable network in mind. Peers are expected to move in and out of reach all the time. JXTA assumes this unreliability as the norm. 3. If the peergroup advertisement is not found, the PDA creates a new one and publishes it, i.e. sends it to all reachable peers. 4. The PDA stores the discovery and pipe services of the Office peergroup. The discovery service is necessary to find other peers in the group (e.g. the printers), and the pipe service is used to create pipes for communication with other peers in the group. The above is typical for any JXTA peer, and more or less the textbook approach. A note on the local cache: This is stored in the.jxta sub-directory of the directory the peer is started from. We empty this cache from our run.sh scripts before starting the peers, because it is a source of unpredictability. Especially when the peers were under development, this proved to be a big hassle. In production code, the cache would not be emptied, of course. It is meant to provide faster operation by caching remote advertisements, and stale advertisements disappear after an expiration time that defaults to two hours. 3.4 Modifying JXTA-SOAP The next step was to find some way for the peers to communicate. JXTA does not prescribe how to do this. It does define a message format to send arbitrary messages between peers, and pipes to send these through, but not how peers should handle messages, or a remote method invocation system. The easiest way would probably have been to use Java RMI, but this would restrict peers to be programmed in Java, and we wanted things to be platform-independent. After some research on current technologies in the area, SOAP (see [22] and section 2.5.2) seemed like the most promising candidate. Normally, SOAP messages are put into HTTP requests/responses, and handled by a web server on the server side. Since we re using JXTA and don t want to be limited to using HTTP for reasons of platform independence, we would prefer to put SOAP messages into JXTA messages, and to send these through JXTA pipes. Fortunately, important work on using SOAP with JXTA had already been done in the JXTA-SOAP code by Kevin Burton 36. JXTA-SOAP is a transport for Apache 35 We follow the convention of naming our packages after our URL (ida.liu.se) backwards, and adding a discriminator of some kind (such as sim ) to separate packages from one another

32 Axis 37, a popular open-source web services platform for Java. Axis has a plug-in architecture that allows other transports than the default HTTP transport. JXTA-SOAP is such a transport plug-in to allow SOAP to work over JXTA. When JXTA-SOAP is used, the SOAP messages are put in JXTA messages and sent through JXTA pipes, rather than put in HTTP messages and sent over TCP/IP, and this is exactly what we want. Before we could use JXTA-SOAP to full advantage, we had to do quite a bit of work on it. This work could be summarized as follows: 1. First of all, it had a number of bugs, which we fixed. 2. JXTA-SOAP was written for a pre-1.0 version of JXTA (which is now in version 2.0). We updated the code in the necessary places to compile and work with JXTA 2.0, as well as the newest versions of other supporting libraries (Log4J, Xerces, Apache Axis and so on JXTA- SOAP uses quite a few libraries, which dramatically increased the size of our code. More on this later). 3. Most importantly, we added a number of features, including: Convenient little methods here and there to make the programmer s life easier. The ability to add arbitrary additional parameters to the Module Specification Advertisement, which we needed to put our <WSDL> and <hasretrievable...> tags into it, as explained in section WSDL support. Apache Axis has some WSDL support, and this was integrated with JXTA- SOAP (which previously did not take advantage of WSDL). At this point, we had peers able to invoke services from each other, and the ability to use proper WSDL descriptions of those services. This is an important and useful step in itself. But our goal was to provide semantic information about the services using DAML-S. Next section details how we wrote the DAML-S ontologies for our devices. 3.5 Writing the ontologies In the current implementation, our client peer (the PDA) mostly uses the information in the DAML- S Profile. This is where we describe the information about the service that clients should use for service discovery. DAML-S Profiles have a property called serviceparameter, which we have used to point to something we call device configurations. A device can have one or more such configurations to describe different combinations of values for its parameters, or different ways it can be used. For example, Printer2 has one slow-printing high-resolution mode, and one fastprinting low-resolution mode: <profile:serviceparameter> <printer:printerconfiguration rdf:id="printer2-printconfig1"> <profile:serviceparametername> Printer 2 Configuration 1 </profile:serviceparametername> <profile:sparameter rdf:resource="#printer2-printconfig1data"/> </printer:printerconfiguration> </profile:serviceparameter> <profile:serviceparameter> <printer:printerconfiguration rdf:id="printer2-printconfig2"> <profile:serviceparametername> Printer 2 Configuration 2 </profile:serviceparametername> <profile:sparameter rdf:resource="#printer2-printconfig2data"/>

33 </printer:printerconfiguration> </profile:serviceparameter> <device:deviceconfiguration> <printer:printerconfigurationdata rdf:id="printer2-printconfig1data"> <printer:printtechnology rdf:value="laserjet"/> <printer:papersize rdf:value="a3"/> <printer:papersize rdf:value="a4"/> <printer:resolution rdf:value="300"/> <printer:colorcapability rdf:value="true"/> <printer:ohcapability rdf:value="false"/> <printer:printspeed rdf:value="6.0"/> </printer:printerconfigurationdata> </device:deviceconfiguration> <device:deviceconfiguration> <printer:printerconfigurationdata rdf:id="printer2-printconfig2data"> <printer:printtechnology rdf:value="laserjet"/> <printer:papersize rdf:value="a3"/> <printer:papersize rdf:value="a4"/> <printer:resolution rdf:value="600"/> <printer:colorcapability rdf:value="true"/> <printer:ohcapability rdf:value="false"/> <printer:printspeed rdf:value="3.0"/> </printer:printerconfigurationdata> </device:deviceconfiguration> The definitions of the different properties are found in the Profile for the appropriate device. For example, the printspeed property is defined in printerprofile.daml, like this: <daml:datatypeproperty rdf:id="printspeed"> <rdfs:subpropertyof rdf:resource="#printerconfigurationproperty"/> <rdf:type rdf:resource="&daml;#uniqueproperty"/> <rdfs:domain rdf:resource="#printerconfigurationdata"/> <rdfs:range rdf:resource="&dt;#printspeedtype"/> <device:comparisontype rdf:resource="&device;#greaterthanorequal"/> </daml:datatypeproperty> (We do not give all details here, see the entire file for more information on what e.g. #printerconfigurationproperty is). Note that the range of values for this property is &dt;#printspeedtype. &dt; is a short-hand for the file:printerprofile-dt.xsd namespace, and this is a file that goes with printerprofile.daml and contains its data type definitions. PrintSpeedType looks like this, for example: <!-- this will be interpreted as pages/minute --> <xsd:simpletype name="printspeedtype" > <xsd:restriction base="xsd:float"> <xsd:mininclusive value="0.0"/> <xsd:maxinclusive value="100.0"/> </xsd:restriction> </xsd:simpletype> We see that it is an XML Schema float, restricted to the interval [0.0, 100.0]. Now that we had written the ontologies, and created peers to share and download them, respectively, we needed to actually make use of them. For this, we started working with JTP, which is what the next section is about. 25

34 3.6 Working with JTP We explained the basic functionality of JTP, the Java Theorem Prover, in section 2.7. This section explains how we used and integrated it in our project, and we summarize the Java class hierarchy for our JTP-related classes in figure 3-2. First, we needed a useful API. As it was, JTP was a bit hard to work with. We took code from JTP s interactive shell, found in the class jtp.ui.queryanswereringcontext and adapted it to work programatically (i.e., from Java). Our class, like QueryAnsweringContext, extends the class jtp.context.daml.damlreasoningcontext. Our new class is called jtp.context.daml.extendeddamlreasoningcontext (for lack of a better name). This class should be useful for anyone programming with JTP and something like this should really be included in the JTP distribution. Furthermore, we created the class jtp.context.daml.damlsreasoningcontext, which subclasses ExtendedDamlReasoningContext with some pre-made JTP queries to find device configurations and evaluate them, and also a method to set up some namespace aliases to avoid having to write out the entire namespaces for entities when we write the queries. For example xsd: can be used instead of A few JTP queries are also done from the class se.liu.ida.sim.discovery.device, which will be covered in the next section. It should be noted that the original version of JTP that we used was extremely slow. It would take around a minute to load all the ontologies, and we considered changing to some other inference engine. Then we got our hands on a pre-release version of the next release of JTP (which is supposed to be out soon at the time of writing) and this was orders of magnitude faster, (albeit still CPU intensive) so we stuck to that. Memory consumption is still very large, going up to about 145 MB for our test runs. jtp.context.daml Package jtp.ui Package DamlReasoningContext Inherits ExtendedDamlReasoningContext Inherits QueryAnsweringContext Inherits DamlsReasoningContext Figure 3-2: Part of JTP s class hierarchy 3.7 The client-side support framework At this point we had working JXTA peers, the ability to execute remote methods, fetch the DAML- S files, and reason about them. In order to facilitate the management of all the information that the client peer needs to handle, we decided to create some client-side support classes. These classes are in the Java package se.liu.ida.discovery, and are summarized in figure 3-3. First of all, we have the classes that map to the JXTA/DAML-S hierarchies, as described in section (and especially the table in that section). The base class is simply called Device. This has lots of functionality, and there is no absolute requirement for specific devices to subclass this this is 26

35 only necessary if e.g. pre-made queries or wrappers for method invocations to the device are needed. Most of the work in this class is done by the constructor. When first created, Device objects look at the Module Service Advertisement provided to their constructor, and try to fetch the DAML-S files given in this advertisement. When they have been fetched, the information from these DAML-S files is immediately loaded into the JTP knowledge base associated with the Device object. The subclasses of Device defined so far are Printer and Wallscreen. Do not confuse these with the Printer1, Printer2, and Wallscreen classes in se.liu.ida.sim. The ones in sim are the actual peers providing the services, whereas the ones in discovery are client-side support classes. The Wallscreen classes are just place-holders for an empty class. This was supposed to simulate a wallmounted screen that e.g. PDAs could view images on (along with printers, this is a typical example in ubiquitous computing texts). The construction of Device objects is done through the class DeviceFactory (and the constructor in the Device class has only package visibility to ensure this). DeviceFactory has methods that take Module Specification Advertisements as a parameter, and creates the appropriate object of class Device or a subclass of Device, depending on the JXTA device name in the advertisement. For example, if the advertisement specifies the <Name> of the device as Device:Printer:Printer1, DeviceFactory creates a Printer object. The DeviceMapper class is a small singleton class (i.e. there is always at most one instance of the class) that associates the Java Device objects that have been created, with their respective DAML-S Profile names. The JTP queries will obviously not return Java objects, so we need this to connect the DAML-S descriptions with the Java objects. The Search class is used to construct a search for devices, which can then be evaluated by DamlsReasoningContext. It uses the small helper class SearchPair in the following way: (Propertyname, SearchPair) pairs are stored in a HashMap (a standard Java class) in the Search object. The SearchPair object contains a requested value and a priority for this search criterion. Priorities range from 1 to 10, where 10 is the highest. Each device configuration that is evaluated with the Search object will acquire a score to represent how good a match it is for the search. A higher value is better. The score starts at zero. For each fulfilled search criterion, the priority associated with that criterion is added to the score. Furthermore, if a criterion with priority ten (10) is not fulfilled, the total score for the configuration will be zero. In other words, priorities one to nine represent preferred properties, while priority ten represents a required property. This should be easy to understand when using the interactive GUI, described in the next section. A further note on the evaluation of properties: Some properties (like printspeed) are evaluated by checking if the profile has such a property with a value that is higher than or equal to the requested value. If the client wants a print speed of four pages per minute s/he is not going to complain if s/he gets a printer with six pages per minute. This doesn t work for all properties however. For example, there is no better than or equal relationships defined for paper sizes (or, formally, the papersize property). Here we want the values to be compared by string equality. If we want A3 paper size, then that s what we want. To describe how a property should be compared, it can have a comparisontype property, which has an instance of the class Relation as its allowed range: <daml:class rdf:id="relation"> <daml:oneof rdf:parsetype="daml:collection"> <Relation rdf:id="lessthan"/> <Relation rdf:id="lessthanorequal"/> <Relation rdf:id="equal"/> <Relation rdf:id="greaterthanorequal"/> <Relation rdf:id="greaterthan"/> </daml:oneof> </daml:class> 27

36 Going back to section 3.5, we see that printspeed has greaterthanorequal as its comparisontype. se.ida.liu.discovery Package DeviceFactory Creates DeviceMapper Maps to DAML-S Profile names Printer Inherits Device Inherits OtherDevice... Search Uses SearchPair Figure 3-3: The client-side support framwork 3.8 The GUI Part of the goals of the project was to provide a graphical user interface (GUI). The classes for this are in the se.liu.ida.gui package, summarized by figure 3-4. What we provide is a window where searches for different devices can be executed (with arbitrary priorities for the defined properties). Results are shown, along with their scores (see section 3.7 for a description of how the scoring is done). Various information about the found devices can be accessed by clicking different buttons. We feel that this demonstrates the search mechanism, and packages a lot of complex technical information in a rather nice way. The classes in the gui package are: LogWindow. This is the first thing seen when one of the peers is started. LogWindow provides a window where information to the user can be printed, using Log4J. PdaWindow. This is the main window of the GUI. It is closely tied to the se.liu.ida.sim.pda class, i.e. the PDA peer. It is also the class whose main() method should be run on the client side when the GUI is to be used. For console-only operation, the main() method of Pda is used instead. These main() methods are executed when the different versions of the start-up scripts are executed, see the next section. ProgressWindow. This is the progress window that comes up when the Search button is clicked on the PdaWindow, to reduce user anxiety. DeviceSearchPanel. When the user changes the selection on the device chooser (on the top left of the PdaWindow), a DeviceSearchPanel for that JXTA name selection is loaded and inserted under the chooser. There are no generic search criteria implemented for just Device (or Device:* in JXTA terms), so when the PdaWindow loads, the text No search criteria are implemented for this device, or the device type is unsupported appears. If the device chooser selection is changed to Device:Printer:*, a PrinterSearchPanel (a class that subclasses DeviceSearchPanel) will appear below the chooser. This lets the user create a search using all the properties that have been defined for printer devices. Currently, all device types must have such pre-programmed search panels if 28

37 they are to be used with this GUI. Ideally, the search panel would be generated automatically from a DAML-S description of how communication with the device type should happen. This is left as a future development. javax.swing Package JFrame JPanel Inherits Inherits se.ida.liu.gui Package LogWindow PdaWindow DeviceSearchPanelFactory DeviceSearchPanel Creates ProgressWindow Inherits PrinterSearchPanel OtherDeviceSearchPanel... Figure 3-4: The GUI classes For the PdaWindow to know which DeviceSearchPanel to use, the DeviceSearchPanelFactory class is used. This class has a method that takes the device type (such as Device:Printer:* ) and returns the appropriate DeviceSearchPanel object. 3.9 Running the GUI Examples are always useful to understand complicated things, so we provide a complete run of the three peers, using the interactive GUI to see what happens on the client side. (The console version, see below, is purely non-interactive, and just shows a pre-programmed example use of the system.) To begin with, you need to have a working Java installation to run this simulation. Recent versions (for a large number of operating systems) are available on Sun s Java web pages 38. To run the simulation in a UNIX/Linux environment, download the archive with a name of the form elenius-exjobb-yyyymmdd.tar.gz from the project homepage 39. The peers are started by running the shell scripts called run.sh in the subdirectories under sim/test. To run the graphical version, execute the run-gui.sh script instead of run.sh for the PDA (the printers are always started with their run.sh scripts). To run the simulation under Microsoft Windows (any version), download the archive with a name of the form elenius-exjobb-yyyymmdd-windows.zip from the same location. The peers are started with the run.bat files in the subdirectories undert sim\test. To run the graphical version, execute the

38 run-gui.bat file instead of run.bat for the PDA (the printers are always started with their run.bat scripts). Note that you will need three different terminals/command windows to run the three peers. The peers can be started in any order. The behavior of the system will vary slightly depending on this order the peer that is started first will create the Office peergroup, and the others will discover the peergroup announcement for the group and join it. The first thing that happens when one of the peers is started is that its log window appears. The one for the PDA looks like figure 3-5 when the peer has finished loading. Figure 3-5: PDA log window The log windows for the printers are similar. We can see from this log that the first thing the client does is load the DAML-S files, and its predefined DAML-S profile hierarchy. Currently this is just the base DeviceProfile and PrinterProfile, but a client supporting more devices would load more profiles here. After this, the client joins the Office peergroup (in this case, one of the printer peers was started first, so an existing advertisement for the peergroup was found). After this, the main window of the GUI comes up. See figure 3-6. Figure 3-6: PDA main window after just starting up 30

39 The starting device selection (top left) is Device:*. Since there is no search criteria defined for this device class, no search panel will appear below the device chooser. When we change the selection to Device:Printer:*, the DeviceSearchPanelFactory is invoked, and returns the PrinterSearchPanel (see section 3.8). The window takes on the look of figure 3-7. Figure 3-7: PDA main window after choosing a device type The values to the right in the search panel are the selectable numeric priorities for the values that are chosen for the properties in the panel. A property with a value of zero will not be included in the search. After we have selected some priorities and clicked the Search button, a number of things happen. First of all, the ProgressWindow appears (and the search button is deactivated, preventing several searches from going on at the same time, which would complicate things unnecessarily for this simple demo). See figure 3-8. Figure 3-8: Progress bar, searching for Module Spec Advertisements Like the text in the window says, the first thing that happens when a search is executed is that the peer looks for advertisements (Module Specification Advertisements, to be more precise) with a Name field that matches Device:Printer:* (remember that the * is a wild card that matches anything, in our case it would match Printer1 and Printer2 ). If the printer peers have been started, the client peer will go on to create Device objects of the appropriate type from the information in these advertisements, using the DeviceFactory class. The text in the progress window changes to reflect this. See figure 3-9. Figure 3-9: Progress bar, creating Device objects In this case, we will get two Printer objects. This step takes a while because the DAML-S files 31

40 describing the printers have to be downloaded from them (according to the information in the Module Spec Advertisement) and loaded into the client s JTP knowledge base. If we look at the log window for one of the printers at this stage, we see evidence of this action. See figure Figure 3-10: Printer log window The search finds two devices, which are added to the Results panel (the middle part of the main window). See figure Figure 3-11: PDA main window after found devices have been evaluated Printer1 has a score of zero, because it doesn t have color printing capability. If we select e.g. Printer2 and click on the Device Configurations button, we get more detailed information on this printer s configurations. See figure Here, we see that the printer has two configurations, one with score 10 and one with score 16, for this search. Only the highest score appears in the results panel. It is worth trying out stopping and re-starting the printers at different times and see that the client behaves correctly A known problem is that a peer started at the same time as another peer (or very close to the same time) will not have time to discover that the Office peergroup has already been created, and will therefore go on to create it itself. The result is that it ends up in its own peergroup without being able to reach the other peers. If this happens, the faulty peer can just be re-started. I consider this a minor bug with JXTA, that should be solved by introducing appropriate delays, etc. 32

41 3.10 Adding more devices This section details what steps have to be taken in order to add more devices to this system. We assume Java is being used. 1. Write the service. Write a class with methods that look just like normal, nonremote methods. See se.liu.ida.sim.printer1service for an example. The methods should be static, because SOAP does not know about object instantiation. Furthermore, the service must include the getfile method to be able to respond to requests for its DAML-S files, so just copy this method from Printer1Service. 2. Generate a WSDL file for the service. This is usually done automatically with an appropriate tool. For example, we used the Java2WSDL 41 tool to generate the file printer1.wsdl from our Printer1Service class with the command-line: java org.apache.axis.wsdl.java2wsdl -o printer1.wsdl se.liu.ida.sim.printer1service -l" This assumes all the Apache Axis.jar files are in the Java classpath. The resulting file may need some manual editing. This is often the case with WSDL files, due to different tools creating slightly incompatible files, ambiguities in the WSDL protocol, or special requirements we may have on the output that cannot be known by the tool. For example, in our printer1.wsdl file, we changed <wsdl:message name="setpapersizerequest"> <wsdl:part name="papersize" type="xsd:string"/> Figure 3-12: Two device configurations to </wsdl:message> <wsdl:message name="setpapersizerequest"> <wsdl:part name="papersize" type="impl:papersizetype" damls:daml-s-parameter= "pr1_process:#printer1_papersize"/> </wsdl:message> These changes are non-trivial and require a good understanding of DAML-S, WSDL, and XML Schema. The change from xsd:string (the standard XML Schema type that Java String variables will be represented by, by default) to impl:papersizetype is because we have defined a specific type for PaperSize values that only allow certain strings ( A4, A3 and Letter currently). The daml-s-parameter is not strictly necessary, but it says which input in the DAML-S process model this parameter represents). 3. If a profile is not defined for the service/device in the standard profile hierarchy (which currently includes only deviceprofile.daml and printerprofile.daml), then one needs to be written. See the existing profiles for examples. 4. If the device type is to have any pre-defined client-side functionality other than what s in the Device class, then the appropriate subclass of Device needs to be written. See the Printer class for an example. If such a new class is written, then update the DeviceFactory methods to return objects of this type when appropriate. 41 Part of the Apache Axis project ( 33