LANGUAGE INDEPENDENT SOFTWARE COMMUNICATION IN DISTRIBUTED APPLICATIONS

Transcription

1 MASTER S THESIS LANGUAGE INDEPENDENT SOFTWARE COMMUNICATION IN DISTRIBUTED APPLICATIONS AUTHOR: VELI PETTERI JÄRVINEN MYNTINTIE 12 A NUMMELA FINLAND Tel ADVISORS: KARY FRÄMLING, Ph.D., Project Manager of the Dialog research project MATTI VUORINEN, Ph.D., University of Helsinki, Department of Mathematics

2 UNIVERSITY OF HELSINKI Faculty Faculty of Science Department Department of Mathematics Author Veli Petteri Järvinen Title Language Independent Software Communication in Distributed Applications Subject Applied mathematics Level Master s Thesis Abstract Month and Year November 2002 Page count 72 This work presents the most popular XML based communication protocols and the XML technologies used alongside (XML-RPC, SOAP, Jabber, XML Schemas, XML Namespaces). The usability of the protocols is being evaluated and the process of realizing language independent software communications between network endpoints is carried out using the presented techniques. The work also participates in the ongoing discussion of the future of the Internet and highlights the problem of standardization that different industries need to overcome before the Internet can be seriously used in efficient and automated information exchange. TAI Research Institute of Helsinki University of Technology hosts a scientific project named DIALOG, which explores new methods of product information management for various industries. Key concepts of this research are product identification, highly automated information exchange and the use of the Internet. The purpose of this thesis was to study how the recent development of different XML technologies could be utilized in the DIALOG project. Keywords Communication protocols, XML, standardisation, Web Services Where deposited Department of Mathematics, University of Helsinki Additional information This work was done at TAI Research Institute under the supervision of Ph.D. Kary Främling and Ph.D. Matti Vuorinen 2

3 Contents CONTENTS 3 ABBREVIATIONS 6 1 INTRODUCTION DISTRIBUTED APPLICATIONS AND THE INTERNET GOALS OF THIS THESIS THE DIALOG PROJECT 9 2 AVAILABLE TECHNIQUES THE EVOLUTION OF PROTOCOLS THE COMMON OBJECT REQUEST BROKER ARCHITECTURE (CORBA) DISTRIBUTED COMPONENT OBJECT MODEL (DCOM) XML RPC SIMPLE OBJECT ACCESS PROTOCOL (SOAP) XML THE BASIC LAYER OVERVIEW XML SCHEMAS AND NAMESPACES XML-RPC SERIALIZATION IMPLEMENTATIONS LIMITATIONS SOAP V OVERVIEW SERIALIZATION PACKET STRUCTURE AND PROTOCOL EXTENSIONS IMPLEMENTATIONS LIMITATIONS JABBER EMBEDDING XML PROTOCOLS JABBER ARCHITECTURE XML STREAMING JABBER CONVENTIONS EMBEDDING STRUCTURED DATA IMPLEMENTATIONS LIMITATIONS 27 3 IMPLEMENTATIONS AT WORK AUTOMATED EVENT MONITORING 28 3

4 3.2 PRODUCT IDENTIFICATION TECHNICAL DEVICES THE DIALOG WEB APPLICATION FEATURES MOTIVATION FOR LANGUAGE INDEPENDENCE SOAP IN DIALOG APACHE SOAP TME GLUE COMPARISON GLUE 2.3 PROTOCOL ARCHITECTURE SOAP SERVER INTERFACES FOR DIALOG SOAP CLIENT SIDE FOR DIALOG JABBER RPC IN DIALOG JABBER SETUP THE SERVER COMPONENT THE CLIENT COMPONENT SECURITY CONSIDERATIONS SOAP EXTENSIONS JABBER SECURITY 43 4 EVALUATION SOAP VS. XML-RPC MESSAGE SIZE SOAP VS. RMI PERFORMANCE COMPARISON FIREWALLS & PDA HOSTS JABBER COMMUNICATIONS DYNAMIC MESSAGES CHALLENGING HTTP? GATEWAYS FIREWALLS & NETWORK LATENCY THE REST PHILOSOPHY AND WEB SERVICES VERTICAL VS. HORIZONTAL SOAP VS. XML SCHEMAS RESTIFYING WEB SERVICES SUMMARY NETWORK-BASED COMMUNICATION DESIGN OBSTACLES TO INTEROPERABILITY WHERE ARE THE APPLICATIONS? 56 5 WHAT NEXT? THE FUTURE OF WEB SERVICES STANDARDIZATION EFFORTS INTELLIGENT AGENTS AND WEB SERVICES THE WEB SERVICE BROWSER XML TOMORROW 61 4

5 REFERENCES 62 BOOKS 62 ARTICLES 62 WHITE PAPERS 62 WEB SITES (LAST VISITED ) 62 APPENDIX A 65 APPENDIX B 66 APPENDIX C 67 APPENDIX D 68 APPENDIX E 70 APPENDIX F 71 5

6 Abbreviations ASCII American Standard Code for Information Interchange API Application Programmer s Interface BMP Bitmap file format DNS Domain Name Service DTMF Dual Tone Multi-Frequency (e.g. signals for numbers in cell phones) EPC Electronic Product Code FTP File Transfer Protocol GIF Graphics Interchange Format HTML HyperText Markup Language HTTP HyperText Transfer Protocol IANA the Internet Assigned Numbers Authority ID Identifier IDL Interface Description Language IIOP Internet Inter-ORB Protocol IM Instant Messaging IP Internet Protocol JID Jabber Identifier JSM Jabber Session Manager JPEG Joint Photographic Experts Group LPC Local Procedure Call MIT the Massachusetts Institute of Technology OMG the Object Management Group ONS Object Name Service ORB Object Request Broker PDA Personal Digital Assistant REST Representational State Transfer RFID Radio Frequency IDentifier RMI Remote Method Invocation RPC Remote Procedure Call SGML Standard Generalized Markup Language SMS Short Message Service SOAP Simple Object Access Protocol (plain SOAP since version 1.2) SSL Secure Socket Layer TCP Transmission Control Protocol UDDI Universal Description Discovery and Integration URI Uniform Resource Identifier W3C the World Wide Web Consortium WAV Audio file format WSDL Web Service Description Language WWW the World Wide Web XML extensible Markup Language 6

7 1 Introduction 1.1 Distributed Applications and the Internet After an extremely rapid expansion during the 1990 s the Internet began to have an effect on almost everyone s lives in the western civilisations. There were people who thought, that just by having the ability to reach masses of consumers a solid ground for successful e-business was established. These people then managed to set up a mass hysteria among the economic industry leading up to major investments in companies which had no grasp of reality in designing network-based software products that would have had any chance of making profit. Now that most of those companies are wiped out and the investors have gained a little more insight of electronic commerce, dust is beginning to settle and the problems of making commercial use of the Internet are thoroughly addressed. Network-based computing means that in delivering an expected result a software product manages some of its operations on different machines over a network. Being a net of machines with computing power, the Internet is an environment where this is the case by default. The emerge of communicating protocols, such as File Transfer Protocol (FTP) in the 1970 s and Hypertext Transfer protocol (HTTP) in 1990, made it early on possible for software developers to create distributed software components independently. Adoption of communication rules that define a protocol clearly simplified designing of a network-based software product, because now one could concentrate on a single component on a single machine. Distributed computing became hidden behind the interface of a communication protocol, and autonomous software components could be developed by developer groups with no mutual engagement. Tim Berners-Lee realised his vision of the World Wide Web (WWW) in 1990, after which network-based computing soon became an everyday matter in the shape of web browsers and web servers. Browsing the Web is still the most popular service the Internet provides and the long awaited electronic revolution of commercial industries 7

8 is yet to be seen. There are attempts under way to form a coherent set of rules that define the procedure of putting a software service on the Internet. Although banks and bookstores among other businesses are currently offering human centric services on the net, it is strongly believed [WebSe, ch.1] that a unified protocol is needed before stand alone computer-to-computer software services have a chance to succeed. 1.2 Goals of This Thesis The World Wide Web Consortium (W3C) is a group of around 500 organisations and its mission is to develop the use of the World Wide Web by creating helpful Web standards. W3C has undertaken the task of defining the rules which every software service on the Internet should follow. One issue is interoperability between software components that have independent developing environments. It is reasonable to allow multicultural software development to exist to assure, that also the tools we use are developed in the spirit of free enterprise. And because people are different, also the tools, that they can make the best use of are different. So, it might be the case that a software component written in one programming language would want to utilize a software service written in another. This general scenario is actually taken as the basis for designing a protocol that would enable language independent software communication between components hosted by operation systems of any kind. This thesis will present various modern methods of achieving language and platform independence in software communication. The common characteristics for these methods are that they are referred to as protocols and that they all are XML based. Extensible Markup Language (XML) is also a creation of W3C and the following chapters will illustrate how it is applied by these protocols and what effect it has on software performance issues. The Dialog Project at TAI Research Centre serves as an evaluation environment for the protocols to be presented and as an inspiration source for some use case scenarios where the established platform and language independence is utilized. 8

9 1.3 The Dialog Project At TAI Research Institute in Helsinki University of Technology there is a scientific project in progress focusing on [Kär02,p.6] item level information management and the integration of material and information flows. The Dialog Project introduces a new convention of linking a collection of data and a product together with an address type (identification@uri) of product code. When products are equipped with some means of storing the code, they can utilize suitable software services in managing their own product information databases over the Internet. Bar codes and Radio Frequency Identification (RFID) tags are the two most popular ways of linking a material entity with its virtual counterpart. Using appropriate reader devices to transmit the code to a computer, a software component can trigger programmatic actions provided by that particular piece of software. This can of course be anything a computer is capable of, like sending information across the Internet to another computer. When two independent software components exchange information, they follow the same communication protocol i.e. they adopt the same set of rules defined for that type of software communication. If both components are written in the same programming language, there usually is a standard procedure for software communication across the Internet. For example, since the version JDK1.1 there has been the Remote Method Invocation (RMI) protocol in Java, which is a set of helper classes managing the software interaction over the net. The Dialog Project has successfully utilized this feature in Java, but if there is no certainty that the communicating components are written in the same language, or if the other component is hosted by an operating system that doesn t support the required functionality, a language and platform independent solution is needed. These are matters to be taken into consideration by the Dialog Project, since the research field covers the usage of hand held devices, such as mobile phones which do not have RMI capabilities, and since the software components in the Dialog web application are meant to be strictly autonomous software agents. 9

10 2 Available Techniques 2.1 The Evolution of Protocols The need for language independent software communication protocols increased largely after the Internet made application-to-application data exchange possible. So, it is no wonder that there are a number of solutions to choose from. Unified standards of data presentation form the basis for successful data exchange and text (ASCII, UniCode), pictures (GIF, BMP, JPEG, ) and sound (WAV) can easily be communicated between different languages. The protocol merely defines the course of action that the communicating parties are bound to follow through that standardised binary flow. However, programming languages have their own characteristics in presenting different data types, and the essence of language independent communication is the conversion of language specific data presentation to a standard form and providing sufficient metadata for the reverse conversion in the other end. The one asking for information is called a client and the one answering the call is referred to as a server. The roles may well switch several times during the connection, or not if it is a question of a pure client-server interaction like ordering a web page to a browser The Common Object Request Broker Architecture (CORBA) The Object Management Group (OMG) introduced the Common Object Request Broker Architecture (CORBA) as a specification for distributing software objects over a network in OMG is [OMGpg] an organisation, very much like W3C, that produces specifications and technologies to standardise network programming and create interoperability between applications. CORBA is a client/server specification [Beq01 p.11] that makes use of other standards like Interface Description Language (IDL) and Internet Inter-ORB Protocol (IIOP) that defines how two Object Request Broker (ORB) components communicate. These layers provide the functionality that makes two software objects of different languages interoperable over the standard Internet protocols (TCP/IP). 10

