X
Business

Conflict between Rich Internet Apps and SOA? Say it isn't so

SOA is too coarse-grained, while RIA is too fine-grained
Written by Joe McKendrick, Contributing Writer

Okay, it's well documented that the worlds of SOA and Web 2.0, while increasingly overlapping, have operated in parallel dimensions. SOA preaches 'worry about the business, and the technology will follow,' while Web 2.0 preaches, 'get into the technology, and the business will follow.'

Still, the headline "Resolving RIA-SOA Conflict" is an eye-catcher, especially since we're counting heavily on these two methodologies to get along and perform in unison. Rich Internet Applications are potentially part of that "last mile" between SOA-based infrastructures and client endpoints.  They are the foundations of simple, lightweight front-ends and mashups that are becoming so popular, and are enabling business users to get in on the SOA action with their own rapidly deployable composite applications.

In a recent article, Michael Poulin points out that the issue between SOA and RIA is that they often differ too widely in granularity. "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."

SOA and RIA projects often see a "mismatch in objective requirements, granularity, and data formats." That's because the "RIA spectrum is wide," Poulin says. RIA encompasses 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."

Poulin proposes an "RIA-SOA collaboration design pattern" to resolve the discrepancies between RIA and SOA.  This pattern involves the use of a "conciliator module" between RIA requests and SOA business service interfaces. The conciliator module "bridges business functionally provided by SOA business services and business user interface functionality," while supporting the delivery of data to and from RIA-based widgets.

It's urgent that any issues between RIAs (and mashups) and the SOA-based infrastructure be resolved, as this now represents the path of least resistance to service orientation.

Editorial standards