SOAP AND CORBA PRODUCTIVITY COMPARISON FOR RESOURCE-LIMITED MOBILE DEVICES

Dr. Eugene A. Gryazin, Industrial IT Laboratory,

Helsinki University of Technology, PL9204, 02015, TKK,

Espoo, Finland eugene.gryazin@hut.fi

M.El.Eng. Olli Seppala Industrial IT Laboratory,

Helsinki University of Technology, PL9204, 02015, TKK,

Espoo, Finland olli.seppala@hut.fi

ABSTRACT This article is a deep analysis and comparison of CORBA

and SOAP/Web Services as two middleware solutions for resource limited mobile applications. The main parameters of these protocols are measured and classified for easy understanding of advantages and disadvantages in the mentioned solutions for lightweight Communicator-type mobile devices in highly distributed wireless systems.

KEY WORDS

Middleware, CORBA, Web Services, SOAP, XML, Communicator.

1. Introduction

There is considerable interest in Middleware among the distributed and mobile software community. The market of middleware has grown exponentially and, by various estimations, the tendency will continue (Gartner Group. David McCoy “Application Integration and Middleware at the Crossroads”, 19 December 2001, AV-15-1027). Currently, there are many middleware platforms and tools on the market. Different technologies and approaches are used to simplify application-to-application and application-to-user interaction (the main idea of middleware). In this article, it is sought to compare the two big players in the mentioned field, Common Object Request Broker Architecture (CORBA) [2,6,8] and Web Services Technology frequently referred to as SOAP (according to the protocol name – Simple Object Access Protocol) [1,9]. Much effort has been made for integrating both these technologies [3,5], but still many developers and system analysts spend great amounts of time to choose one of them for particular system implementations. The Java language was chosen as the comparison programming tool as it is a flexible, interoperable and interplatform means for working with different hardware. Mobility of the tested devices was supplied by GSM/HSCSD connections on Communicator telephones and High Speed GSM Wireless PCMCIA cards.

2. Objective and Scope

Objectives of this article are to determine the protocols’ processing speed for wireless limited resource channels, like GSM etc. The amount of data transfers and traffic activity serve as crucial points and supplying these variables by optimal means operator can reach better results and better satisfy customers. The servers for these tests were Intel processor based PCs and the wireless clients (for one and two client environment) were Nokia Communicator 9210’s with GSM/HSCSD connections. All test data presented was randomly generated string sequences based on number of sequence. Measurement made for three parameters: exact time of transmission (after protocol initialization), amount of characters transmitted (effective payload), full data transmitted (overall payload). For the multi-client tests (3-5-7-10 clients on notebook PC through wireless channels) only minimal and maximal timing results were collected. Also the interoperability of different protocol implementations is tested (CORBA and SOAP from different sources). This article is extends and completes initial results which was described in [10]. Additional experiments are provided and more analyses done. Protocol usability recommendation and dependencies are revealed.

3. Methodology

This section includes the methodological approach behind tests of each phase of the experiment. Three different test environments were established: one-to-one connection using wireless methods from both sides (see fig. 1), two clients to one server connection using wireless connection from both sides (see fig. 4) and multi-client connection to one server than server is normally connected with cable (100Base-T) and clients located at wireless connected emulation notebook (shared channel) (see fig.6).

3.1 Tools and Equipment

Hardware: - Intel PIII-700 with 256M RAM and Windows 2000; - IBM ThinkPad 600X with Windows 2000;

418-809 707

- Nokia GSM RPM-1 Wireless PCMCIA card; - Nokia Communicator 9210 – 2 pcs.

Software: - JDK for Windows version 1.3.1; - Java for EPOC 6.0 version 4.13; - Borland JBuilder 6.0 with Mobile Set; - Etherial – Network Protocol Analyzer version 0.9.6; - CORBA: JacORB version 1.2 (as server middleware), IONA Technologies Orbix/E version 2.0.0 (as client middleware); - Web Services/SOAP: Apache Tomcat 4.0.1 with Axis and Xerces (as server), Wingfoot SOAP version 1.02 (as client).

3.2 One-to-One Case

The server was connected to the network via a GSM/HSCSD channel (upstream was 28.8 Kbit/s, down stream was 28.8 Kbit/s). On the server-side, both SOAP and CORBA server applications were started. On the client, test applications were started one by one. The test environment is shown in Fig.1.

Fig. 1. One-to-One test environment structure.

A protocol analyzer was used during the operation of the test applications on the server to gather all data packets for overall traffic analysis. Every protocol (CORBA and SOAP) test consists of two parts. The first is a “short” test, where a pseudo-random string is requested. The second is a “long” test, where the test data is derived by repeating the short test generation 10 times. For both tests, the pseudo-random string is generated based on the request number, and the length of string is from 1 to 255 randomly generated characters. A total of 10 iterations of each test are carried out, recording the total amount of time and the total amount of characters transmitted during testing. For evaluation, these times are divided by 10 to represent the average individual test time.

