ARTAIL LAYOUT
10/6/10
10:51 AM
Page 81
ACCEPTED FROM OPEN CALL
A SERVER-IN-THE-MIDDLE APPROACH FOR ENABLING MOBILE DEVICES TO DISCOVER AND INVOKE WEB SERVICE METHODS ON DEMAND HASSAN ARTAIL AND HAIDAR SAFA, AMERICAN UNIVERSITY OF BEIRUT RAWIA ABDEL-SAMAD, BOOZ ALLEN HAMILTON IBTISSAM EZZEDINE, UNIVERSITY OF ILLINOIS AT URBANA-CHAMPAIGN OMAR ABOU-FARAJ, OC&C
ABSTRACT
Mobile device User input
(4) (9)
) (5)
Text matching algorithm
Mobile devices are becoming more pervasive, and it is becoming increasingly necessary to integrate Web services into applications that run on these devices. We introduce a novel approach for dynamically invoking Web service methods from mobile devices with minimal user intervention that only involves entering a search phrase and values for the method parameters. The architecture overcomes challenges that involve consuming discovered services dynamically by introducing a server in the middle that provides a Web service whose responsibility is to discover needed services and build the client-side proxies at runtime. Moreover, experiments have shown that the architecture is scalable and saves device battery power.
Short list of web i
The authors introduce a approach for dynamically invoking Web service methods from mobile devices with minimal user intervention that only involves entering a search phrase and values for the method parameters.
INTRODUCTION The technology of Web services has emerged as a popular middleware for offering remote method invocation capability. Recent trends in mobile computing and the popularity of mobile devices has motivated interest in accessing Web services from mobile devices in order to gain access to remote data and extend the functionality of such devices. However, the technology that allows devices to dynamically access Web services is not yet mature as there are infrastructural issues, which need to be tackled [1]. Enabling a client device to access a Web service dynamically requires building at runtime, on the device itself, a client-side proxy class for accessing the Web service. This in turn requires the presence of a programming language compiler in order to generate the class from the Web Service Description Language (WSDL) file of the particular service. Several approaches have been developed or proposed for solving aspects of this problem. However, they either are not suited for mobile
IEEE Wireless Communications • October 2010
devices or follow an altogether different style than the standard for invoking Web services, like Representational State Transfer (REST), which has not yet been adopted widely by the software industry. Besides this technical issue, it is intuitive to design architectures for mobile devices that conserve battery power and reduce user wait times. Indeed, such devices depend primarily on their batteries for power to communicate and run applications. Power conservation becomes more critical when the device participates in a cooperative environment, like a mobile ad hoc network (MANET), where it is expected to perform network-wide functions such as multihop routing. Our work provides a solution that addresses the inability of mobile devices to build proxies at runtime, a necessary operation to invoke Web methods of services that are being discovered dynamically and have not been accessed before from the device. Moreover, it offers a scalable architecture that reduces device battery power consumption when accessing Web services, and allows mobile device users to seamlessly acquire needed data through dynamic invocation of Web methods by merely supplying search phrases and entering argument values into a dynamically generated graphical user interface (GUI). Work described in the literature provides solutions to aspects of the problem we are addressing, but is not suitable for mobile computing. Of most relevance to our work, the DynWsLib library [2] enables .NET clients to invoke Web services dynamically by generating the client-side proxy class at runtime. However, according to one developers’ forum, this library worked consistently with services running on the local server, but issues were encountered when trying to reference remote services. Moreover, this library, which is no longer supported, does not provide an effective mechanism to handle specific types during the proxy generation process. The ProxyFactory project [3], which builds on DynWsLib,
1536-1284/10/$25.00 © 2010 IEEE
81
ARTAIL LAYOUT
10/6/10
10:51 AM
The client-side proxy class creation is normally performed on the development machine at design/compile time. To be able to do this at runtime for the mobile device, we implemented a man-in-the-middle (MIM) server.
Page 82
tries to address this issue by taking advantage of the unification of communications technologies provided by the .NET Framework. Unfortunately, it cannot run on the Compact Framework (lightweight version of .NET targeted for smart devices) due to several incompatibilities, one of which is the lack of a serialization class for this framework. In other related works, servers in the middle were integrated into architectures to make the invocation of Web methods faster. In [4] it was argued that the normal Web Service architecture, which integrates a requestor, a broker, and a provider, does not allow for designing a suitable service invocation on mobile devices. Therefore, a service gateway is suggested between the requestor and the rest of the architecture. It was recognized that the proposed solution requires additional code on both the mobile phone, and more critically on the service side, which poses a serious issue in that already deployed services will not work. Simulation results show that a Java-enabled mobile phone accessing a Web Service via the service gateway works much faster than invoking the method from the phone using the KSOAP protocol (a light version of the Simple Object Access Protocol [SOAP]).
OVERVIEW OF WEB SERVICES A Web service is a collection of Web methods that can be called over the Internet. A Web service consumer makes a call to one of its methods normally through a previously registered proxy class local to his computer. The class takes care of sending requests over the Internet to the server, and getting results back plus presenting them to the consumer. Two different techniques exist for accessing Web services: the SOAP framework and the REST approach.
SOAP FRAMEWORK SOAP is a lightweight XML protocol for exchanging structured and typed information on the Web. For invoking Web service methods using the SOAP protocol, the client-side proxy wraps the user’s request (method call) into an XML SOAP message and transmits it to the remote Web service. On the server, the service extracts the call from the SOAP message, executes the call, wraps the results into an XML SOAP message, and sends it to the client. Upon receiving the message, the client proxy extracts the results and hands them over to the calling application. However, before an application can begin communicating with a Web service, it must discover the service, get the list of its supported methods and invocation details, and then generate the proxy class. A service is usually discovered through the UDDI registry, which is a service broker through which service providers advertise their services. A service description on the UDDI includes information about the provider, list of exposed services, their URLs, and their interfaces. Using the URL, the client can download the service’s WSDL file, which contains the list of available methods and their invocation details. The WSDL file is used to cre-
82
ate the proxy class, which is platform-specific and must be created for the client that intends to use it. Its role is to allow the client application to make method calls as though it were calling a local function. To generate this class, a language specific source file (e.g., C#) is outputted from the WSDL file and then compiled. As a final step, the proxy must be registered with the client application, which can start making Web method calls to the particular Web service.
REST APPROACH REST [5] stands for Representational State Transfer, and is an architecture style that provides an alternative to SOAP for consuming Web services. With this approach, a Web service makes available a URL that returns an XML document, which in turn can include links to other documents. This allows the user to drill down to get more details or other related information. For sending data to the server, the service also provides a URL that allows the user to create an instance document which conforms to a schema publicized in a WSDL document. The user then submits the XML document as the payload of an HTTP POST. The provided URLs are logical, not physical, and correspond to conceptual entities (not static documents). Hence, a key characteristic of REST is that all resources exposed by a Web service can be accessible using an HTTP GET, POST, PUT, and/or DELETE. This is different than SOAP, which is regarded by many as an RPC middleware that utilizes Web protocols for transport.
SYSTEM DESCRIPTION The client-side proxy class creation is normally performed on the development machine at design/compile time. To be able to do this at runtime for the mobile device, we implemented a man-in-the-middle (MIM) server whose responsibility is also to discover needed Web services on behalf of the mobile device in addition to building the proxies dynamically. This server can be installed on the LAN to which the access points that provide connectivity to the mobile devices are attached, or connected to a WAN to serve more users. The MIM server offers a special Web service that exposes Web methods through which mobile devices request discovery of Internet Web services. In other words, the MIM server is logically a Web service, which allows for having a unified interface through which the devices communicate with remote processes. Moreover, we extend the functionality of the server through caching the generated proxies and storing related information that include WSDL files, source language (e.g., Java), intended platform (e.g., Symbian), and assigned time to live (TTL) value. With this, the MIM server will be able to provide already built proxies from its cache after matching the user-supplied keywords with the descriptions found in the WSDL files, thus reducing user wait times, especially for popular Web services. The operations of the system are depicted in Fig. 1, but the detailed actions can be grouped into two phases: one to locate the service, and
IEEE Wireless Communications • October 2010
10/6/10
10:51 AM
Page 83
Man-in-the middle server
Mobile device
Proxy
Text m
ARTAIL LAYOUT
Descriptions of available services (2)
(4), (7) atching
(10)
WSDL URLs (5) Generate source file (8)
Web service
Internet
Build dll (9)
Local area network
Query phrase (3)
Web server
)
(6 Wsdl files
e vi c ser b e Get w
ip scr de
n tio
s
) (1
UDDI server
Figure 1. Role of the MIM server in the dynamic invocation of web methods.
one to set up the mobile device to actually invoke the Web service method. The first phase is illustrated in the top part of Fig. 2, where steps 1 and 2 can occur offline, meaning the MIM server can download service descriptions from particular UDDI registries and cache them locally, for example shortly after the server boots up. Later, when the user submits a query on his device, it goes to the MIM server (step 4) where it gets matched (step 3) with the short service descriptions. This produces a short list of Web services with corresponding URLs (step 5) that are used to download the associated WSDL files from the hosting servers (steps 6–8). The Web method descriptions found in these files are in turn used for matching with the user’s sentence, but this time to zoom in on the most relevant Web service (step 9). The second phase is shown in the bottom part of Fig. 2. Here, the WSDL file of the discovered service is used to programmatically generate the language-specific source code of the client-side proxy (step 10) and compile it for the target platform into a class (step 11) that is uploaded to the device. Reflection is then used to get the Web method’s parameters (step 12) and correspondingly generate a dynamic GUI (step 13) to collect the user’s input (values for the method’s parameters). Finally, Reflection is used again but this time to invoke the Web method (step 14) and display the results (step 15).
IMPLEMENTATION As a prototype, the Web service client on the mobile device was implemented using the .NET Compact Framework (CF) and the C# programming language. The application was installed on an iPAQ hx 2700 Pocket PC running the Windows Mobile OS and set up to communicate with a wireless access point using wireless LAN. The MIM server was implemented on a Fujitsu Siemens laptop with a Centrino processor and 1 Gbyte of memory.
to call this method after startup and stored the returned descriptions locally. Afterward, when the submitted user query is submitted on the device, it gets matched against the descriptions on the server using the Boyer-Moore algorithm [6], which takes two strings and searches for the occurrence of one in the other. This algorithm is suitable for this type of application as it works the fastest when the alphabet is moderately sized and the pattern is relatively long. We used the user’s phrase as a pattern to be maximally found in the service descriptions after removing words like the, when, and its. A score is computed that accounts for the number of matched words between the phrase and the description, and the positions of the matches in the description. Our experiments showed that a score higher than 0.6 (out of 1) indicates a good match. The output of this process is a short list of services whose descriptions matched the input phrase. If more than five matches occurred, the user is asked to supply a more specific phrase. The next step was to obtain the WSDL files of the selected services. For each service, an HTTP request is created from the WSDL URL, and the resulting HTTP response is put into a stream, which constructs a string containing the actual WSDL file. Each of the obtained WSDL files is parsed to get the Web methods of the Web service and their documentations. First, the whole file is searched to find the word portType, then the word operation (tells the name of the Web method), and finally, the word documentation. Following this, the documentations are searched for the best match with the input phrase using the same procedure described above. The outcome of this search is one Web method that best matches the input phrase. We note that Web method descriptions are not always available, in which case the documentation field is null. In this case our approach simply uses the method’s name for comparison.
DISCOVERING WEB METHODS
PROXY CLASS GENERATION AND COMPILATION
We used the XMethods UDDI registry, which provides a service that offers a method which, when called, returns an array of summaries for all listed services. The MIM server was set up
After identifying the Web method, the proxy is built from the WSDL file and sent to the mobile device where a reference to it is added in the client application. This enables the application
IEEE Wireless Communications • October 2010
The output of this process is a short list of services whose descriptions matched the input phrase. If more than five matches occurred, the user is asked to supply a more specific phrase.
83
ARTAIL LAYOUT
10/6/10
10:51 AM
The developed application was named SNAPP, which stands for Service Navigator at Palm Proximity. The assumption is that the user does not know the name or the URL of the Web service, but has an idea of what he needs.
Page 84
Short descriptions Mobile device User input
(2)
(1)
(4)
Service summaries: names, IDs, short descriptions, wsdl URLs, publisherIDs
(9)
(3)
(8) Web servers
(5)
UDDI server (7)
Text matching algorithm
WSDL file of discovered web service
Short list of web services
WSDL files (6)
(10)
WSDL file of discovered web service
(11)
Compile into proxy class
Source file from WSDL
(15)
Displayed results
(12)
(14)
Web method invocation
(13)
Dynamic GUi and user input
Reflection to get invocation parameters
Figure 2. Phase 1 (top) and phase 2 (bottom) of the dynamic web method invocation process. with the aid of the Reflection application programming interface (API) to get the desired method’s input and output parameters, and then retrieve their names and types. Having the information about the method’s parameters, the dynamic GUI was generated. In our implementation, for every input parameter a text box and a corresponding label (using the parameter’s name) were drawn. After getting the user’s input, the method was invoked at runtime, also using Reflection, and the returned results get displayed.
EVALUATION The developed application was named SNAPP, which stands for Service Navigator at Palm Proximity. The assumption is that the user does not know the name or the URL of the Web service, but has an idea of what she needs. Once the user starts SNAPP, the initial form is
84
launched. This form has a GUI comprising a textbox into which the user can enter the phrase that represents the desired functionality. After a phrase is entered, the program displays a GUI for entering the parameters’ values for the web method to invoke. Figure 3 shows a case of a user wanting to perform currency conversion. The program determined that the most relevant web method is ConvertCurrency found in the published DOTSCurrencyExchange Web service. The method has three input parameters that are selfexplanatory. As shown in the middle image, we provide a link to the documentation of the web method if it is available in order to help the user correctly interpret the purpose and use of the input parameters. We tested our application on several input phrases while measuring the runtime and the appropriateness of the result with respect to the search phrase. We reran the application five
IEEE Wireless Communications • October 2010
ARTAIL LAYOUT
10/6/10
10:51 AM
Page 85
Figure 3. Screenshots of the application when taking the user search phrase (left), the user entering values for the input parameters (middle), and displaying the result (right).
times for each phrase in order to get average runtime values.
EFFECTIVENESS We define effectiveness as the ability of the application to give the user the needed service. For a sample of search phrases, the upper part of Table 1 indicates the matched web method and the service exposing that method. This table lists few but representative Web services from the point of view of WSDL file size, a major determinant of the performance of the proposed system. The sizes of the WSDL files of the shown services ranged between 4 and 18 kbytes. In this respect, it is worth mentioning that according to [7], the average WSDL file size for services on the Internet is close to 10 kbytes. The table shows that the requests and responses are highly correlated, which reflects the effectiveness of the search algorithm. The system gives back desired results most of the time, but when the user enters a very general search phrase, the invoked method may not meet the user’s requirements.
SPEED When the server application starts, and then periodically afterward, it downloads available service summaries from the UDDI registry. The average time it took to download and store all summaries is close to 8 s, but this delay corresponds to an offline step that does not affect the user wait time. The individual times of selected services corresponding to the online phases of the process are indicated in the lower part of Table 1. The reported times in the last row exclude the times corresponding to waiting for the user to type in the values of the input parameters. By summing the numbers in the bottom three rows of Table 1, we get the total user wait time, which amounts to less than 11 s for the shown services. We add that since the user inter-
IEEE Wireless Communications • October 2010
feres by filling in the values for the input parameters almost halfway through the process, the perceived wait time can be less than what it actually is.
SCALABILITY To evaluate the scalability of the architecture, we conducted an experiment through which the mobile devices were simulated using threads. This allowed easily increasing the load on the MIM server by increasing the number of concurrent threads that submit requests. For each request it receives from a client, the MIM server spawns a thread and runs in it code that performs tasks 2 and 3, as defined in Table 1. In the experiment the downloaded and processed WSDL files were from a collection of over 200 files that were determined a priori and whose sizes were around 4 kbytes. The number of simultaneous requests that were sent to the MIM server was increased starting from 5 until the server started dropping requests. Moreover, every single experiment was run twice, and the average was taken. The measured delay values we report are the cumulative communication time and processing time. The former is mainly the total time it took to fetch the WSDL files from web servers on the Internet, as the communication delays between the client computer that ran the threads and the MIM server were negligible. Before discussing the results, we need to point out that the MIM server, having a singlecore CPU, sent the replies (answers of the method invocations) sequentially to the client computer as they were completed. The collected results indicated that the MIM server was able to process up to 100 simultaneous requests before starting to drop requests. The results are illustrated in Fig. 4, where we notice that a threshold of 85 simultaneous requests may be
85
Send SMS SendSMSWorld
Data encryption
Remove Profanity CDYNE Profanit Filter — FREE
DOTSGeoPinPoint
IP address location
Phone number verification Phone Number Verification service
Driving directions Mapquest Driving Directions
Currency exchange DOTS Currency Exchange
Sagsagsa “No service/Web method found”
Stock prices exchange Stock Quote
Get zip code WeatherForecast
Zip code
0.9
0.6
0.6
0.7
0.6
0.6
0.8
0.7
Task 2
3.7
5.3
5.4
5.6
4.9
4.6
6.0
5.2
4.6
6.2
4.9
4.8
5.3
6.0
Task 3
5.31
7.60
6.43
8.68
2.91
3.32
3.22
3.14
3.80
5.20
7.80
Legend:
Encrypt
PhoneVerify
SimpleRoute
sendSMS
0.5
ProfanityFilter
0.6
TWS-DE
1.1
GetLocationByIP
0.8
ConvertCurrency
0.5
GetQuote
0.8
GetWeatherByZipCode
“Input phrase is too general”
Task 1
Chosen web method
“Input phrase is too general”
Weather
Weather in U.S. WeatherForecast
Page 86
GetWeatherByZipCode
Shakespeare
10:51 AM
GetSpeech
Discovered Web service
Shakespeare
10/6/10
Input phrase
ARTAIL LAYOUT
Task 1 = Generating short list of service descriptions Task 2 = Getting the WSDL files and identifying web method Task 3 = dll generation and loading, dynamic GUI, and method invocation
Table 1. Effectiveness of the application as inferred from the results in the second and third row, and times in seconds for the different steps of service discovery and invocation.
derived to ensure acceptable performance. However, with proper implementation of queuing, the server will be able to handle a much larger number of requests that may transiently arrive at the server. Finally, the right graph presents the cumulative processing times that correspond to the results in the left graph. They show that as more requests are completed by the server, increasingly less processing time is required to complete the remaining ones.
BATTERY POWER SAVINGS To get a handle on the power savings that can be attributed to the MIM server, we measured the power directly by connecting the battery to the Pocket PC externally and measuring the voltage drop across 0.375 ohm resistors placed in series between the battery and the handheld using an Agilent DSO3062A oscilloscope for capturing instantaneous voltage values. The instantaneous power consumed was then measured by multiplying the current (measured voltage divided by the resistance) and multiplying it by the battery’s fixed voltage (3.7 V). To get an estimate of the power savings that the mobile device achieves through delegating the above tasks to the MIM server, we measured the power by running similar or mock-up tasks on the device. Moreover, over 100 service descriptions and associated WSDL files were placed on a local server that took the role of the UDDI and Web servers. In conclusion, the mea-
86
sured energy spent to perform the communication and processing tasks associated with a single request was 13.64 J. To appreciate the significance of this saving, we divide it by the capacity of the HP iPAQ hx 2700 Pocket PC, which is about 19 kJ. The 1/1400 ratio states that the saving from each use represents 1/1400 of the capacity of the battery for this device type.
PRIVACY AND SECURITY The MIM server does not cache content (i.e., Web service responses) nor is it aware of the particular Web methods that the user is invoking. This eases user privacy concerns in relation to the data exchanged between him and the Web server and in relation to tracking his specific activities. As for security, encryption and server authentication can be used to protect the MIM server records and as much as possible avoid intrusive activities, like keeping eavesdroppers from learning about the interests of users.
SUITABILITY FOR RECENT PLATFORMS In this section we consider the applicability of our proposed approach to two recent mobile device platforms, Google’s Android and Apple’s iPhone. Android does not have a built-in feature for consuming SOAP-based Web services, but a third-party component such as ksoap2 can be installed on the device to provide this capability. Such a component will enable an Android client device to take part of our proposed architecture
IEEE Wireless Communications • October 2010
ARTAIL LAYOUT
10/6/10
10:51 AM
Page 87
200
200 5 clients 10 clients 15 clients 20 clients 25 clients 50 clients 75 clients 100 clients
160
Total processing time (ms)
Total communication time (s)
160
5 clients 10 clients 15 clients 20 clients 25 clients 50 clients 75 clients 100 clients
120
80
40
120
80
40
0
0 0
20
40
60
80
100
0
15
30
45
60
75
Index of finished client
Index of finished client
Figure 4. Results of the scalability experiment. and access offered Web services through MIMserver-generated Java proxy classes. In the case of the iPhone, the Core Services framework found in the Cocoa Touch iPhone SDK can be used to access Web services. More specifically, the WSMakeStubs utility can be called on the MIM server to generate proxy classes that can be sent to iPhone clients.
ALTERNATE SOLUTIONS The major vendors and standard bodies continue to build the core Web services stack around SOAP, but some favor REST [8]. In any case, our design makes migration to the REST approach quite easy. At the architectural level, one of the publicized characteristics of REST is the use of layered components, such as proxy and cache servers. The employed MIM server already plays the role of a cache server and a gateway. To start supporting RESTful services in parallel with RESTless services, which is the likely future scenario, the MIM server can simply return to the client the URL made available by the service instead of the interface to the Web service method, and skip the whole proxy generation process. By having the client recognize that the service is RESTful, it can easily be programmed to consume the service by directly sending a GET to the server. Concerning the client-side proxy generation, by default the proxy class uses SOAP over HTTP to communicate with the Web service. However, the wsdl.exe tool can generate proxy classes to communicate with a Web service using HTTP GET and POST, which is more in line with the REST style of invoking Web services. Our proposed solution compiles the proxy code generated from the WSDL file at the server and sends it to the mobile device. An alternative solution is to have the device directly
IEEE Wireless Communications • October 2010
interpret the WSDL file, which, after all, is designed to be easy to parse and interpret by a client in order to understand how to call the service. This is certainly a valid observation, but there are a few issues to consider. Table 2 compares the two approaches while referring to them as the client-stub execution and the wsdl interpretation approaches, respectively. As illustrated, the proposed approach offers certain advantages, the most important of which may be the code update and flexibility issues.
CONCLUSIONS The presented architecture makes it possible for mobile device users to dynamically invoke Web service methods that are judged by the system to match the needs of those users the most. Since the system initially identifies potential Web services, one future work would be to make use of context and location information in order to influence the Web service selection process and choose the appropriate Web methods. Moreover, Natural Language Processing (NLP) can be incorporated in order to make the process of Web method selection smarter and more representative of the user’s intent.
ACKNOWLEDGMENT The authors kindly acknowledge the generous financial support of the Lebanese National Council for Scientific Research (LNCSR).
REFERENCES [1] S. Berger et al., “Web Services on Mobile Devices — Implementation and Experience,” Proc. 5th IEEE WMCSA, 2003, pp. 100–9. [2] C. Weyer, “DynWsLib Tutorial”; http://www.thinktecture.com/resources/software/DynWsLib/default.html [3] CodePlex, “ProxyFactory”; http://www.codeplex.com/ProxyFactory
87
ARTAIL LAYOUT
10/6/10
10:51 AM
Page 88
Client-stub execution
WSDL interpretation
Comparison
Execution efficiency
The logic needed to communicate with the Web service is ready to go.
WSDL file must be parsed and interpreted at run time.
Proposed approach has an advantage, although minimal since the mechanics to communicate with a Web service are generally simple.
Client code size and bandwidth efficiency
The client receives executable code containing additional information on how to make calls over HTTP.
The client receives the WSDL file that includes method descriptions.
The code size and download speed saving/penalty may be minimal
Code complexity
Requires writing and maintaining code to reflect on the classes and understanding what to do with them.
Involves writing code to parse the WSDL file and extracting the information needed.
There may be existing libraries to interpret the WSDL file, which could make this approach easier to implement.
Client code updates
Most of the code is located on the proxy server and less or it on the mobile device.
More code is placed on the mobile client.
The proposed approach minimizes the amount of client code, and thus minimizes the need for client updates.
Platform compatibility
Compiled bytecode is platform-dependent.
WSDL file is platform-independent.
The MIM server can provide proxies for different device platforms, but this may involve extra work.
Flexibility
Thesspecific Web service interface is unimportant to the client: it reflects on the bytecode and makes the call.
The client code is dependent on the specific Web service interface, and therefore, must be updated if this interface changes.
The maintainer of the proxy using the proposed approach could find a way to tap into a new class of Web services (e.g., REST) over a new communication protocol with no changes to the client.
Security
Compiled client stubs are in the form of bytecode that is sent to the clients over the wireless network.
WSDL files are human-readable XML files.
Bytecode is harder for network intruders to read and manipulate when compared to raw WSDL files.
Table 2. Comparison of proxy class generation and direct WSDL file interpretation. [4] L. Li, M. Li, and X. Cui, “The Study on Mobile PhoneOriented Application Integration Technology of Web Services,” LNCS, Springer, vol. 3032, Apr. 2004. [5] R. Costello, “Building Web Services the REST Way”; http://www.xfront.com/REST-Web-Services.html [6] R. Boyer and J. Moore, “A Fast String Searching Algorithm,” Commun. ACM. vol. 20, 1977, pp. 762–72. [7] K. Phan, Z. Tari, and P. Bertok, “A Benchmark on SOAP’s Transport Protocols Performance for Mobile Applications,” Proc. ACM Symp. Applied Comp. ‘06, Dijon, France, Apr. 2006. [8] R. Heffner, “SOAP versus REST: A Comparison”; http://www.forrester.com/research/document/excerpt/0, 7211,35361,00.html
published over 90 papers in reputable conferences and journals.
BIOGRAPHIES
I BTISSAM E ZZEDDINE (
[email protected]) graduated as a computer and communications engineer in 2007 with high distinction from AUB. She is currently a graduate student in the ECE department at the University of Illinois at Urbana-Champaign.
HASSAN ARTAIL (
[email protected]) worked for 11 years in developing software systems for vehicle testing applications at the Scientific Labs of DaimlerChrysler before joining the Electrical and Computer Engineering Department at American University of Beirut (AUB) in 2001, where he is currently an associate professor. He is doing research in the areas of mobile and Internet computing, as well as wireless networking. During the past seven years He has
88
HAIDAR SAFA (
[email protected]) worked for ADC Telecommunications and then SS8 Networks before joining the Department of Computer Science at AUB in 2003. He is now an associate professor doing research in mobile and wireless networks, quality of service, plus routing, and network security. R AWIA A BDEL S AMAD (
[email protected]) graduated as a computer and communications engineer in 2007 with high distinction from AUB. She is now working for Booz Allen Hamilton as a system analyst.
OMAR ABOU FARAJ (
[email protected]) graduated as a computer and communications engineer in 2007 with distinction from AUB. He is working with the consulting firm OC&C as an associate consultant.
IEEE Wireless Communications • October 2010
