With the recent release of Flash MX 2004 Professional Edition and the SOAP support built into Flash Player some are questioning whether Flash Remoting has become obsolete. Indeed, it appears that Macromedia did not do anything to enhance the Flash Remoting feature, but instead made a significant stride to beef up support for SOAP Web services. The noticeable presence of the WebServiceConnector component, as well as the API for programmatically invoking Web services, makes a lot of developers wonder whether Flash Remoting is overshadowed by SOAP now. Anyone familiar with both approaches will admit that the core difference between them would be performance, though products such as FlashORB add a variety of features that significantly enhance the Flash Remoting approach. This article analyzes the results of a set of benchmark tests designed to demonstrate the performance differences between SOAP and Flash Remoting.

Test Setup
The tests were designed to demonstrate system performance for transferring simple type, complex type, array of simple types, and array of complex types. Additionally, a set of tests was included in which a combination of the above listed types was transmitted in the same test run. Each test was executed first against the SOAP service and then against a Flash Remoting service. While a test was running, the benchmark client measured the performance of the client/server communication and reported results like "total message throughput" and "number of messages per second". The same class was exposed as a Web service as well as a Flash Remoting service. FlashORB was selected as the Flash Remoting hosting server and Apache Axis was selected for the SOAP tests.

Server-Side Service Class
The server-side service class includes a set of methods corresponding to each type of test:

• echoString: This method accepts a string object argument and returns the same string object.
• echoInt: This method accepts a primitive integer argument and returns the same value.
• echoPerson: This method accepts a data structure representing a person. Each data structure has a set of fields. The method then returns the same object received as an argument.
• echoPersonArray: This method accepts an array of Person objects and returns the same array.
• echoArray: This method accepts an array of string objects and returns the same array.

Benchmark Client Application
The benchmark client application consists of five sections, each corresponding to one of the methods in the remote service. Each section has one or more fields to configure the argument(s) for the appropriate method. For example, the "echo Int" section has a text field where the number for the argument can be entered. The "echo Person Array" and "echo String Array" sections use the values from the "echo Person" and "echo String" sections for the actual data, but they also contain a field where the array size can be entered. Each section has a checkbox, which if selected, specifies that the method should be executed in the test run. This way you can easily select the methods that should be invoked in a test. At the bottom of each section, there is a test summary area. The "Messages Total" fields provide information about the number of messages sent and received during a test. The "Messages/ Second" fields automatically calculate the throughput for the running test. At the very bottom of the client UI, there are two buttons responsible for starting a test. The "Test Duration" field can be used to set the duration of the test.

Only one test can be executed at a time - once a test is started, no other test can be executed. The recommended approach is to run one type of a test first (SOAP or Flash Remoting) and once it completes, execute the other type of the test for the same test duration and method selection.

Client Design
The client application contains an invisible movie clip (invoker) responsible for running a test. In the first frame of the invoker movie clip, 2 proxies are created: one for the SOAP Web service and the other for the Flash Remoting service (see Code II).

As soon as one of the buttons kicks off a test, button click handler delegates the execution to the second frame of the invoker movie clip, which checks the methods that should participate in the test. For each selected method an operation is added to an array. (See Code III. Code III and IV are available at www.syscon. com/mx/sourcec.cfm.)

Once the servicesToCall array is set up, the Invoker movie clip enters a tight loop (frames 3 and 4). The code continuously invokes methods on the remote service (SOAP or Flash Remoting), until the time in the test duration elapses (see code IV). Frame 4 of the Invoker movie clip sends the control back to frame 3 to repeat the entire sequence until the test is complete.

Tests Results
A number of tests were executed to identify the performance of each approach. The tests (and the client application) are designed to demonstrate raw performance of transferring a homogenous data type (primitive, complex, or array) or a combination of data types. Each message invoked on a remote service includes both transferring an argument to the service (serialization) and receiving the same object as a response (deserialization). A description of each executed test with the produced results can be found in Table 1. Each test was executed with the client and server on the same computer to avoid network latency. However, this could have impacted the results since both client and server compete for the same CPU and memory.

Benchmark Observations
The Flash 7 SOAP implementation has a significant memory leak. The duration of each of the executed tests was set to 60 seconds. During the execution of a test, the memory allocated by the browser (IE 6.0) increased between 400% (echoInt test) and 1700% (echoArray test).

Tests passing just primitive arguments or strings had comparable performance for SOAP and Flash Remoting approaches. This can be explained by the rather simple format of the on-the-wire SOAP messages for these data types. As the complexity (and size) of the SOAP messages increases, the performance significantly drops. For example, the throughput of passing an array of 20 elements (each containing a Person object) is 7.22 times higher with Flash Remoting than with SOAP (65 messages/second vs 9).

The SOAP approach experienced a close-to-failure condition with a very large array of strings (2000 elements). Throughout the test, the browser process became very sluggish and nonresponsive, resulting in a throughput of less than 2 messages per second. The Flash Remoting approach carried out the same test significantly better, with an average throughput of 20 messages/second.

Test Conclusion
Macromedia has done an outstanding job of making its SOAP integration as simple as possible. Our experience using the Web services APIs was very positive. However, there are several drawbacks in the current Flash Player SOAP implementation. The most noticeable drawback is the memory leak, which makes the approach impractical. The Flash Remoting approach is by far more stable and has better performance. The SOAP approach results in larger payloads and greater CPU processing, resulting from the XML Schema validation and XML parsing. The Flash Remoting approach benefits from a binary representation of request/response as well as the invocation- batching feature. For any application that requires moderate to high remote invocation volume and/or that involves complex data types and large arrays, Flash Remoting is a better fit.