11 A layered view of CORBA Although CORBA is widely used and is still being developed further, it is mainly accepted on UNIX platforms and has received [Beq01,p.11] criticism for its complexity and heavy infrastructure Distributed Component Object Model (DCOM) Component Object Model (COM) was introduced in 1993 by Microsoft as their solution for making software components reusable by other languages. Distributed COM became reality in 1997 as [DCOMp] a networked version of the same subject. The development of DCOM resulted in COM+, a near relative of CORBA with improvements in performance, but with the same amount of complexity. In-process calls, when all components are in the same process, are handled by the Local Procedure Call (LPC) protocol to make things quicker, as opposed to the DCOM network protocol that closely resembles how CORBA manages communication between different machines. A layered view of COM+ 11

12 Being a binary standard [Beq01,p.13] makes DCOM language independent, but in practice it is only used with C++ and Visual Basic on the Windows platform XML RPC When Hypertext Markup Language (HTML) had made web surfing so popular, people at W3C (i.e. people at software companies) started designing a more advanced language that would better meet the needs of e-business. After W3C s Recommendation for XML specification 1.0 was released in 1998, it was almost immediately put to use by Dave Winer, an active participant at W3C, to construct a protocol that launched a landslide of implementations made of it, and inspired some to come up with XML-based protocols of their own. XML-RPC is a [XRPCp] Remote Procedure Call protocol that uses HTTP as the transport and XML as the encoding. Its simplicity and support for HTTP was warmly welcomed by programmers frustrated with CORBA and the vast number of open source implementations really invited people to try out creating little programmatic services on non-commercial basis. XML-RPC tools are available for virtually any programming language. A layered view of XML-RPC Simple Object Access Protocol (SOAP) The Microsoft, Inc. did not want to get cornered with their unappreciated policy of conforming the software world and being a member of W3C, it began to co-sponsor further development of XML-RPC. In 1999 the Simple Object Access Protocol specification 1.0 was released. As a joint effort of IBM, Microsoft, Lotus, DevelopMentor and UserLand it was modified and submitted to W3C and currently the version 1.2 is being finalized. The key concepts are similar to XML-RPC, but 12

13 because of the companies commercial intentions, it had to get a more convincing appearance. There was also still a little more interoperability to be squeezed in and thus SOAP became [Beq01,p.16] XML-RPC with extended features in metadata presentation and a more complex packet structure. HTTP remained the preferred transport, but not the only one by definition. The implementing task grew slightly bigger than with XML-RPC, but still SOAP received acceptance among the open source community and the 1.1 protocol version is now implemented in most programming languages. A layered view of SOAP 2.2 XML the Basic Layer Overview XML, like HTML, is a subset of Standard Generalized Markup Language (SGML), which was made an ISO standard in It provides strict rules, by which one can create a vocabulary to describe the data being transmitted. Extensible Markup Language acts as an interpreter between different programming languages that follow XML-based communication protocols. HTML made data presentation interoperable cross languages and XML does the same thing to data processing. The foundation is the UniCode [UniSt] standard presentation of characters that every serious programming language supports. Converting complex data collections, like large Objects in Java, to text format is not a problem, since they always in the end consist of simple data types, which have text presentations in every language. 13

14 2.2.2 XML Schemas and Namespaces There is a number of technologies [XML10] that belong to the XML family. XML is a modular language meaning that vocabularies created with XML can be merged together to produce new ones. Therefore it is advisable to set up rules for creating a vocabulary to preserve its integrity when merged with another one. XML Shemas [XSche,ch.1.1] are files that declare those rules and thus define classes of XML files. And to avoid name confusion among the tags and attributes of originally different XML files, there is the convention of XML Namespaces. These are important building blocks for any XML based software interaction. <xs:schema xmlns:xs=" xmlns:dc=" xmlns=" targetnamespace=" elementformdefault="qualified" attributeformdefault="qualified"> <xs:annotation> <xs:documentation xml:lang="en"> XML Schema by Pete Johnston Based on Andy Powell, Guidelines for Implementing Dublin Core in XML, 9th draft. This XML Schema is for information only</xs:documentation> </xs:annotation> <xs:import namespace=" schemalocation=" /> <xs:complextype name="audiencetype"> <xs:simplecontent> <xs:extension base="dc:elementtype" /> </xs:simplecontent> </xs:complextype> <xs:element name="audience" type="audiencetype" /> <xs:group name="elementsgroup"> <xs:choice> <xs:element ref="dc:title" /> <xs:element ref="dc:creator" /> <xs:element ref="dc:subject" /> <xs:element ref="dc:description" /> <xs:element ref="dc:publisher" /> <xs:element ref="dc:contributor" /> <xs:element ref="dc:date" /> <xs:element ref="dc:type" /> <xs:element ref="dc:format" /> <xs:element ref="dc:identifier" /> <xs:element ref="dc:source" /> <xs:element ref="dc:language" /> <xs:element ref="dc:relation" /> <xs:element ref="dc:coverage" /> <xs:element ref="dc:rights" /> <xs:element ref="audience" /> </xs:choice> </xs:group> </xs:schema> An XML Schema file The above XML Schema file is an XML file itself consisting of tags and attributes like HTML files. The first bold line is a namespace declaration that assigns a specific Uniform Resource Identifier (URI) to the prefix dc. The next bold line binds the 14

15 previously declared prefix dc with another Schema file that has the target namespace which is assigned to dc. The third bold line is an example of utilizing information from another XML Schema file by using the defined dc prefix. That was a typical example of merging two classes of XML vocabularies. A thing to notice is that none of the String values used in XML Namespace declarations resulted in HTTP traffic. A namespace prefix is usually assigned to a URI, because it is [rfc2396,ch.1.1] a unique sequence of characters in the global namespace by definition and that way one can be sure that namespaces will never collide. In this context URIs are meant to be taken as String values and not as document addresses. Namespaces can be any Strings and when it is absolutely certain that we are dealing with a closed set of XML files, other Strings than URIs can be used. The only -prefixed String that acted as a document address over the Internet, was the value of schemalocation attribute after the second bold line, which told where to look for the other XML Schema file. On the other hand nothing prohibits [XSche,ch.4.3.2] the usage of document addresses as namespaces, since they are well suited to do that. The XML Schema files that W3C has published can usually be found at their targetnamespace URI addresses. 2.3 XML-RPC As stated before, XML-RPC is the precursor of SOAP, a slimline version that is capable of virtually everything that SOAP can do. The specification [Xspec] is rather informal and too easy to understand to be taken seriously by people who think that complex solutions resolve complex problems. In fact, the problem is not that difficult. The protocol specification gives a few simple guidelines on how common data types are described and how programmer-defined data collections should be presented. In addition, it sets a couple of header attributes that the HTTP header field must include and gives the format of the return message. XML-RPC is used to transmit a set of parameters over the Internet to another program, which in turn gives back the processed set of values. It does not deal with Objects, but in most cases it gets the job done. 15

16 2.3.1 Serialization Converting a data presentation from some programming language to XML form is called serialization or marshalling. Every data collection is broken down to individual values, which are written as plain text surrounded by the appropriate elements of the correct XML vocabulary. The reverse operation is called deserialization or unmarshalling, which involves creating a matching data collection in some programming language using the metadata provided by the given XML vocabulary. Tag Type Example <i4> or <int> Four-byte signed integer -12 <boolean> 0 (false) or 1 (true) 1 <string> ASCII string Hello world <double> double-precision signed floating point number <datetime.iso8601> Date/time T14:08:55 <base64> Base64-encoded binary ew91ignhbid0ihjlywqgdghpcye= Scalar values defined in the XML-RPC specification In XML-RPC also complex data types can be serialized as <struct/> elements and arrays as <array/> elements. The vocabulary has a few other rules [Xspec], but if one is not out to implement the protocol, the specification does not need to be memorised. Here is an example of an XML-RPC call made to utilize an imaginary weather forecast service. This type of information is not visible to a person using an implementation of the protocol. A class library providing the functionality for executing XML-RPC calls hides the details behind interfaces. POST / HTTP/1.1 Content-Length: 172 Content-Type: text/xml User-Agent: Java1.3.1_03 Host: weatherworld.com:8080 <?xml version="1.0"?> <methodcall> <methodname>service.getweatherreport</methodname> <params> <param> <value><string>helsinki</string></value> </param> </params> </methodcall> 16

17 2.3.2 Implementations Usually it takes a lot of work to create a program that effectively delivers the means of software communication and hides the manoeuvres required by a specification. Software development has always based on reusing existing components and as programs got more complicated, the tools developed alongside. Nowadays only a small portion of executing code is written specifically for that program. The Internet has generated active world-wide communities of software developers, who create programming tools and give them out for free. Some of these massive joint efforts focus on implementing specifications of new technologies and they usually result in quality software products that are in everyone s reach. Given the simplicity of XML- RPC, it is no surprise that the implementation count [Ximpl] of the specification is nearly seventy covering every thinkable programming language. Most of the implementations are individual projects of dedicated programming enthusiasts. XML- RPC has received very little status as a communication protocol in commercial products, but its successor SOAP has a better chance Limitations XML-RPC does not support the use of XML Schemas or XML Namespaces because it was created before them and because Object handling is not an included feature. The protocol defines one strict vocabulary to be used, so there is really no need for the assisting XML technologies. Lacking flexibility in the encoding of data as well as in the data transport, XML-RPC is not considered as a protocol for production use. These shortcomings are overcome in SOAP, which is in many ways an updated version of XML-RPC, not the least because the creator of XML-RPC, Dave Winer played a major role in developing the Simple Object Access Protocol. 17

18 2.4 SOAP v1.2 SOAP Version 1.2 (SOAP) is a lightweight protocol intended for exchanging structured information in a decentralized, distributed environment. It uses XML technologies to define an extensible messaging framework providing a message construct that can be exchanged over a variety of underlying protocols. The framework has been designed to be independent of any particular programming model and other implementation specific semantics. [SOA12] Definition of SOAP stated in the W3C Working Draft Part Overview The Simple Object Access Protocol is still in a state of flux, although the 1.1 version of the protocol has been submitted to W3C and many implementations have been made of it. One of the chief SOAP 1.1 architects, Dave Winer writes in his column [WinSO] on March the 2 nd in 2001: The SOAP spec is broad enough that a developer can implement an application that conforms yet still does not interoperate with other implementations. The World Wide Web Consortium said in their [SOSuC] comment on the SOAP 1.1 submission that:..its object serialization scheme needs to be more explicit and that: security considerations should have a central place in such a design So, the version 1.2 of the protocol [SOA12] was published as the Last Call Working Draft on June the 26 th in 2002 and the changes are numerous. However, the practice of leaving key issues of network-based computing to be specified as extensions by other protocols is still there. Security and reliability, for example, are completely left to the implementors hands. That does not mean that SOAP lacks these features, but that they are implementation specific. In addition to other changes, they have stopped spelling out the acronym and the Simple Object Access Protocol, that really was not Object oriented in the first place, is called just plain SOAP from now on Serialization SOAP does not define an XML vocabulary to be used in the encoding of data in a SOAP message. Serialization rules are declared with XML Schemas that are assigned 18

19 to the necessary parts of a message with encodingstyle attributes [SOA12,ch.5.1.1]. In a quest for more interoperability SOAP allows the XML encoding to be defined as needed, but this can result in metadata exchange that largely exceeds the amount of actual information transmitted. POST /forecast HTTP/1.1 Host: weatherworld.com:8080 Content-Type: text/xml; charset=utf-8 User-Agent: GLUE/2.3.1 Connection: Keep-Alive SOAPAction: "getweatherreport" Content-Length: 508 <?xml version='1.0' encoding='utf-8'?> <soap:envelope xmlns:xsi=' xmlns:xsd=' xmlns:soap=' xmlns:soapenc=' soap:encodingstyle=' <soap:body> <n:getweatherreport xmlns:n=' <arg0 xsi:type='xsd:string'>helsinki</arg0> </n:getweatherreport> </soap:body> </soap:envelope> An example of a SOAP 1.1 message The above SOAP message is the same imaginary service call that was made in chapter with XML-RPC. We can see, that all the namespace declarations have tripled the size of the message which otherwise carries no more data than the XML-RPC version. While this is an extreme example, it clearly indicates how increased interoperability also increases the amount of needed metadata. Not to mention the increase in Internet traffic, if a Schema file has to be retrieved. This is, however, rarely the case, because XML vocabularies have to be at hand in the programming phase and the XML Schema files [SOSch] that W3C has constructed for the most common data types are usually a kind of default vocabularies that are used Packet Structure and Protocol Extensions SOAP encourages application developers to [SOA12,ch.3] extend the protocol whenever it does not specify the kind of behaviour a particular information exchange 19

