Enterprise Software

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

Joe McKendrick says the issues between Rich Internet Applications (and mashups) and the Service-Oriented Architecture-based infrastructure need to be resolved because these issues represent the path of least resistance to service orientation.

 

This is a guest post from Joe McKendrick of TechRepublic's sister site ZDNet. You can follow Joe on his ZDNet blog Service Oriented, or subscribe to the RSS feed.

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.

2 comments
Tony Hopkinson
Tony Hopkinson

What did you say this guy's name was Dr Obvious? SOA to be a vaguely sensible must be UI agnostic. RIA to cope with stateless HTTP usually ends up with way too much service logic in it. So the solution is to move it into another layer? RIA over HTTP is convenient, it's the financial path of least resistance. This is turd polishing, nothing else, and I can assure you turd polishing is far from new. Concilliator model, sheesh.

Justin James
Justin James

Personally, I see no techinical reason for this conflict; it is entirely cultural. Maybe the real issue at play, is that the folks who are writing RIAs are addressing entirely different issues, with a different audience, and a different scope, and probably a different mindset fromt he folks writing SOA stuff? J.Ja