From the first days of Rich Internet Application (RIA) technology, many enthusiasts found an analogy between RIA and service-oriented architecture (SOA). Some of them talked about the benefits of a would-be-wonderful use of SOA in RIA; others saw RIA as a SOA face. Nonetheless, there are experts who see a discrepancy between RIA and SOA concepts.

The major disagreement between RIA and SOA is in the fine-grained operations in RIA and the coarse-grained type of interfaces of SOA business services. Let's take a closer look at this problem.

In a glance we can see that the RIA spectrum is wide. It includes applications with interfaces for information reporting, modifying predefined business data, collecting and inserting new data into the systems, fast and frequent exchange of information in social/community-oriented Internet applications, and setting commands in the processing systems. Depending on the task, RIA might require a frequent and fine-grained information exchange between an RIA client, such as a browser and a RIA application that is deployed on the server. At the same time, the RIA client can perform relatively coarse-grained interactions, e.g., display Web content of large size. In all cases, we can assuredly say that RIA emphasizes the user interface (UI), which means that RIA has to meet UI requirements such as:

• Human comprehensive information exchange
• Information representation/report
• User operational tooling for the systems
• User experience requirements

At the same time, the "application" part of RIA remains foggy. This creates an impression that the "application" part exists either to serve the interface, which is a bit strange (interface to what?) or the "application" part is the interface itself and somebody else has to provide for support of the end-user operations in the interface.

We also know that SOA business services represent business model services, business functions, business features, and business processes. All these entities operate on smaller or larger sets of business data. Business services implement business logic and provide access to business functionality and resources and result in real-world effects (RWE). Thus, SOA business services are supposed to meet business functionality requirements comprising:

• Business logic
• Business resources
• Business data processing

To meet these requirements, business services have to provide relatively coarse-grained interfaces. Moreover, to minimize difficulties caused by change management support and simultaneously allow for reuse, the service interfaces have to become a kind of pipeline, which only strengthens the coarse granularity.

Thus, RIA and SOA business services have two major discrepancies - approach to the granularity and no shared requirements. This means that "would-be-wonderful use of SOA in RIA" requires proof.

Figure 1 illustrates a scenario in which RIA screen widget events originate RIA requests. Depending on the application, they may be more or less fine-grained. If such requests directly contact the points of invocation of SOA business services (service clients), then two inefficiencies happen:

• Business service interfaces and returned data get unutilized, reducing the power and defeating the purpose of the SOA business services
• Business services have to be called much more frequently than they could be with adequate interface usage; this also overwhelms communication channels/network

• Direct RIA + Google App Engine = Simplicity + Scalability