20 routine requires. Therefore SOAP messages consist of three elements: an <Envelope>, that encapsulates the message, an optional <Header> element that can be used for application specific communication design and a <Body> element that carries the primary data. Examples of extending the protocol could be: added routing information between SOAP nodes in a network, forcing SOAP messages of an application to conform with a unified policy of information handling, or whatever is necessary. The basic idea is no different than handling the serialized data of the <Body> element. Extensions a.k.a. Header Blocks are XML elements that, according to some XML Schema file, produce information which is to be processed in a preprogrammed way. The structure of a SOAP message <env:envelope xmlns:env=" <env:header> <n:alertcontrol xmlns:n=" <n:priority>1</n:priority> <n:expires> t14:00:00-05:00</n:expires> </n:alertcontrol> </env:header> <env:body> <m:alert xmlns:m=" <m:msg>pick up Mary at school at 2pm</m:msg> </m:alert> </env:body> </env:envelope> A SOAP message with a Header Block Above SOAP message [SOA12, example 1] has some self explanatory features added as a Header Block. An application might reject the lower priority messages without further processing, which could be perceived as an extension of the protocol. 20

21 2.4.4 Implementations Like XML-RPC, SOAP 1.1 was pretty soon after its publication implemented in the most popular programming languages. Microsoft, IBM, Sun Microsystems and many other companies have released products for creating software services i.e. SOAP interfaces on the Internet. When the 1.2 specification finally comes out as a W3C Recommendation, hopefully during 2002, it is expected to start a new round of implementation releases. Because of the commercial potential of SOAP, it has attracted some serious software companies. Although there are many SOAP tools available [SOimp] free of charge, the differences in quality can be radical. Luckily, some of the commercially oriented products are released for free with some features stripped off. In most cases commercial products provide a whole set of implementations, which together adopt the complete specification of Web Services [WebSe] that W3C has constructed Limitations In addition to swelling up the messages with metadata, SOAP 1.2 has other downsides that derive from the over anxious search for interoperability. It seems like everything that would have forced the protocol in one distinct direction, has simply been left out. When application developers can add extensions (and have to add, if they want to achieve, for example, secure message transaction) to the protocol, the SOAP interfaces on the Internet can have the same implemented functionality specified in different ways and that is just the opposite of interoperability. But, as seen in the example message in chapter 2.4.3, the protocol extensions are better described as application features and different applications are not of course interoperable. Still, the situation is that [SOA12,ch.1] key elements of reliable message transaction are not included in SOAP. Thus the implementations i.e. the programming tools do not have a uniform way, if any, to address these problems. And so network-based software development for production use is not much easier with SOAP than with other techniques. 21

22 Another thing is, that can you calmly rely on two different implementations to be completely interoperable? Sam Ruby, a co-developer in Apache SOAP and Apache Axis implementations, points out in his article [Rub02] on February the 1 st in 2002 that: there is still much that needs to be done to make interoperability downright automatic. As he demonstrates with examples, a cold fact is that if different programming languages have different precision with the same data type, there is no way to prevent data loss. What if the given XML Schema file does not define precisions accurately? While in some cases it may sound like nitpicking, still after evolving from the three page specification of XML-RPC to the ninety page specification of SOAP 1.2, one can find points where interoperability fails. Sam Ruby calls out for [Rub02] a classification of errors that identify potential interoperability issues. 2.5 Jabber Embedding XML Protocols Jabber is a fine example of an ongoing world-wide software development project that invites anyone to participate. It was founded by Jeremie Miller in 1998, when he got tired of keeping several different instant messaging (IM) clients open to be in touch with all of his friends. Instant messaging is a concept that has evolved from chatting over the Internet to cover all possible ways of network-based message exchange. Commercial IM products usually have their own unstandardized data presentations and for understandable marketing reasons companies do not want people to communicate with other than their applications. Jeremie Miller happened to have friends that had acquired individually different IM clients and he started developing XML-based gateways, with which he could have communicated with everyone using just one application. Soon he realized, he had material for something bigger and so a language and platform independent IM protocol was conceived. Jabber is constantly developed as a community project in a massive way. You can post your protocol enhancements to a particular mailing list or join various implementing efforts of different kinds of Jabber related software tools. 22

23 2.5.1 Jabber Architecture Jabber is a protocol for chatting applications. It is also a transport protocol on top of the standard Transmission Control Protocol / Internet Protocol (TCP/IP) layer like HTTP. The original goal of language independent chatting reflects itself in the network architecture of Jabber as well as in the procedure of first getting online i.e. authenticating before the actual data exchange. Clients and servers are strictly separated with the intention of making clients as light and simple as possible while servers take the responsibility of routing and storing the messages and otherwise administrating the Jabber universe. This does not [JABFQ,ch.3.4] necessarily mean a centralized network environment, because the servers work together in delivering the messages and, if one so pleases, the clients can have dedicated servers running on their machines. The aim with this protocol driven load balancing is to enable a larger collection of computing devices to communicate. Anyone is free to set up a new Jabber server and have the application s data exchange done through that, if privacy is desired. A Jabber network of servers and clients 23

24 2.5.2 XML Streaming Because Jabber was originally designed for real time arbitrary text exchange between people, it has a narrow basic XML vocabulary for data transfer. Text is expected to be the primary data, so the protocol does not say anything about serialization or data types. However, instant messaging applications nowadays have a rich set of features and XML Schemas are used in the protocol specification to add more functionality to the fundamental XML vocabulary being used. Thus XML Namespaces are frequently utilized to [JAB00,ch.4.2] describe and qualify the data in a Jabber message. The namespace policy is slightly different from the way it is been handled in SOAP. Jabber: -prefixed namespaces are reserved String values for the protocol and URIs are rarely used. Another big difference comes from the nature of instant messaging. When the communicating parties have authenticated themselves and received online status, they have each created an abstract XML document of their existence in the Jabber universe. The client entities then send chunks of XML data to each other and when they go offline i.e. leave the Jabber universe, those abstract XML files receive their closing tags. If one was to look at such an arbitrary file, one would notice that it is a well formed XML document containing perhaps several data transmissions to other client entities. Jabber conversations can therefore be described as [DJA02,p.129] streams of XML data which build up to large abstract XML documents each covering the whole online period of one client entity. Other XML-based communication protocols including XML-RPC and SOAP involve exchanging complete and well formed XML documents, one per each message, without the concepts of online and offline. <stream:stream xmlns:stream=" xmlns="jabber:client" to="jabber.org"> <iq id="0" type="set"> <query xmlns="jabber:iq:auth"> <username>someuser</username> <password>somepassword</password> <resource>jrpc-client</resource> </query> </iq> An authentication query to a Jabber server 24

25 2.5.3 Jabber Conventions To enter the Jabber universe, one must establish an account on a Jabber server. This means simply reserving a unique Jabber Identifier (JID), which consists of a user name, server name and an optional resource indicator: [email protected]/laptop. Then, by authenticating with that user name, an entity can become an endpoint in a closed Jabber network or join the world-wide Jabber universe, depending on the server configuration. Every node in a Jabber network, whether it be a server, a software service or an IM client is addressed with a JID. After going online in a network, a Jabber entity can notify its presence to selected entities and also receive their notifications. Jabber Session Manager (JSM) is a server component that provides presence subscription and notification services as well as message storage when an entity is offline. Jabber servers handle the dirty work of administrating the network, which has been a conscious decision in the protocol design. A Software developer can choose, which features the client program needs to support for sufficient communicating skills and thus Jabber endpoints can easily reside on machines with limited computing capabilities. Although the protocol does not prohibit direct interaction between endpoints, the servers usually route messages so that all JIDs in a network can communicate Embedding Structured Data As stated before, serialization is transforming data collections from a programming language presentation to XML form. And all XML documents are UniCodecompliant text files. If Jabber is designed for delivering text messages, it surely must be able to transport serialized, language-agnostic data between network endpoints. After all, every Jabber transaction is encoded in XML. So, anything that can be expressed in XML is fit to be embedded in a Jabber message. This could be considered as an extremely efficient way of extending the Jabber protocol. Having SOAP and XML-RPC in the toolkit gives JID endpoints possibilities to represent virtually any thinkable object or service. In the case of XML-RPC, it is a minor 25

26 violation of the embedded protocol, which allows only HTTP to be the transport and so it is been given a special name, Jabber-RPC. <iq to="[email protected]/jrpc-server" id="123ae495" type="set"> <query xmlns="jabber:iq:rpc"> <methodcall> <methodname>service.getweatherreport</methodname> <params> <param> <value><string>helsinki</string></value> </param> </params> </methodcall> </query> </iq> A Jabber-RPC service call Above Jabber message is the weather service call, familiar from chapters and 2.4.2, made as an embedded XML-RPC call. The service provider has an account on jabber.org and is currently online like the Jabber client making the call Implementations Chatting is a popular way of using the Internet and instant messaging client applications can be found on almost every personal computer with an Internet access. Jabber has attracted numerous implementors due to the simplicity of the client side and because there are several public Jabber servers providing free accounts. The tendency is, that developers create IM client programs with full features but only for person-to-person message exchange. There are also some free server implementations, but the serious server programs (over online users) are commercial products. The programming tools for creating Jabber IM clients or other JID endpoints in different languages are freely available. The Jabber community hosts web sites, where all important resource pointers have been collected. Every now and then some of the several open source developing projects releases a new version of a Jabber programming tool, that can be obtained and put to use by anyone who is interested. 26

27 2.5.6 Limitations As with any developing project, the people involved tend to be more enthusiastic than realistic about the work they are doing. If XML is data's new ASCII, then Jabber is the network's new TCP/IP", said DJ Adams, a Jabber developer in the [OSCON] O Reilly Open Source Convention on 26 th of July Being a transport protocol Jabber cannot communicate with HTTP servers, although there are gateways for interpreting Jabber-RPC to HTTP/XML-RPC. Jabber is a closed network by nature and thus unsuitable for publishing software services for other than Jabber entities. Jabber developers have suggested that it is time to move forward from HTTP, but are people willing to do that? Another thing is that embedding protocols always means embedding their shortcomings as well. Jabber entities communicating with embedded SOAP messages are just as interoperable as their SOAP implementations are. 27

28 3 Implementations at Work 3.1 Automated Event Monitoring The Dialog Project at TAI Research Institute of Helsinki University of Technology studies new ways of identifying products and new methods of managing product information through the use of networked computing devices. The research team explores possibilities to reduce production costs and improve product quality with better product information management. The latest technologies enable wireless database updates across the Internet and thus make it possible to maintain real-time status information about physical objects. Of course this has been done before, but now that cellular phones come with Internet access installed and products can be tagged with Radio Frequency Identifiers (RFID), the scope of automated event monitoring can be stretched to cover every branch of industry. If there are scheduled events during the life cycle of a product, those events can be programmed as checkpoints for the software component to run appropriate routines and take measures if the schedule fails. Unscheduled events may simply be reported and reacted to as needed. When products are identified, software components may use their pre-programmed knowledge and act in a variety of different roles. One could even perceive that the product itself triggers the programmatic actions concerning each particular identification event and thus it is the product that makes the database updates and sends other notifications. So, in the planning of a manufacturing process, a logistic case or other type of production, it is appropriate to let the product do the information management with the help of its representative software components. The question then is: What do we want the product to tell us?. After the plans are complete, the product has a series of checkpoint events along its life cycle. Those checkpoints are translated into suitable software components that gather the needed information and send it to the correct address. When a checkpoint occurrence takes place, the product s identification tag is read and the ID info is transmitted to a computing device that hosts the software translation of that particular event. The software component then carries out the procedures as planned and reports 28

