News

Should RIA Developers Shift to Service Orientation?

• By John K. Waters
• July 29, 2008

According to XAware founder Kirstan Vandersluis, developers of rich Internet applications (RIAs) should shift their thinking toward service orientation to give their apps the benefits of reusability and business agility -- qualities typically associated with service oriented architecture (SOA).

"It has been argued that, in SOA terms, a service is a very specific thing that would exclude the kinds of granular services an RIA would call," Vandersluis said. "I'm not currently buying into that line of thinking. There are going to be at least an order of magnitude more services written for RIAs than there are services more for traditional, mainstream SOA applications 000 something that would feed business processes. Why wouldn't you want the benefits that we talk about for SOA in RIAs?"

Vandersluis is the founder and chief science officer of his open-source, Colorado-based company. XAware aims to simplify the complexities of data integration with technology that provides a data-services layer. That layer makes it possible to create a service that executes distributed queries across multiple data sources. The resulting integrated views, which are formatted as XML, can then be consumed and manipulated more easily by Web 2.0 dashboards, applications, and other integration infrastructure components, such as ESBs and XML query-and-reporting tools.

Vandersluis hosted a technical session at the recent O'Reilly Open Source Convention in Portland, Ore., entitled "Creating Data Services Mashups for SOA & Web 2.0." He showed a standing-room-only crowd how to create data-services mashups by tapping multiple data sources, conforming them to an XML schema, and then exposing them as services.

"We feel that one of the inhibitors to SOA all along has been the lack of data at the right level of granularity," Vandersluis told this reporter in a post-session phone interview. "SOA is all about providing data at the proper level of granularity. With a data services layer, you can construct your services at the right level to supply your orchestration layer, so that your processes now look a lot more like something a business analyst can understand. Long term, that's what's going to allow SOA to work properly."

Vandersluis said he believes the ability to build RIAs would be enhanced if the base data services layer is more service oriented. But he allows that service-oriented developers and RIA builders tend to come at their work from opposite ends of a broad spectrum.

"On the RIA side you see screen-driven development," he said. "The developer has to show a customer view, for example, that includes his name, address, and recent order history. So they have a tendency to think about getting data quickly, and don't bother me with process. I'm not going to my Center of Excellence to find out where to get a customer address."

Meanwhile, the needs of the business tend to drive SOA. "I think typically it's driven by some smart architects or people on the IT side trying to align better with the business," he said. "They're thinking more about driving the business into IT, so naturally you're going to get more governance related requirements falling out of that. You're going to want to manage those services so to make sure that they're not replicated. But the RIA developer isn't going to care so much whether somebody else is calling a GetAddress service."

Vandersluis commented that a lack of good governance tools is one inhibitor of the development of more service-oriented RIAs. "The whole governance realm would get an allergic reaction from an RIA developer," he said.

Better tools for metadata management and traceability would help RIA developers to embrace service-orientation, Vandersluis suggested. "If we can make that automatic and transparent, then that would remove one inhibitor to an RIA guy using more SOA-style technologies."

"Maybe there's some middle ground where a couple of related sections on the screen map to a data service," he added. "The idea would be to drive reusability of that service. But both sides should be driving towards commonality, reusability and agility."