Test Parameters

Two basic types of parameters are measured in the current scenario for protocol comparison. Main

consideration was given to major parameters such as: - time of procedure call (total time for 10 calls); - amount of character transmitted during test (total for all 10 calls); - total amount of data (in Kbytes) transmitted during the test (summarized in all 10 calls); - average request and response sizes for different protocols.

Minor parameters were parameters: - size of system libraries for mobile device; - installation packet size for mobile device.

Test Scenario

Web Services/SOAP

In the SOAP case, the test method was similar to CORBA, both a short and a long test repeated 10 times each. To simplify evaluation, some parameters (due to pseudo-random Java specific) were fixed in identical value. Namely, the amount of characters transmitted during the test (effective payload) was set to 1108 in one test iteration (ten procedure calls) for the “short” test, and 284739 characters in one test iteration (ten procedure calls) for the “long” test. The total amount of data transmitted during the test for the “short” case is 16Kbyte, and for the “long” case 581Kbytes. The average request size for a SOAP packet is 469 Bytes, and the average response size for a SOAP packet is 599 Bytes. The size of the Wingfoot system library is 32K and installation package size for SOAP application for Communicator built with Mobile Set for Borland JBuilder is 9074 Bytes. And finally, Table 1 shows minimal, maximal and average times for the “short” and “long” SOAP one-to-one protocol tests.

Table 1. Timing measurements for SOAP one-to-one case

SOAP “Short” case “Long” case

Minimal time, msec 38156 316515

Maximal time, msec 62172 317172

Average time, msec 39849 316860

Screenshot from Communicator after the next SOAP test completion is shown in Fig. 2.

CORBA

The same test arrangement as was used for SOAP was applied to CORBA, every test was made by ten times both as “short” and as “long”. Identical parameters were measured; the amount of characters transmitted during the test (effective payload) was set to 1109 in one test iteration (ten procedure calls) for the “short” test, and 284740 characters in one test iteration (ten procedure calls) for the “long” test. Total amount of data transmitted during the “short” test case was 2.59Kbytes, and for

708

“long” case 570Kbytes. The average request size for a CORBA packet is 21 Bytes, and the average response size for a CORBA packet is 33 Bytes. The Orbix/E system library is 746K in size and installation package size for CORBA application for Communicator built with Mobile Set for Borland JBuilder is 22906 Bytes. Table 2 shows the minimal, maximal and average times for the “short” and “long” CORBA one-to-one protocol tests.

Fig. 2. Finished “short” SOAP test at mobile device.

Table 2. Timing measurements for CORBA one-to-one case

CORBA “Short” case “Long” case

Minimal time, msec 13980 196906

Maximal time, msec 23140 198578

Average time, msec 14427 197781

Screenshot from Communicator after the next CORBA test completion is shown in Fig. 3.

All constant experiment parameters are shown in Table 3 (for SOAP and CORBA tests).

3.3 Two-to-one Case

For the second test, the server was connected to the network via a GSM/HSCSD channel (upstream was 28.8 Kbit/s, downstream was 28.8 Kbit/s). On the server-side, both SOAP and CORBA server applications were started. On the two Communicators, the test applications were started. Structure of this test environment is shown in Fig.4.

Fig. 3. Finished “short” CORBA test at mobile device.

The testing application on each client was started simultaneously and results collected from them and from protocol analyzer, which gathered all data packets for

overall traffic analysis. The complete test infrastructure with server and test devices is shown in Fig.5.

Table 3. Constant test parameters for all SOAP and CORBA test cases

SOAP CORBA

Effective payload “short”, chars 1108 1109

Effective payload “long”, chars 284739 284740

Total payload “short”, Kbytes 16 2.59

Total payload “long”, Kbytes 581 570

Request size, byte 469 21

Response size, byte 599 33

System lib. size, Kbytes 32 746

App. Pack. size, byte 9074 22906

For both protocols (SOAP and CORBA) the “short” and “long” test cases were used with simultaneous application starting. The flow of experiment followed that of the one-to-one case and allowed verification of one server channel sharing among two wireless applications.

Test Parameters

As in the one-to-one test case, two types of parameters were measured for protocol comparison. All parameters were checked according to same methodology as in previous tests.

Fig. 4. Two-to-One test environment structure.

Fig. 5. Test environment organization for two-to-one test case.

709

Test Scenario

Parameters collected in Table 3 are also topical for this test case, but if we examine channels from client point of view. Server total payload is multiplied by 2 for “short” and long cases. Due to this fact and because the clients share the same wireless server, the channel use times of the current experiment show increases. Minimal, maximal and average times of SOAP and CORBA protocols in two-to-one test cases from both clients are shown in Table 4.

3.4 Multi-client-to-single Server Case

