Mathieu Baeumler
Fabrice Daugan
David Hoeung
January 2004
Contents Intro
2
1 SOAP 1.1 W3C abstract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 SOAP messages . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3 3 4
2 server 2.1 Tomcat . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.2 Apache Soap . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2.3 implementation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6 6 7 7
3 SmartPhone
8
Conclusion
9
A D´ eploiement
10
1
Introduction ’The LuxDeal case study consists of an e-exchange web site that allows its members to exchange items.’
At the moment when we read for the first time the project’s main goals, an IMode and a WAP prototype had been already developed. We had to extend these implementations with SmartPhone[1] and J2ME [2] technologies. Considering the large variety of possible clients (web browser, mobile phone, Rich client) for such a service, we tried to develop a light server architecture, independent of the client’s platform. One of the major tasks of this project was to find a simple way of exchanging data between a server and the clients, regardless of their platform and their respective programming language. Several solutions exist that provide these functionalities, like CORBA or RMI. But another popular solution used by developers over the Net, and which suits well to our objectives, is the Web-services, supported by SOAP, the Simple Object Access Protocol. This is the solution we have chosen, and we’re going to explain how we have realized the server and his clients. But first of all, we have to give a quick explanation of how SOAP work.
2
Chapter 1 The Simple Object Access Protocol 1.1
description
he W3C[3] organization provide us a simple definition of what SOAP is and what it does with his recommendations[4]:
T
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. Another way of explaining what SOAP will do for us is to say that we have to provide some services to client’s applications. These services are described by the functions they implement, and the clients are aware of these signatures. They send a SOAP request to listener, in which they call a named function with its parameters, to a listener. This listener translates the request for the service, wait for the response and send it within a SOAP message1 :
Figure 1.1: SOAP exchange
1
image thanks to Soapuser website[5]
3
Chapter 1. SOAP
1.2
Structure of SOAP messages
A soap message structure is formalized as above. Our server and clients applications must conform to it, but some parts are optional(*) and may be ignored. SOAP message, the basic unit of communication between SOAP nodes. SOAP envelope, The outermost element information item of a SOAP message. SOAP header*, A collection of zero or more SOAP header blocks each of which might be targeted at any SOAP receiver within the SOAP message path. SOAP header block*, In general, contain information which might be of use to SOAP intermediaries as well as the ultimate destination of the message. SOAP body, A collection of zero or more element information items targeted at an ultimate SOAP receiver in the SOAP message path. SOAP fault*, A SOAP element information item which contains fault information generated by a SOAP node. Suppose a client want to contact a web-service named LuxdealService. It should use an authentification function first, called for example login. This function would have two string parameters, username an password. Finally, suppose that this service is hosted on localhost, listening the port 5555. Here we show the corresponding SOAP request, and the response2 : 2
in which the server as authentified Cedric
Chapter 1. SOAP
Figure 1.2: Example of SOAP transaction
Chapter 2 The LuxDeal Web-service 2.1
Apache Tomcat
s mentioned in figure 1.1, the central part of this project’s architecture is a listener. It waits SOAP request, then it translates them into a method call for our service. The listener used in the two precedent prototype was the Tomcat[6] servlet container. We keep it, along with the mysql database, although we used EasyPhp[7], which provides an easy-to-use administration tool. We can now draw the entire architecture of our project :
A
Figure 2.1: Server Architecture
6
Chapter 2. server
2.2
Apache Soap
We’re going to use Java to implement the web-service, but we have first to allow Tomcat to redirect SOAP requests to a servlet which can understand them and call the corresponding methods. This will be done with Soap[8] application. After the study of LuxDeal specifications, we have discovered that we can use simple types to fulfill all our transactions. To be more accurate, String Array is the only type we use, due to its portability with the different SOAP implementation. If you look for advanced compatibility tests, you can go at ksoap homepage and look their interoperability tests[9].
2.3
The LuxDeal Web-service
The server implementation of LuxDeal service consist in two main classes, LuxDealDBInitServlet and LuxDealDB . The first one is a simple servlet, launched at Tomcat startup. This servlet is connected with the database and ensures authentification of users. It gives a connection to granted clients. LuxDealDBInitServlet is not yet configured to response to SOAP requests, but it could be used in the future to administrate the database as a private Web-service. The class LuxDealDB implements the service methods. The functions of I-Mode and WAP prototypes are all supported, and new ones have been created.
Figure 2.2: Luxdeal Web-service Architecture
Chapter 3 SmartPhone
8
Conclusion
9
Appendix A Tomcat & co
10
List of Figures 1.1 SOAP exchange . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1.2 Example of SOAP transaction . . . . . . . . . . . . . . . . . . . . . .
3 5
2.1 2.2
6 7
Server Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . Luxdeal Web-service Architecture . . . . . . . . . . . . . . . . . . . .
11
Bibliography [1] Windows software mobile for smartphones. http://www.microsoft.com/ windowsmobile/products/smartphone/default.mspx. 2 [2] Java 2 platform, micro edition (j2me). http://java.sun.com/j2me/. 2 [3] The w3c organization. http://www.w3.org. 3 [4] Soap w3c recommendation. http://www.w3.org/TR/SOAP/. 3 [5] Soapuser website. http://www.soapuser.com/. 3 [6] Tomcat, version 5. http://jakarta.apache.org/tomcat/index.html. 6 [7] Easyphp homepage. http://www.easyphp.org/. 6 [8] Apache soap for java package,version-2.3.1. http://xml.apache.org/soap/ index.html. 7 [9] compatibility issue with ksoap. URL:http://ksoap.enhydra.org/software/ documentation/round-2-base/index.html. 7
12