29 any anomalies. A familiar example of automated event monitoring is the modern cash register reading product bar codes, adding the prices up and updating the store s database. 3.2 Product Identification Network-based applications, such as or instant messaging applications, have established human identification to be in a specific format: username@hostname. The user name is a unique identifier in the local namespace of the or IM account provider, which in turn is identified by the host name. serves as a delimiter between these two pieces of information. A host name, being a part of a domain name, is [rfc1034,ch.3] unique in the domain namespace structure making the virtual counterparts of humans (i.e. their or IM addresses) uniquely identifiable in the global sense. The Dialog Project has introduced the same convention to product identification: companies can decide suitable, locally unique, coding for their products and append the codes with their Internet addresses. This way every product is globally uniquely identifiable. The identification tag of a product holds therefore a character string in a format: productid@hostname. The possibilities that electronic product identification and networked computing devices give to industries have been studied for some time, and different research teams have come up with different suggestions for a standard identification scheme. The Auto-ID Center in the Massachusetts Institute of Technology (MIT) is strongly campaigning for their own Auto-ID Technology, which includes new standards like Electronic Product Code (EPC) and Object Name Service (ONS). The idea is that [MITa02,p.24] every company would receive its own identification code from an EPC namespace authority, which would be the Auto-ID Center. An Object Name Service Framework would be built on top of the existing Domain Name System (DNS) and every product identification would involve an ONS lookup to resolve the product s Internet address. The technology would allow [MITb02,p.5] a constant amount of identification numbers for each company to use on their products. The Auto-ID Center has decided to do the same thing as the Dialog Project, mapping the product codes to Internet addresses, but with an additional protocol layer that needs an 29

30 infrastructure of its own and causes [MITa02,ch.4.7] additional performance overhead. address type of product identification, on the other hand, uses the existing infrastructures and protocols, causes no performance overhead and lets the companies use their current product coding with possibly unlimited number of identification codes. 3.3 Technical Devices The most popular ways of identifying products are bar codes and Radio Frequency Identifiers (RFID). Bar codes have been around for decades, but only the resent break throughs in the development of hand held computers have extended bar codes usability to a new level. The combination of a bar code reader and a wireless pocket size computer with an Internet access makes it possible to identify virtually any product in any environment. RFID-tags are a step forward from bar codes. Although they are more expensive, they have significant advantages over bar codes like reprogrammability, more data storage and non-visual readability. In the near future [Nok01] cellular phones are equipped with RFID readers and consumers receive product information on their phones and cause other events like order placement and payment. 3.4 The Dialog Web Application The Dialog Project does research work by resolving product information management problems arising in the everyday life of evolving industries. This means implementing the solutions as software components and testing them in the industrial environment. The companies involved in the project have been interested in some specific features, which all are similar in their programmatic nature: every identification event starts a database operation across the Internet. 30

31 3.4.1 Features The Dialog Web Application currently supports three kinds of cross network database operations: updating product location, retrieving product information and storing references to other products. The third feature is for situations where a product contains other identifiable products. The application is divided into two parts: the client receives identifications from an ID-tag reader device and sends the desired service requests, the server performs database operations and sends information back to the client. The client software lies on the node of a network that is in contact with the product and the server software lies on the product holder s computer. The application is programmed in Java and the components communicate using Java s RMI technology Motivation For Language Independence One goal of the Dialog Project is to encourage companies to deepen their collaboration on product information management, especially on logistic issues. Industrial products are often transported by various transport companies from manufacturer to customer. Sub-contractors deliver main contractors industrial items which are assembled into final products. For example, when a product does not arrive at a construction site, crucial parts of the construction work may be delayed. The result can be overtime work or even exceeding the deadline for completion. If the transport companies have checkpoint events associated with every cargo loading and unloading, both the manufacturer and the customer can have real time notifications if a shipment is delayed, or completely stopped. This involves that the software platforms of various actors along the product s logistic chain are interoperable. A convenient way to establish this is to have a language and platform independent communication protocol as an option. The companies may well use their existing software platforms and database implementations, and design a light XML-based interface on top, if a Java solution is not approved. Another issue is the use of hand held computers and mobile phones as hosts to the client side component. Although they usually have some sort of Java environment installed, RMI technology is rarely an included feature. This situation is likely to be 31

32 improved in the near future, but in the mean time XML-based protocols offer a coherent way for the software components to communicate. Some companies may even consider SOAP as their primary communication method if they have updated their operating systems with Microsoft s SOAP oriented.net platform. 3.5 SOAP in Dialog Apache SOAP 2.3 The Apache open-source community is probably the world s largest coalition of different non-profit software developing projects. Since 1995 it has released several freely downloadable products, that are widely used and appreciated. Also SOAP implementations appeared on the menu a year after the first specification draft was published in Apache SOAP 2.3 conforms to the SOAP 1.1 specification TME Glue 2.3 The Mind Electric (TME) is a thriving new software company that has successfully combined open-source thinking and commercial aspirations. The company has a policy of giving a little lighter versions of their products for free, while the full version licenses with large companies make the income. Still, the product quality exceeds by far the level that strictly non-commercial developing projects are capable of. TME Glue 2.3 conforms to the SOAP 1.1 specification Comparison The quality of a protocol implementation can be measured by first analyzing its requirements and limitations. What kind of software environment it must have, and if there are protocol features left out of the implementation. This gives right away some idea whether the software tool is worth further consideration. After the initial elimination of unsuitable candidates one can look at the level of complexity associated with each remaining implementation. This part may involve looking through some example programs and otherwise getting to know, how much work it 32

33 takes to achieve the same results with different implementations. And finally, if there are still choices left, one can pick the tool that feels the most fun to work with. All these steps can be greatly simplified by finding out what has been said about different software tools by other programmers. The Internet is full of mailing lists that host e- mail discussions of professional programmers experiences with different implementations. And if performance issues are given a high priority, one must rely on other people s opinions anyway, if one is not going to do the same work twice with different tools to make the comparison. Implementation features Apache SOAP 2.3 TME Glue 2.3 Requirements Limitations Additional features J2EE SDK 1.2 or higher Servlet Engine XML parser JavaMail JavaBeansActivationFramework EncodingStyle attribute must have only one encoding style given (see section of the spec) mustunderstand attribute support - only supports checking for and rejecting requests that require mustunderstand checking root attribute actor attribute and SOAP intermediaries does not use multi-ref accessors during serialization J2SDK or higher JavaServer Pages (JSP) Engine WSDL support UDDI support Thread pooling Key differences between TME Glue 2.3 and Apache SOAP

34 The previous table of key differences between the two implementations gives an indication of the configuration requirements and the tools interoperability with other implementations. Although it seems that Apache s product does not do very well in comparison, it has until recently been the most popular SOAP implementation. This is merely because the Apache community s web site is one of the most popular places to look for free software tools, and the knowledge of better options does not necessarily reach people who do not look for it Glue 2.3 Protocol Architecture The Mind Electric, like many others, has designed an application that supports a family of protocols. While the concept of programmatic Internet interfaces i.e. Web Services is still somewhat unclear [WebSe,ch.1.1], many companies have created software tools that conform to protocols that are suggested to be followed, but not yet finally accepted. There are still open issues concerning describing and locating the service endpoints. Web Service Description Language (WSDL) is an XML grammar for describing network endpoints. TME Glue 2.3 offers tools that convert Java classes to WSDL files and vice versa. The idea is that every SOAP interface is defined by an accessible WSDL file, according to which the proper Java interface and a helper class can be automatically created in the programming phase of the client side. This ensures that every service call is targeted at the proper remote method with correct parameters. Glue 2.3 even provides a console program, with which one can monitor available SOAP interfaces on the Internet through a web browser and create suitable Java client classes for utilizing those services. Another thing is to locate the available Web services and their WSDL files. One solution for this is the Universal Description, Discovery and Integration (UDDI) protocol. UDDI servers collect information about companies and their Internet services. This information is constantly available and can be accessed from a web browser or from a UDDI SOAP client. Glue 2.3 comes with an UDDI client that can perform service publication and service info inquiry operations on any UDDI server. 34

35 Anyone can also set up a UDDI server, which means implementing the Application Programmer s Interfaces (API) published by the UDDI project, which is again a cross-industry effort driven by all major platform and software providers [UDorg]. TME Glue 2.3 comes with a UDDI server, of course, but how locate all the others? There is no other way than using conventional search engines like Google to find sites listing UDDI registry addresses. Using the protocol family to utilize a web service The picture above illustrates what steps the procedure of writing a client program for a Web service involves. If a person wants to make weather forecast service calls (ch ) with his mobile phone, the first step is to browse UDDI registries and choose a suitable service. The second step covers downloading the service s description (WSDL) file, or otherwise finding out about the endpoints interface. A company may even provide complete client programs for downloading. The third phase is to write the client program that is to be hosted by the mobile phone. After testing that it works, the SOAP client is downloaded on the phone and then the service can be utilized. Of course the mobile phone must be sophisticated enough to perform SOAP service calls over the Internet. 35

