Browser Incompatibilities
Challenge #1: Reporting requires complex UI programming, but maintaining browser-specific code is a huge effort. Optimizing code delivery is an art. Optimizing data delivery isn't easy because it needs to support ever-changing protocols (SOAP, REST).

Solution: Flash Player is a virtual machine that works the same way in every browser

Challenge #2: Code packaging (in Internet Explorer Web Services are packaged as HTC, which is not supported by Mozilla browsers.

Solution: Use a browser-agnostic invisible Flash Player-based agent that supports communications with Web Services regardless of the Web browser you're using.

Performance
Challenge #3: Large JavaScript projects such as reporting applications need to be loaded, pre-processed, and executed on every page load

Solution: Use Flash agents that are pre-compiled, compressed, and optimized for streaming and caching.

Robustness
Challenge #4: The HTTP protocol is very forgiving because it was optimized for non-reliable networks. Web browsers were designed to display whatever has arrived with a Web page. If a page includes an image, which was not available at the moment, you'll see an icon of the broken image, and, maybe an alternative text. But what if a piece of JavaScript code doesn't arrive for whatever reason?

There's no built-in way to ensure the delivery of JavaScript. This means that AJAX programmers have to write additional code just to check if the application code has arrived. On top of this, Web browsers offer mediocre debugging support.

Solution: Use a virtual machine with reliable code delivery and good development and debugging tools.

Web Browsers Have an Unpredictable Future
Challenge #5: Software vendors don't seem to be eager to invest into browsers. Microsoft is investing in .NET (WPF) and Silverlight, which runs on CLR. Adobe is developing AIR. Sun Microsystems is about to release a small consumer VM for rich Internet applications written in Java and JavaFX.

Solution: Select a ubiquitous technology (currently it's Flash Player) that offers a solid development and deployment environment.

I've listed some major challenges that any RIA developers would face regardless of what protocol they use for data delivery. Recently, our company, Farata Systems, which was working mainly with Flex/Java applications, decided to create a version of our ClearBI reporter as a component for AJAX applications as well. After experimenting with various protocols, we created a component called WebService.swf, which is a Flash Player and can easily turn a SOAP Web Service into an object with methods that correspond to WSDL operations, and the XML processing is done using ECMAScript for XML (E4X), which lets you avoid XML parsing headaches

Figure 1 shows an HTML/JavaScript application that uses an invisible Flash Player component (WebService.swf) and one visible (ClearBI.swf). In this example we'll use the data coming from a publicly available book search Web Service off Amazon .com.

The entire process works like this:
1.  The JavaScript code gives a URL of Amazon's WSDL to a hidden WebService.swf.
2.  The WebServices.swf loads WSDL from Amazon and automatically converts XML into an object with properties (it uses E4X as will be explained below).
3.  The JavaScript asks WebService.swf to call the selected operation from Amazon's WSDL.
4.  WebService.swf gets the data and passes them to JavaScript (XML or JavaScript objects). If you're just interested in simplified processing of SOAP in your AJAX application, you don't need to do step 5 - WebService.swf is all you need.
5.  To produce reports that look as shown below and can be customized by the end users, pass the data from JavaScript to ClearBI swf.

What's Under the Hood
The entire workflow consists of two major steps described below: (Figure 2)
1.  Using JavaScript initialize the WebService.swf object, register event listeners, and load the WSDL:

Var ws=com.farata.jsfx.WebServices("MyWebService");
Add the WSDL load listener
ws.addEventListener("serviceload", onWsdlLoaded);
Add the error listener

ws.addEventListener("servicefault", onError);
Initialize the WebService.swf with wsdl. Load wsdl and notify ServiceLoadListeners on success.
ws.useService("http://soap.amazon.com/schemas2/AmazonWebServices.wsdl", "Amazon");

This call will load Amazon's WSDL, which among other things will contain the operation KeywordSearchRequest:

<wsdl:message name="KeywordSearchRequest">
<wsdl:part name="KeywordSearchRequest" type="typens:KeywordRequest"/>
</wsdl:message>

As you can see, this operation expects an argument of a KeywordRequest type that is described in the same WSDL:

<xsd:complexType name="KeywordRequest">
<xsd:all>
<xsd:element name="keyword" type="xsd:string"/>
<xsd:element name="page" type="xsd:string"/>
<xsd:element name="mode" type="xsd:string"/>
<xsd:element name="tag" type="xsd:string"/>
<xsd:element name="type" type="xsd:string"/>
<xsd:element name="devtag" type="xsd:string"/>
<xsd:element name="sort" type="xsd:string" minOccurs="0"/>
<xsd:element name="variations" type="xsd:string" minOccurs="0"/>
<xsd:element name="locale" type="xsd:string" minOccurs="0"/>
</xsd:all>
</xsd:complexType>