Last test case was conducted under different conditions than the previous two. The server was moved to a standard PC connected to the Internet via a 100 Mbit/s wired network card. Client(s) had connections with the network via GSM/HSCSD channels (upstream was 28.8 Kbit/s, downstream was 28.8 Kbit/s) organized on a notebook with a Nokia PCMCIA GSM card. The server hosted both SOAP and CORBA server applications as well as the protocol analyzer software. The client hosted 10 virtual client applications using emulator software. Fig. 6 shows the test configuration. The aim of this test was´to examine the possibility of protocols to share channels among many clients, and the behavior of load-balancing capabilities for server software during work with “thin” channel clients. This test generated a trend line which shows the tendency of protocol bandwidth consumption. Due to the number of clients in one wireless channel, only the “short” test was executed for this test scenario.

Table 4. Timing measurements for CORBA and SOAP in two-to-one test case

SOAP “short”

CORBA “short”

SOAP “long”

CORBA “long”

Min time, msec 38828 14516 451016 358984

Max time, msec 41563 16172 505938 360570

Average time, msec 40697 15082 497627 359548

Test Parameters

Main constant test parameters stay the same as mentioned in Table 3, with indication of the number of clients and total payload for server and one physical client notebook channel which is shared between all virtual clients.

Fig. 6. Multi-client-to-single server test environment structure.

Test Scenario

Tables 5 (SOAP) and 6 (CORBA) show the timings for 3, 5, 7, 10 virtual clients working with “short” test via one wireless GSM/HSCSD channel. Minimal and maximal times of virtual clients presented in those tables. For each protocol, there were three trial experiments.

Table 5. Timing measurements for SOAP in the multi-client-to-single server test case

SOAP Min/Max 3 clients 5 clients 7 clients 10 clients

Min, msec 25717 30323 38846 52276

1

Max, msec 26548 31705 40578 59507 Min, msec 22993 34300 37304 51604

2

Max, msec 23727 37805 38636 54478 Min, msec 25767 30935 37564 51264

3

Max, msec 26208 32717 39256 56472

Table 6. Timing measurements for CORBA in the multi-client-to-single server test case

CORBA Min/Max 3 clients 5 clients 7 clients 10 clients

Min, msec 7641 13369 15205 14421

1 Max, msec 7792 15122 16607 18166

Min, msec 7531 10415 13569 14952

2 Max, msec 8132 13519 14269 16271

Min, msec 7941 11316 13119 13910

3 Max, msec 8352 13592 14641 16283

710

4. Results Analysis & Evaluation

Table 7 shows the average results collected in the first two tests and total minimal-maximal of the third test.

Graphic presentation of results is shown in Fig.7, 8 and 9. Fig.7 shows the “short” case for one-to-one and two-to-one experiments. Fig.8 shows the “long” case for one-to-one and two-to-one experiments.

Table 7. Average timings for all three test cases

Test 1 (one-to-one), sec

“Short” “Long”

SOAP 39,8 316,9

CORBA 14,4 197,8

Test 2 (two-to-one), sec

“Short” “Long”

SOAP 40,7 497,6

CORBA 15,1 359,5

Test 3 (multi-client-to-single server), sec

3 5 7 10

Min 22,993 30,323 37,304 51,264 SOAP

Max 26,548 37,805 40,578 59,507

Min 7,531 10,415 13,119 13,910 CORBA

Max 8,352 15,122 16,607 18,166

Fig. 9 demonstrates the final multi-client-to-single server experiment for the “short” case. The CORBA trend is asymptotic line type and SOAP trend is exponential line type. These graphs mean that in critical conditions (overloaded channels) CORBA will manage with bandwidth distribution better than SOAP.

Another important parameter in all these experiments is speed of transmission (as effective as total). Table 8 shows the calculated average effective and total speed using data from Table 3 and Table 7.

It is necessary to remark that the physical limitation of the channel is 2TX+2RX (most efficient mode for HSCSD), meaning that 28.8 kbps is reserved for upstream and 28.8 kbps for downstream traffic. And that one character is represented by two bytes (16 bit Unicode). Also in two-to-one case amount of data coming from server doubled because server sent responses to two clients, which means the speed of the Communicator-side application is slightly lower than in the one-to-one case, while the speed of the same channel from server side (wireless GSM/HSCSD card) is greater. This speed is shown in table 7.

05

1015202530354045

SOAP CORBA

Protocol

Tim

e, s

ec

One-to-oneTwo-to-one

Fig. 7. SOAP and CORBA trends for one-to-one and two-to-one “short” experiments

0

100

200

300

400

500

600

SOAP CORBA

Protocol

Tim

e,se

c

One-to-oneTwo-to-one

Fig. 8. SOAP and CORBA trends for one-to-one and two-to-one “long” experiments

For multi-client-to-one server is calculated slowest speed (with maximal time for correspondent number of clients).

0

10

20

30

40

50

60

70

3 5 7 10

Clients number

Tim

e, s

ec

SOAP MaxSOAP MinCORBA MaxCORBA Min

Fig. 9. SOAP and CORBA trends for different client number with one wireless channel

711