36 3.5.5 SOAP Server Interfaces for Dialog TME Glue 2.3 aims to be as simple as possible in providing means of communication for software components. The software s API offers so powerful helper classes that realizing software communications across the Internet doesn t require high level programming skills. The server side procedure involves exposing the service s WSDL file to the rest of the Internet and publishing the desired Java Objects (classes) as web services. The Java Objects (i.e. the service interfaces) that bind the Glue 2.3 software to the Dialog Web Application are very much alike and, as an example, we follow through the case of Product Information Service. package fi.hut.soap.server; import fi.hut.dialog.server.dserver; import fi.hut.dialog.productinformation; import fi.hut.soap.piserviceinterface; /** * The Service class for retrieving product information */ public class ProductInformationSOAPService implements PIServiceInterface{ public ProductInformation getproductinformation(string tagid) { ProductInformation result = null; try { DServer ds = new DServer(); result = ds.getinformation(tagid); catch (Exception e) { System.out.println(e); return result; Code for forwarding product information requests on the Dialog server component The class implements PIServiceInterface class that only reports the signature of the remote method getproductinformation, which takes a String parameter (the product identification) and returns a ProductInformation Object. To make the service available, a command file is written. This is an XML startup file, which tells Glue 2.3 software what to do when the program starts. <commands> <invoke> electric.registry.registry.publishinstance( "PI", "fi.hut.soap.server.productinformationsoapservice" ) </invoke> </commands> A Glue 2.3 command file commands.xml 36

37 The service can now be published by a command prompt if we use the built in server of Glue 2.3, or by an external servlet engine hosted by an external server. The Dialog Web Application s developing environment is hosted by an Apache Tomcat Server and it is the Tomcat servlet engine that routes the service calls to Glue 2.3. To manage this, a <Context/> element is added to Tomcat s server.xml file with the proper information. : : <Host> : : <Context path="/contextaddress" docbase="c:/filesystemaddress" reloadable="true" > </Context> </Host> : : Added <Context/> element to server.xml Tomcat will forward all calls that are addressed to hostname/contextaddress/... to the hands of the application residing in C:\fileSystemAddress, which is the Dialog Web Application s server component. The three dots at the end are address extensions, which are defined for Tomcat and mapped to appropriate servlet classes in C:\fileSystemAddress\WEB-INF\web.xml file. <?xml version="1.0" encoding="iso "?> <!DOCTYPE web-app PUBLIC "-//Sun Microsystems, Inc.//DTD Web Application 2.2//EN" " <web-app> <servlet> <servlet-name> http </servlet-name> <servlet-class> electric.server.http.servletserver </servlet-class> <init-param> <param-name> electric.commands </param-name> <param-value> commands.xml </param-value> </init-param> <load-on-startup> 1 </load-on-startup> </servlet> <servlet-mapping> <servlet-name> http </servlet-name> <url-pattern> /services/* </url-pattern> </servlet-mapping> </web-app> The web.xml file for Tomcat servlet engine 37

38 According to the previous servlet mappings, all URIs that begin with are routed to the Glue 2.3 servlet named simply http, which begins the server side processing. The GLUE-STD.jar file that provides all SOAP functionality, is copied into C:\fileSystemAddress\WEB-INF\lib directory for Tomcat to contact. The command file a few pages back bound the service interface, being the ProductInformationSOAPService class, and a String value PI together, which means that the product information SOAP requests need a /PI extension to the base URI. However, with Glue 2.3 all service calls are always made to a WSDL file, while other implementations may just use the service s URI. The service description is supposed to be published anyway and therefore we use one of Glue s utility programs to convert the service interface Java class into a WSDL file called ProductInformationSOAPService.wsdl (see APPENDIX A). The program lets description files be mapped to more suitable file names like PI.wsdl in this case SOAP Client Side for Dialog The client side programming is a remarkably simple process. When the service interface is, either programmatically converted by Glue s wsdl-to-java utility, or simply hand written into a Java interface class, there is nothing more to it. We use the same PIServiceInterface class that was implemented by the server side. package fi.hut.soap; import fi.hut.dialog.productinformation; /** * The Service interface for Product Information Service */ public interface PIServiceInterface { public ProductInformation getproductinformation(string tagid); A Java description of the Product Information Service With this interface description a helper class for the Dialog Web Application s client component can easily be written. The class is to be used by another client side class that gathers all SOAP communications together. 38

39 package fi.hut.soap.client; import electric.registry.registry; import electric.registry.registryexception; import fi.hut.soap.piserviceinterface; public class ProductInformationGLUEClient { /** * The method binds to the specified host and executes the remote * method stated in the PIServiceInterface.class */ public Object invokeservice(string host, Object obj) throws Exception { PIServiceInterface pi = (PIServiceInterface)Registry.bind(host, PIServiceInterface.class); Object result = pi.getproductinformation((string)obj); return result; The class executing a SOAP service call over the Internet The client side, of course, also needs a copy of the GLUE-STD.jar file to be able to send and receive SOAP messages. After that Glue 2.3 takes care of serialization and parsing of XML files along with other details of software communication. The server side service may be used as if an in-process method call was made to it. To see an example of a client/server SOAP conversation, refer to APPENDIX B. 3.6 Jabber RPC in Dialog Resources for Jabber programming are very few in number compared to those of SOAP, but still you get to choose your programming language from a handful of options and between Linux, Windows or Solaris server implementation. Since we are doing XML-RPC inside the Jabber protocol on Windows2K, the developing environment consists of three software tools: an XML-RPC Java class library, a Jabber Java class library and a Windows Jabber server. The comparison of quality is now a bit more difficult, because there are no commercial development tools for Jabber and the class libraries are very similar in nature. The documentation of a Java class library, however, always gives an indication of the level of complexity and thus 39

40 the amount of work associated with using the documented software tool. This kind of approach led to select the Apache XML Project s XML-RPC implementation and the JabberBeans class library as well as the JabberD server for Windows from Jabber Software Foundation [JABSO]. J2SDK 1.3 or higher is the required Java platform Jabber Setup Jabber architecture is a server-centric setup, in which the network endpoints have equal communicating skills (ch ). For the Dialog Web Application this means that both software components are clients in the Jabber network. And before any data exchange is possible, the clients must be identified i.e. have accounts on Jabber servers in the same network. Establishing a Jabber Identifier (JID) for a software component can be done simply by logging with an instant messaging (IM) application on a Jabber server and reserving a user name and a password for that component. This procedure creates an XML file about the client on the server and the same JID information can later be assigned to a software component. The Jabber server administrator could also create the same file manually, but this is much faster. The other issue with Jabber is the practice of authenticating and getting online before sending messages. This is what the pre-reserved JID info is used for and the obvious thing is to make it a startup procedure as if an IM application logged on a server automatically when launched. These steps aside, the programming is nearly similar to establishing normal XML-RPC communications between a client and a server The Server Component The server component of the Dialog Web Application is likely to be hosted by a company server and we assume that the company wants to host a dedicated Jabber server as well. JabberD is not used for conferencing (group chatting) or other fancy stuff and therefore the configuration of the Jabber server doesn t require more than following the installation instructions. The actual server component of the application is completely oblivious to the fact that the Jabber service provider resides on the same machine. 40

41 The main functionality, i.e. authenticating, monitoring messages and providing XML- RPC services, is gathered in one class called DialogJabberResponder.java (see APPENDIX D). The start method takes care of connecting to the server, authenticating and sending the presence notification. The PacketListener interface is implemented with three methods, one of which selects all InfoQuery instances and uses one of the Apache XML-RPC library s classes, namely XmlRpcServer, to forward service calls to the DServer class that executes the database operations. The same instance of XmlRpcServer called xmlresponder is used at startup by that executive DServer class to map the service calls to the class (itself) that defines the remote methods. DialogJabberResponder djresponder = new DialogJabberResponder(SERVER,SERVICE,PASSWORD,resource); djresponder.xmlresponder.addhandler("lu", this); djresponder.xmlresponder.addhandler("pi", this); try { djresponder.start(); catch (Exception e) { System.out.println("Cannot start server: " + e.tostring()); System.exit(0); Code snippet from DServer class. For Product Information Service the remote method is called getproductinformation, which takes a product identification String parameter. As opposed to SOAP, XML- RPC does not handle user defined Objects and therefore the return value is a Vector Object that carries the corresponding information. public Vector getproductinformation(string tagid) throws Exception { ProductInformation result = null; try { result = getinformation(tagid); catch (Exception e) { System.out.println(e); if (result!= null) { Vector retval = new Vector(3); retval.add(0, result.getidentifier()); retval.add(1, result.getinformation()); retval.add(2, new Boolean(result.getIsCollection())); return retval; return null; Code snippet from DServer class. 41

42 3.6.3 The Client Component The client side is somewhat complicated, because the Apache XML-RPC library is intended for built-in HTTP communication, and therefore we only use the parser class uk.co.wilson.xml.minml to handle the return values and build the XML-RPC messages on our own. Otherwise the Jabber related programming is very similar to the server side, since both components have equal status in the Jabber network. The JabberClient class provides the familiar startup manoeuvres, but in addition to that the class gives Jabber RPC functionality in the form of the method dojabberrpc (see APPENDIX E). The method takes a JID parameter as the service address, an XML file String parameter as the service call message and a message identifier String parameter for the Jabber server. It returns a String value which is an XML-RPC file presenting the service response. package fi.hut.jabber.client; import fi.hut.dialog.productinformation; import org.jabber.jabberbeans.util.jid; public class ProductInformationJabberClient { private JabberClient jb; private ResultHandler resulthandler; private String remotemethod = "PI.getProductInformation"; private String messageid = "123AE495"; public ProductInformationJabberClient (JabberClient jb) { this.jb = jb; resulthandler = new ResultHandler(); public ProductInformation invokeservice(jid endpoint, String prodid) { String message = RpcHelper.toXML(remoteMethod, prodid); String retstring = jb.dojabberrpc(endpoint, message, messageid); if (retstring!= null) { String[]results = resulthandler.getvalues(retstring); if (results!= null) return new ProductInformation(results[0],results[1],results[2].equals("1")); return null; Code for the ProductInformationJabberClient class. The class above wraps everything together for the Product Information Service on the client component. The remote method name has to agree with the mapping information on the server side (ch ). The messageid variable serves as a reminder for the Jabber server to match the return values to the right calls. Static toxml method of RpcHelper class is used to build appropriate XML-RPC messages for the Product 42

43 Information Service requests. The ResultHandler class offers a method for extracting data from the service response to build a ProductInformation Object, which is expected as a result. In short, RpcHelper class handles the serialization process according to the XML-RPC vocabulary and ResultHandler handles the opposite i.e deserialization (see APPENDIX F). To see the exact same client/server information exchange that was described in APPENDIX B with SOAP, but now with Jabber, refer to APPENDIX C. Again it is quite obvious, that the same amount of data is being transferred, but the Glue 2.3 SOAP implementation uses multiple times more network resources than Jabber RPC. 3.7 Security Considerations SOAP Extensions The main sponsors of SOAP protocol development, Microsoft and IBM, have come up with an extension (ch.2.4.3) to the protocol in order to provide quality of protection through message integrity, message confidentiality and single message authentication [WSsec]. The paper is called Web Services Security and it also suggests how to encode binary security tokens in the SOAP messages. In practise, most of the protocol implementations are poorly equipped for security issues and rely on external tools to provide secure communications over HTTP. TME Glue 2.3 has support for the Secure Sockets Layer (SSL) protocol in the form of the standard Java Secure Socket Extension (JSSE) class library, which requires JDK1.2 platform or higher to work on. Glue 2.3 also supports HTTP authentication, but that is a security mechanism for the Hypertext Transfer Protocol, not SOAP Jabber Security With Jabber the security extensions have not yet been documented anywhere, but the situation is basically the same as with SOAP. SSL support can be added on top of the protocol with available tools. Clients and servers can also keep lists of network endpoints that are trusted communicating parties. Further development is under way. 43

44 4 Evaluation 4.1 SOAP vs. XML-RPC Like said, SOAP is XML-RPC with more verbosity and arguably with more functionality. Data collections can be serialized in SOAP with dedicated XML vocabularies and this creates an illusion of transmitting Objects across a network. But when you look through all the protocol layers that are stacked on top of the raw text presentation of a single data item, there really is no more than one way to express a piece of information in UniCode (,or in ASCII). All Objects, in the end, consist of simple data types that can be serialized with the XML-RPC vocabulary and that is why XML-RPC can do virtually everything SOAP is capable of. The richer metadata features of SOAP, however, make it possible to create more complex interfaces between network endpoints helping the programming work considerably. In short, SOAP enables to create helpful programming tools (i.e. implementations) to achieve vivid software communication, but the network conversations in SOAP do not convey any more data than other protocols like XML-RPC Message Size It is nearly a rule with SOAP that the messages contain more metadata than primary information. Also, depending on the implementation, the data exchange may begin with downloading the WSDL file, which adds up to the strain on the network. As illustrated in chapter 2.4.2, it can happen that a SOAP message is multiple times the size of an XML-RPC message with the same data content. If one is to set up a Web service that takes simple data types in and gives simple data types out, it might be worth considering which protocol to use. Especially, if the user rate is expected to be high enough to put pressure on the server. 44

45 4.2 SOAP vs. RMI One of the reasons for SOAP s being here is the new.net software platform of Microsoft. The largest software company in the world decided to bring Web services development near the average programmer by creating a new product that offers a complete set of programming tools to create and publish XML interfaces on the Internet. Prior to the XML era, the cross network data exchange was done in nontextual binary formats and the protocols were too complex for other than advanced programmers. However, the Java programming language of Sun Microsystems had developed a simple built-in communication protocol, Remote Method Invocation (RMI), which became very popular as Java conquered the world of network-based application development. Java is still the most popular programming language in the world, but for obvious reasons Microsoft had to come up with something of its own, and as the XML hype started to rise, SOAP was created under the wings of W3C. When developing a network-based application today, the programming language is very likely to be Java and there rarely are situations where Java platform is rejected by either side of the conversation. In these cases RMI is always recommended over SOAP [McLwp]. But when cross network communication capabilities are added to a conventional application program, the situation is different. Serious PC applications like text editors, image designers, or industry specific utility programs are likely to be programmed in other languages than Java. SOAP is a convenient protocol for adding communication skills as a plug-in feature to an existing application. Sometimes it might even be, that the service provider is simply an XML oriented company in its data handling, and thus an XML interface on the Internet is a natural choice Performance Comparison The Dialog Web Application has managed software communications with both SOAP and RMI. This gives an opportunity to measure the performance of the two protocol implementations: RMI of JDK1.3.1 and SOAP of TME Glue 2.3. The setup is that one client machine makes service requests to two server machines one call at a time switching the destination on each request. The machines are ordinary desktop 45

46 computers and the requested service simply returns a String value without entering the main application. The test program measures the average times for processing a number of sequential service calls. The setup ensures that every message is handled as an individual service request. RMI vs. SOAP processing time SOAP RMI message count Processing times of service requests The result table above gives an indication of the relational differences between the two means of software communication. The processing times include network latency and Glue 2.3 suffers a bit from being behind the Apache Tomcat servlet engine. Still, one can estimate that RMI can transmit roughly twice the amount of service requests per second than the Glue 2.3 SOAP implementation Firewalls & PDA Hosts One selling argument of SOAP has been its preferred underlying transport protocol HTTP. Companies have years of experience in configuring their servers for secure HTTP information exchange with firewalls, which are software components monitoring the incoming service calls and filtering out any suspicious messages. This level of security does not, however, cover the content of the transported data package and that is why security extensions to the SOAP protocol are being developed. RMI 46

47 technology addresses the firewall issue with an option to make Remote Method Invocations as encapsulated HTTP POST requests. So, the two protocols are pretty much on the same line in the firewall matter. Personal Digital Assistant (PDA) is a hand held computing device having a limited software platform to run simple applications. The most popular software environment for Internet mobile phones and PDAs, Java 2 Platform Micro Edition (J2ME), comes with an optional RMI package and there are also SOAP implementations for the same Java environment. The choice between the two protocols depends on the needs of the application under development. 4.3 Jabber Communications Every node in a Jabber network can both talk and listen. Due to the Remote Procedure Call (RPC) nature of the presented SOAP and XML-RPC communications, the roles in their data exchange have been very strict. The client makes a service request with certain parameters and expects a return value from the service provider. With Jabber RPC the name already indicates that the pattern of software interaction is the same. Jabber protocol, however, guarantees that all network endpoints, once they have got online, are equally capable of receiving service requests and sending them. The embedded protocol dictates if and how that ability is used. SOAP and XML-RPC implementations usually require HTTP servers to accompany the server side and some implementations (like Glue 2.3 and Apache XML-RPC) come with built-in server components. It is not a challenge to equip any node of a SOAP network with some sort of HTTP server when it is necessary, but the Jabber protocol has bidirectional RPC already covered as a feature. 47

48 4.3.1 Dynamic Messages The concept of presence is another built-in feature of Jabber. When a node gets online, it becomes present in the Jabber network and this can be notified to other nodes. Real time data updates can be propagated to selected online nodes and thus achieve dynamics in the transmitted messages. For example, a web page might have a Jabber client as an embedded Java applet, and after downloading the page to a web browser the applet would report the status changes of some data collection in real time without the need to reload the page. This is again something that can be programmatically managed in many ways, but Jabber gives a protocol based approach to the subject and makes the network endpoints interoperable on this matter Challenging HTTP? As a transport protocol Jabber is on the same level in the protocol hierarchy as the Hypertext Transfer Protocol. Jabber clients communicate with Jabber servers via TCP sockets and the Jabber networks are conceptually completely separate from the world of HTTP servers and clients. In practice, the computers that act as Jabber nodes, do so through a Jabber based application (e.g. an IM client) and usually the same computers also produce and consume HTTP messages through other applications like web browsers. The two protocols can happily coexist, but being a newcomer, the Jabber protocol has understandable difficulties in establishing its position in today s network based software development. HTTP is a stateless protocol, meaning that neither side of the conversation keeps any status data of the other. HTTP can be extended with common practices (like cookies in the case of web browsers) to achieve the desired level of state management. Jabber servers maintain state information between two network endpoints so, that they can be aware of each others availability through presence notifications. Otherwise HTTP and Jabber are quite similar, in that both are protocols for exchanging text messages. The methodology is, however, very different. This can be observed by looking at APPENDIX B and APPENDIX C. HTTP can be used to transport XML messages. Jabber uses XML to transport any messages. 48

49 Companies that are familiar with Hypertext Transfer Protocol and maintaining HTTP servers, may find the transition to Jabber not worthwhile, if the new protocol just manages the same things in a different way. Jabber is being promoted and developed by people who take XML very seriously, and because XML offers every means of data handling, all aspects of the protocol can be encapsulated in an XML vocabulary. Including transport issues, like URIs (see APPENDIX C). Jabber protocol simply pleases the eye of an XML advocate, but there is no definite way to say, if it does a better job. Still, one can always list the requirements of a software component under development and then draw conclusions about the best protocol to use. HTTP is more or less considered a standard communication protocol, but there are options Gateways Jabber started as a bunch of software components that interpreted different IM applications messages into a uniform XML format. Those components are called gateways and they are still under development, because companies like Yahoo! constantly develop their IM applications and sometimes change their protocol, which in turn causes updates in the corresponding gateway component. Realizing the leading position of HTTP as a communication protocol, the Jabber community has also released a gateway component between Jabber RPC and HTTP/XML-RPC hosts. The HTTPgate software tool manages XML-RPC communications between a Jabber node and a HTTP node. For wireless software development, there are commercial gateway tools which bind cellular phones to the Jabber network. The basic idea of the Jabber protocol is to keep the client nodes as simple as possible and that is why the gateway components are meant to be installed on the Jabber servers. These gateways have their own Jabber Identifiers (JID) and when a Jabber client sends a message through a gateway, it is addressed to the component s JID with additional information about the actual receiver. In theory it is possible to connect any computing device to a Jabber network with a plug-in gateway software. The server centric architecture allows Jabber clients to maintain their lean composition and the gateways admit even non-jabber nodes to the network. 49

50 4.3.4 Firewalls & Network Latency The Internet Assigned Numbers Authority (IANA) has officially assigned ports 5222 and 5269 for Jabber protocol. The Jabber community recognizes that the protocol is not as widely accepted as HTTP and therefore many Jabber IM clients may be in a situation where their Jabber connections are blocked by the local network s firewall configuration. Of course, when Jabber services are seriously utilized and software development is being done, the network administrator will configure the firewall implementation in Jabber s favour. The issue is no different than with HTTP. Incoming messages are filtered and outgoing messages are accepted only on certain ports. Because of the server centric network architecture, the Jabber protocol is at first look likely to impose longer latency times on messages than HTTP. Every Jabber message travels through a server, which may reside on the same machine as one of the communicating parties. Commercial Jabber servers are optimized to process message forwarding very quickly, but it may still cause additional overhead to the Round Trip Time of a service request. There are no measurements on the subject available and the Jabber programming of this thesis is not a suitable test ground for this matter. 4.4 The REST Philosophy and Web Services There is an ongoing battle about the architectural future of the Internet on various mailing lists and discussion forums. Roy Thomas Fielding, the chief developer of HTTP, has created an architectural model for computer network design. This Representational State Transfer (REST) architectural style for distributed hypermedia systems [Fie00,ch.5] is basically how the World Wide Web stands today. Fielding has made several contributions to the development of WWW over the years and in his dissertation [Fie00] the rationale behind the development work is presented. A Web Service, on the other hand, still lacks a profound definition and yet it has been actively advertised as the keeper of the promises made about the commercial revolution of the Internet. W3C has scheduled the Web Services 50

51 Architecture Working Group to produce a Recommendation document about the technologies that make up Web Services in There are other working groups concentrating on SOAP, WSDL and XML Schemas, which are expected to be in the final bundle. Some people have argued that the massive developing work is focusing on creating something new and complex, while not producing anything that the existing protocols could not manage Vertical vs. Horizontal The question raised by Web Service skeptics is, whether we need to build the protocol stack any higher to achieve interoperability between network-based applications. HTTP and HTML forms have enabled web browser based, programming language independent Remote Procedure Calls years ago. Every business case that involves consumer input over the Internet can be handled with existing solutions. Web Services are supposed to make automated computer-to-computer interaction a reality, but can this be done without adding protocols on top of HTTP? Paul Prescod, a researcher and a former member of the XML Working Group of W3C, suggests a [Pre02,ch.2.3] horizontal protocol approach. He questions, if there has to be a Web Service architecture distinct from the existing Web architecture, where HTTP and URIs are the main building blocks today. The idea is that you can publish an XML interface (i.e. an endpoint which consumes and produces XML messages) as an Internet resource, just like a web page, that has a URI and others can interact with it using the HTTP operations GET, PUT and POST. Is there really a need for SOAP as the middle man? SOAP vs. XML Schemas The Simple Object Access Protocol has evolved drastically if the primary design goals are compared to the features of the SOAP 1.2 specification. The major motivation for SOAP development was to create a type system, a comprehensive XML vocabulary that would have served as an interpreter interface between different platforms and languages. Then came the XML Schema specification, which did the job and much more making SOAP rather a protocol framework than an actual 51

52 protocol. Don Box, SOAP co-founder and current Microsoft executive, said in a web article on 6 th of June, 2002 that: "Had XML Schema been done in 1998, we would not have done SOAP" [Kri02]. SOAP is designed for application-to-application communications, where service requests are triggered programmatically. Since there has to be information about the service interface available for the client design, there usually is an XML Schema file (see ch ) describing the content of service requests and responses. One can rightfully perceive the Schema file to be the standardization of the communication between the two software components. It really is XML Schema, that dictates the rules of data exchange. After all, the SOAP vocabulary itself is described with an XML Schema file. Don Box continues according to the aforementioned article: "The reality is, XML Schema is the foundation for the rest of XML" RESTifying Web Services REST advocates justify their point of view by giving examples of how the few existing web services talking SOAP can be managed with URIs talking HTTP. When there is the XML Schema technology, information flows between network endpoints can be standardized in an XML format and after that the discussion of interoperability is irrelevant, because HTTP is a language and platform independent application level protocol for software communication. Differences between REST and Web Services may seem a bit cosmetic, since SOAP over HTTP uses POST and GET methods of HTTP, and thus Web Services rely heavily on the REST architectural model, except for the endpoint identification. SOAP RPC identifies services with remote methods, which can be accessed through a URI. The REST way of thinking is that each service should have its own URI. Paul Prescod shows in a web article from February the 6 th, 2002 [PreWS] how UDDI registries can manage their operations with HTTP instead of a SOAP API (i.e. a collection of accessible SOAP remote methods) provided that the registry entities are identified with URIs. He suggests a guideline for the development of network-based applications: You can and should think about it as a data resource manipulation 52

53 problem rather than as an API design problem. He continues further: Any business problem can be thought of as a data resource manipulation problem and HTTP is a data resource manipulation protocol. RESTifying Web Services in practice means forgetting about SOAP and simply sending XML files of correct content to the correct address. The difference is not that radical when service calls include parameters. The messages will look a lot like before and only the few SOAP specific elements are stripped off of the transmitted XML files. But when a service call does not involve data input from the client side, the SOAP protocol really loses its appeal. If we assume that the Dialog Web Application s Product Information Service was realized according to the REST philosophy, then every product would have its own URI, which would present the unique XML file describing the product. The service call would be exactly like ordering an HTML file with HTTP POST or GET, but now the client receives an XML file, the vocabulary of which is of course agreed upon beforehand. The only immediate XML processing takes place on the client side just as is the case with web browsers and HTML processing. The server side is responsible for keeping the product s XML file up to date and available. When we compare the client/server SOAP RPC conversation with the REST and XML conversation, using SOAP in Web Services does not seem that attractive. Programmatic stages of the SOAP RPC REST and XML Product Information Service (c) WSDL file request send optional none (s) WSDL file send optional none (c) WSDL file processing optional none (c) XML request file build Required none (c) HTTP POST request Required required (s) XML request file processing Required none (s) XML response file build required (if not cached) none (s) HTTP POST response Required required (c) XML response file processing Required required The Dialog Product Information Service from SOAP and REST perspective. (c) indicates client side action and (s) server side. 53

54 4.5 Summary Network-Based Communication Design Every programming work should primarily concentrate on the needs of the application (i.e. needs of the application users) and secondarily on technology issues. The hype around the XML protocols in the past few years has invited programmers to explore new possibilities of achieving the same functionality as before, but with different tools. It is never advisable to do things differently just because it is possible. New techniques should be incorporated in the existing methodology only when they improve the results. The following table illustrates some common usage situations for application level communication protocols of network-based applications. It does not serve as a guideline, but simply indicates the situations where a given protocol is found more often. The common usability of communication protocols The table above makes a bit crude generalisations, for example, about CORBA not being used on Windows operating systems, but the idea is to point out tendencies. CORBA has been advertised as a solution for any possible communication problem, 54

55 but it rarely is the first choice for strictly Windows [Beq02,p.11]. Cross platform communication situations are more likely to be case Obstacles to Interoperability Web Services are described as XML interfaces on the Internet. Every interface defines, what kind of messages that network endpoint is willing to process and what comes out as the result. W3C and other players are trying to produce a coherent framework for ensured interoperability between all the XML interfaces, but so far they have received a lot of criticism of their accomplishments. The REST devotees have pointed out that we really do not need any more protocols. The work of W3C has, nevertheless, resulted in some important discoveries in the field of XML technologies and because of that, interoperability can be achieved, while not guaranteed, today. In a web interview on 6 th of November, 2001 [WiGos] James Gosling, the former lead developer at Sun Microsystems, acknowledges the importance of XML, but does not speak highly of SOAP when stating that it sucks in comparison to the existing solutions. And even if everyone was pleased with SOAP, it is only a framework for solving the real problem of standardizing information flows of different industries. The driving forces behind the SOAP development have been future scenarios, where different organizations and businesses utilize each other s data processing services over the Internet on an application-to-application basis. If all this communication was to be automated, it would require a world wide consensus of the service providers interface descriptions. James Gosling appreciates: the community effort to develop standardized schemas for common commercial utterances - like purchase orders [WiGos], but the work has not really begun yet. If one considers even the small scale commercial activities on the Internet today, the standardization of that would mean creating numerous XML vocabularies and everyone s acceptance for them. That is not an easy task considering the difficulties of setting up the mere framework, namely the SOAP protocol, for the job. 55

56 4.5.3 Where Are the Applications? Representational State Transfer (REST) is what the World Wide Web does today. Every data collection represents the state of some programmatic Object and that data is being transferred according to the actions of the communicating parties, clients and servers. Most of the service requests, like ordering a web page to a browser, are triggered by human actors. HTML forms have been the standard way of carrying out consumer directed transactions on the Internet for years. The Web itself, meaning the software interaction managed by web browsers and servers, is the application that made the Internet as popular as it is today. First came the application and then came the talk about protocols. HTTP 1.0 was not the best protocol for the evolving Web and so HTTP 1.1 was developed to better meet the needs of the application. XML and Web Services are said to be the saviours of e-commerce, but where are the applications? Desktop computers are nowadays so powerful and fast, that distributing the computing load over a network is not necessary with conventional applications. The use case scenarios of Web Services suggest that soon people can have software agents (i.e. independent interactive software components) surfing the Web for them and, for example, booking the cheapest available airline tickets to the desired destination. There is no application, that does this, but the technology has been around for years. If every airline company agreed on a uniform way of listing their ticket prices on the Internet, it would be easy to write a program, that scans through the lists and selects the winner. The fact that there is no such application, is not because of protocol issues, but because the airline companies do not wish to do so. On the other hand, after web surfing became immensely popular, all airline companies set up their own web pages. So, the evolution of the Web is strictly application driven and even if there are a lot of applications exchanging SOAP messages, one can not really say that there were any applications seriously utilizing Web Services. The Jabber community is not that much involved in the Web Service hype, but that is merely because they want to promote Jabber as a completely separate technology from the conventional Internet. Nevertheless, they have an application, which clearly supersedes the existing solutions. The Instant Messaging (IM) client program of the Jabber, Inc. not only offers the services of a standard IM client, but also connects to 56

57 every other existing IM system (or to those that have not intentionally blocked Jabber). The application uses the convention of presence (see ch.2.5.4) so, that every time the user connects to the Jabber network, he receives the latest news headlines, the latest sports results, the latest weather forecasts and automatically the latest software updates of the program. The chatting features have become less dominant in the application and the service spectrum will continue to expand in the future. Looking at the growing list [JaInc] of their business partners, the Jabber community might be onto something. At least they have the application, the presence aware Jabber network, to build on. 57

58 5 What Next? 5.1 The Future of Web Services The SOAP sceptics, and especially those cheering for the REST model, see that the current Internet architecture will prevail and things will stay more or less the same. No one is talking against Web Services in general, but against creating complexity on top of the simple ideas of the current World Wide Web. Paul Prescod says in the previously quoted article [PreWS], that: The next generation of web services will use individual data objects as endpoints. Software component boundaries will be invisible and irrelevant. In his opinion the Web simply cannot be handled as a closed-world problem where Remote Procedure Call (RPC) style of resource access technologies could succeed. With the few verbs of HTTP (GET, PUT, POST, DELETE) and the countless number of nouns (resources identified with URIs) we have application-toapplication interoperability here today. SOAP RPC would create an additional layer of complexity with SOAP extensions, remote method names and implementation specifics. XML interfaces on the Internet will probably increase if companies learn how to standardize and develop their information exchange. The problem has very little to do with technology and more to do with politics, economics and social psychology. W3C defines Web Services currently like this: A Web service is a software application identified by a URI, whose interfaces and bindings are capable of being defined, described, and discovered as XML artifacts. A Web service supports direct interactions with other software agents using XML based messages exchanged via internet-based protocols. [WebSe] This definition doesn t say anything about the role of SOAP, but with or without it language and platform independence is a reality. 58

59 5.2 Standardization Efforts The World Wide Web Consortium (W3C) is an organization of companies that are financially dependent on the evolution and expansion of the Web. Most of the Internet standards produced by W3C have originated from the sheer willingness to make things better and the commercial aspirations have stayed in the background. There are also organizations like RosettaNet [RoNet] focusing on standardizing how to use the Web for business information exchange. The fact, that the Internet did not fulfil the promises of e-commerce revolution, was because the people chose not to shop on the Internet. And that was because there were no good applications. And that was because the application developers could not offer consumers programmatic features, that could have surpassed the conventional way of shopping. And that was because there was not enough co-operation between the businesses that rushed to the Web. And that was because everyone wanted to get rich first and make things better second. The World Wide Web has brought about some interesting phenomena, like open source communities and non-profit organizations, but it will be a difficult task to convince traditional businesses not to look for the profit margin, but to look for ways to improve things. The profit is usually done at someone else s expense with no intentions of sharing. Meaningful standardizing is done together and the results are shared with everyone. Standards can be achieved through quality applications like the World Wide Web. When something becomes popular enough, it becomes a standard. Standards can also be jointly agreed upon, after which quality applications can be developed. An example of this is the ongoing struggle around Web Services. It might be that in the case of e-commerce both approaches are equally vital. After the business world has reached the critical level of standardizing information flows, the first true Web Service application can be developed and if it becomes a success, everyone will follow. 59

60 5.3 Intelligent Agents and Web Services As stated before, the quest for language independence in software communication is motivated mainly by the visions of automated Web Service utilization. For example, a software component representing a person knows his calendar, knows his location, knows where he has to be tomorrow and books the travel tickets based on the person s preferences. The travel agency is represented by another software component that handles the details on that side of the conversation. These software components work autonomously and communicate with other components. They have the ability to make decisions and pursue the desired goals. The term Intelligent Agent has been suggested to describe such a software component that is a kind of a worker ant for some physical or virtual object. The intelligence of these components is nothing more than conventionally programmed features, but those features usually include the ability to choose between multiple options when searching and conducting a particular service The Web Service Browser When a person downloads a web page to a browser he is said to be surfing the Web. His representative software component, the web browser, is not moving anywhere, but requesting information to the host machine. This is the state of affairs today. One could write a program that makes queries to the Google search engine using the Google SOAP API [GooSO]. The program could ask about the user s interests and use that information to search for web pages with the desired content. The program could also do the search routine on a daily basis independently, provided that the computer is on. This is a feasible example of an Intelligent Agent utilizing a Web Service on physical object s behalf. The eager surfer has everyday updated resource pointers instantly available. Of course this does not make life a lot easier, but what if those selected Internet resources, URIs, conformed to a uniform data presentation standard? Let s say, that the airline companies had agreed on an XML vocabulary for listing tomorrow s budget flights to the Canary Islands. The program could every day request the XML files (HTTP GET or POST) from the listed URIs and select the cheapest flight. If the price was below the limit set by the user, the program could 60

61 send an SMS message about it to the user s cellular phone or book the flight right away. This kind of automated service utilization would spare the consumer s time already in a larger scale. The application capable of previous actions would actually be the prototype of a Web Service Browser that should interest consumers, who do not want to spend time looking for information and evaluating it. When the element of automation is removed from the application, you have the traditional web browser. It is easy to understand that the precondition for developing such an application is the standardization of various business data presentations, and that it would involve some serious co-operation across company limits. 5.4 XML Tomorrow The family of XML technologies is expanding all the time. One recent member is the Voice Extensible Markup Language (VoiceXML). This technology is designed for creating audio dialogs that feature synthesized speech, digitized audio, recognition of spoken and Dual Tone Multi-Frequency (DTMF) key input, recording of spoken input, telephony, and mixed-initiative conversations. Its major goal is to bring the advantages of web-based development and content delivery to interactive voice response applications. [VoXML] Based on this description one can anticipate pretty interesting times in the XML world. The key technology is, however, the XML Schemas, which sets the rules for creating other XML vocabularies. To keep up with the latest protocol definitions and working drafts the W3C web site is the place to go. 61

62 References Books Beq01 Bequet, H., Professional Java SOAP Programming., Wrox Press Ltd 2001 McL01 McLaughlin, B., Java & XML., O Reilly & Associates, Inc DJA02 Adams, DJ., Programming Jabber., O Reilly & Associates, Inc Articles Kär02 Kärkkäinen, M. et al., Integrating Material and Information Flows Using a Distributed Peer-to-Peer Information System., Helsinki University of Technology., 2002 White Papers MITa02 Auto-ID Center of MIT, The Object Name Service version 0.5, 1 February MITb02 Brock, D., The Virtual Electronic Product Code, 1 May Fie00 Fielding, R., Architectural Styles and the Design of Network-Based Software Architectures, University of California Web sites (last visited ) WebSe W3C, Web Services Architecture Requirements, 29 April Wspec W3C, Web Services Description Language 1.1, 15 March OMGpg Object Management Group, About Object Management Group, 21 May XML98 W3C, Extensible Markup Language 1.0, 10 February XML10 W3C, XML in Ten Points, 20 December

63 DCOMp Microsoft, Inc., DCOM, 30 March XRPCp Userland Software, Inc., What is XML-RPC?, 5 November Xspec Userland Software, Inc., XML-RPC Specification, 27 April Ximpl Userland Software, Inc., XML-RPC Implementations, 10 November UniSt Unicode, Inc., What is Unicode?, 13 December XMLna W3C, Namespaces in XML, 14 January XSche W3C, XML Schema Part 1: Structures, 2 May SOA12 W3C, SOAP Version 1.2 Part 1: Messaging Framework, 26 June SOpri W3C, SOAP Version 1.2 Part 0: Primer, 26 June SOSch Rub02 W3C, Ruby, S., To Infinity and Beyond- the Quest For SOAP Interoperability, 1 February QuestForSoapInteroperability.html SOREp Prescod, P., The Role of HTTP, 6 February SOSuC W3C, Comment on the SOAP Submission, 8 May SOFaq Developmentor, Frequently Asked Questions (3), SOimp Userland Software, Inc., SOAP Implementations, 17 October JAB00 Miller, J. et al., Jabber Specification, 21 February JABFQ JABSO Jabber Software Foundation, About Jabber, General FAQ, Jabber Software Foundation OSCON Adams DJ, Outrageous Uses of Jabber, 26 July

64 rfc2396 Berners-Lee, T. et al., Uniform Resource Identifiers, August rfc791 University of Southern California, DARPA Internet Program Protocol Specification, September rfc1034 Mockapetris, P., Domain Names Concepts and Facilities, November UDorg OASIS UDDI Member Section, About UDDI Nok01 Matthews, M., Nokia and 2Scoot begin trials, 5 January WSsec Atkinson, B. et al., Web Services Security, 5 April SOsec W3C, SOAP Security Extensions: Digital Signature, 6 February McLwp McLaughlin, B., A Closer Look at SOAP, April JEP25 Hildebrand, J. et al., Jabber HTTP Polling, 23 September WSawg W3C, Web Services Security Statement, 17 October Pre02 Prescod, P., Roots of the SOAP/REST Debate, Kri02 Krill, P., Microsoft exec calls for innovative Web Services apps, 6 June JaInc Jabber, Inc., Customers, PreWS Prescod, P., Second Generation Web Services, 6 February PreRE Prescod, P., REST and the Real World, 20 February WiGos Winer, D., Gosling on SOAP, 11 June RoNet RosettaNet, RosettaNet Home GooSO Google, Google Web APIs, VoXML W3C, Voice Extensible Markup Language 2.0, 24 April

65 APPENDIX A ProductInformationSOAPService.wsdl <?xml version='1.0' encoding='utf-8'?> <!--generated by GLUE on Thu Jul 11 15:45:44 EEST > <definitions name='fi.hut.dialog.server.productinformationsoapservice' targetnamespace=' fi.hut.dialog.server.productinformationsoapservice/' xmlns:tns=' fi.hut.dialog.server.productinformationsoapservice/' xmlns:soap=' xmlns:http=' xmlns:mime=' xmlns:xsd=' xmlns:soapenc=' xmlns:wsdl=' xmlns=' xmlns:tme=' xmlns:ns11=' <types> <schema xmlns=' targetnamespace=' <complextype name='productinformation'> <sequence> <element name='identifier' nillable='true' type='string'/> <element name='uri' nillable='true' type='string'/> <element name='information' nillable='true' type='string'/> <element name='iscollection' type='boolean'/> </sequence> </complextype> </schema> </types> <message name='getproductinformation0in'> <part name='arg0' type='xsd:string'/> </message> <message name='getproductinformation0out'> <part name='result' type='ns11:productinformation'/> </message> <porttype name='fi.hut.dialog.server.productinformationsoapservice'> <operation name='getproductinformation' parameterorder='arg0'> <input name='getproductinformation0in' message='tns:getproductinformation0in'/> <output name='getproductinformation0out' message='tns:getproductinformation0out'/> </operation> </porttype> <binding name='fi.hut.dialog.server.productinformationsoapservice' type='tns:fi.hut.dialog.server.productinformationsoapservice'> <soap:binding style='rpc' transport=' <operation name='getproductinformation'> <soap:operation soapaction='getproductinformation' style='rpc'/> <input name='getproductinformation0in'> <soap:body use='encoded' namespace=' encodingstyle=' </input> <output name='getproductinformation0out'> <soap:body use='encoded' namespace=' encodingstyle=' </output> </operation> </binding> <service name='fi.hut.dialog.server.productinformationsoapservice'> <port name='fi.hut.dialog.server.productinformationsoapservice' binding='tns:fi.hut.dialog.server.productinformationsoapservice'> <soap:address location=' </port> </service> </definitions> 65

66 APPENDIX B a client/server SOAP conversation (TME Glue 2.3 procedure) Product Information WSDL request: GET /soap_dialog/services/pi.wsdl HTTP/1.1 Host: dialog.hut.fi:8080 User-Agent: GLUE/2.3.1 Connection: Keep-Alive WSDL Response: see APPENDIX A Product Information Service Request: POST /soap_dialog/services/pi HTTP/1.1 Host: dialog.hut.fi:8080 Content-Type: text/xml; charset=utf-8 User-Agent: GLUE/2.3.1 Connection: Keep-Alive SOAPAction: "getproductinformation" Content-Length: 535 <?xml version='1.0' encoding='utf-8'?> <soap:envelope xmlns:xsi=' xmlns:xsd=' xmlns:soap=' xmlns:soapenc=' soap:encodingstyle=' <soap:body> <n:getproductinformation xmlns:n=' <arg0 xsi:type='xsd:string'>someproductidentification </arg0> </n:getproductinformation> </soap:body> </soap:envelope> Service Response: HTTP/ OK Content-Type: text/xml; charset=utf-8 Content-Length: 851 Date: Fri, 13 Sep :59:49 GMT Server: GLUE/2.3.1 <?xml version='1.0' encoding='utf-8'?> <soap:envelope xmlns:xsi=' xmlns:xsd=' xmlns:soap=' xmlns:soapenc=' soap:encodingstyle=' xmlns:ns5=' <soap:body><n:getproductinformationresponse xmlns:n=' <Result href='#id0'></result> </n:getproductinformationresponse> <id0 id='id0' soapenc:root='0'xsi:type='ns5:productinformation'> <identifier xsi:type='xsd:string'>someproductidentification </identifier> <information xsi:type='xsd:string'>test_info </information> <iscollectionxsi:type='xsd:boolean'>false </iscollection> </id0> </soap:body> </soap:envelope> 66

67 APPENDIX C a client/server Jabber conversation through JabberD at localhost Product Information Service Request: <iq to="dialog@localhost/jrpc-server" id="123ae495" type="set"> <query xmlns="jabber:iq:rpc"> <methodcall> <methodname>pi.getproductinformation</methodname> <params><param> <value>someproductidentification</value> </param></params> </methodcall> </query> </iq> Service Response: <iq to="client@localhost/jrpc-client" id="123ae495" type="result"> <query xmlns="jabber:iq:rpc"> <methodresponse><params> <param><value><array> <data> <value>someproductidentification</value> <value>test_info</value> <value><boolean>0</boolean></value> </data> </array></value></param> </params></methodresponse> </query> </iq> 67

68 APPENDIX D DialogJabberResponder.java package fi.hut.jabber.server; import fi.hut.jabber.*; import org.jabber.jabberbeans.*; import org.jabber.jabberbeans.extension.*; import org.jabber.jabberbeans.util.jid; import java.net.inetaddress; import java.util.enumeration; import java.io.*; import org.apache.xmlrpc.*; public class DialogJabberResponder implements PacketListener { private final String SERVER, USER, PASSWORD, RESOURCE; protected XmlRpcServer xmlresponder; private ConnectionBean cb; public DialogJabberResponder(String server, String user, String password, String resource) { this.server = server; this.user = user; this.password = password; this.resource = resource; xmlresponder = new XmlRpcServer(); public void start() throws Exception { cb = new ConnectionBean(); InetAddress addr; cb.addpacketlistener(this); // Connect cb.connect(addr=inetaddress.getbyname(server)); // Authenticate InfoQueryBuilder iqb = new InfoQueryBuilder(); IQAuthBuilder iqauthb = new IQAuthBuilder(); iqb.settype("set"); iqauthb.setusername(user); iqauthb.setpassword(password); iqauthb.setresource(resource); iqb.addextension(iqauthb.build()); InfoQuery iq = (InfoQuery)iqb.build(); cb.send(iq); // Send presence PresenceBuilder pb = new PresenceBuilder(); cb.send(pb.build()); 68

69 // Packet Listener interface: public void receivedpacket(packetevent pe) { Packet packet = pe.getpacket(); System.out.println("RECV:" + packet.tostring()); if (packet instanceof InfoQuery) { Enumeration e = ((InfoQuery)packet).Extensions(); if (e.hasmoreelements()) { Extension ext = (Extension)e.nextElement(); String request = ext.tostring(); String id = ((InfoQuery)packet).getIdentifier(); JID from = ((InfoQuery)packet).getFromAddress(); ByteArrayInputStream bis = new ByteArrayInputStream(request.getBytes()); String result = new String(xmlResponder.execute(bis)); String response = result; int pos = result.lastindexof("?>"); if (pos >= 0) { response = result.substring(pos + 2); IQRPCBuilder iqrpcb = new IQRPCBuilder(); iqrpcb.setpayload(response); InfoQueryBuilder iqb = new InfoQueryBuilder(); iqb.settype("result"); iqb.setidentifier(id); iqb.settoaddress(from); iqb.addextension(iqrpcb.build()); InfoQuery iq; try { iq = (InfoQuery)iqb.build(); catch (InstantiationException ie) { System.out.println("Build failed: " + ie.tostring()); return; cb.send(iq); public void sentpacket(packetevent pe) { Packet packet = pe.getpacket(); System.out.println("SEND:" + packet.tostring()); public void sendfailed(packetevent pe) { Packet packet = pe.getpacket(); System.out.println("failed to send:" + packet.tostring()); 69

70 APPENDIX E dojabberrpc method from JabberClient.java public String dojabberrpc(jid endpoint, String message, String msgid) { IQRPCBuilder iqrpcb = new IQRPCBuilder(); iqrpcb.setpayload(message); InfoQueryBuilder iqb = new InfoQueryBuilder(); iqb.settype("set"); iqb.setidentifier(msgid); iqb.settoaddress(endpoint); iqb.addextension(iqrpcb.build()); InfoQuery iq; Packet response; try { iq = (InfoQuery)iqb.build(); catch (InstantiationException ie) { System.out.println("Build failed: " + ie.tostring()); return null; SyncPacketListener sync = new SyncPacketListener(cb); try { response = sync.sendandwait(iq, timeout); catch(interruptedexception e) { System.err.println("Operation interrupted!"); return null; if (response == null) { System.err.println(" Unable to deliver message!"); System.err.println(" "+endpoint+" was not reached."); return null; String type = ((ContentPacket)response).getType(); if (type!= null && type.equals("error")) { System.err.println(" Call to "+endpoint+" returned ERROR!"); System.err.print(" Error code: "); System.err.print(((ContentPacket)response).getErrorCode()); System.err.println(" "+((ContentPacket)response).getErrorText()); return null; String xmlpayload = null; Enumeration e = ((InfoQuery)response).Extensions(); if (e.hasmoreelements()) { Extension ext = (Extension)e.nextElement(); xmlpayload = ext.tostring(); return xmlpayload; 70

71 APPENDIX F ResultHandler.java and RpcHelper.java package fi.hut.jabber.client; import org.xml.sax.*; import uk.co.wilson.xml.minml; import java.util.vector; import java.util.date; import java.io.*; public class ResultHandler extends MinML { private Vector result; private String[] returnarray; private boolean isfault; public ResultHandler() { result = new Vector(); public String[] getvalues(string msg) { ByteArrayInputStream bis = new ByteArrayInputStream(msg.getBytes()); try { parse(new InputStreamReader(new BufferedInputStream(bis, 1024))); catch (IOException e) { System.out.println("IOException: " + e); e.printstacktrace(); catch (SAXException e) { System.out.println("SAXException: " + e); e.printstacktrace(); catch (Throwable e) { System.out.println("Exception: " + e); e.printstacktrace(); if (isfault) { System.err.println(" XML-RPC error:"); for (int i=0; i<returnarray.length; ++i) { System.err.println(returnArray[i]); return null; return returnarray; public void startelement (String name, AttributeList attributes) { if (name.equals("fault")) isfault = true; public void enddocument() { returnarray = new String[result.size()]; for (int i = 0; i < returnarray.length; ++i) { returnarray[i] = (String)result.get(i); public void characters (char ch[], int start, int length) { result.addelement(new String(ch, start, length)); public void fatalerror (SAXParseException e) throws SAXException { System.out.println("Error: " + e); throw e; package fi.hut.jabber.client; 71

72 import fi.hut.dialog.*; import java.util.*; import java.text.*; public class RpcHelper { public static String toxml(string remotemethod, Object obj) { if (LocationUpdate.class.isInstance(obj)) return marshalllu(remotemethod, (LocationUpdate)obj); if (IdentifierLinkMsg.class.isInstance(obj)) return marshallil(remotemethod, (IdentifierLinkMsg)obj); if (String.class.isInstance(obj)) return marshallpi(remotemethod, (String)obj); return null; private static String marshalllu(string rm, LocationUpdate lu) { Object[]params = new Object[5]; params[0] = lu.getidentifier();params[1] = lu.geturi(); params[2] = lu.getlocation();params[3] = lu.getcomment(); params[4] = lu.getdate(); return buildrpccall(rm, params); private static String marshallil(string rm, IdentifierLinkMsg il) { Object[]params = new Object[4]; params[0] = il.getidentifier();params[1] = il.geturi(); params[2] = il.getdate();params[3] = il.getinternalreferences(); return buildrpccall(rm, params); private static String marshallpi(string rm, String id) { Object[]params = new Object[1]; params[0] = id; return buildrpccall(rm, params); private static String buildrpccall(string remotemethod, Object[]arguments) { String result = "<methodcall><methodname>"+remotemethod+ "</methodname><params>"; for (int i=0; i < arguments.length; ++i) { result += "<param><value>"; result += getparamtype(arguments[i]); result += "</value></param>"; result += "</params></methodcall>"; return result; private static String getparamtype(object param) { String result = ""; if (String.class.isInstance(param)) { result = "<string>" + (String)param + "</string>"; else if (Integer.class.isInstance(param)) { result = "<i4>" + ((Integer)param).intValue() + "</i4>"; else if (Date.class.isInstance(param)) { SimpleDateFormat formatter = new SimpleDateFormat("yyyyMMdd'T'HH:mm:ss"); result = "<datetime.iso8601>" + (formatter.format((date)param)).tostring() + "</datetime.iso8601>"; else if (Boolean.class.isInstance(param)) { result = "<boolean>" + ((Boolean)param).booleanValue() + "</boolean>"; else if (String[].class.isInstance(param)) { result = "<array><data>"; for (int i = 0; i < ((String[])param).length; ++i) { result += "<value>" + ((String[])param)[i] + "</value>"; result += "</data></array>"; return result; 72