With Objects, App Components Ready for SOA, Data Is Next on Tap

With Objects, App Components Ready for SOA, Data Is Next on Tap
By Edward J. Correia

June 1, 2006 — As developers become comfortable with the standards for dividing applications into interoperable services, SOA tool makers are turning their attention to the data layer, and working to standardize ways of assembling SOA components into versatile composite applications.

With the innumerable data sources that developers are likely to encounter—the number is growing literally every day—it will become increasingly difficult to hand-code the connections and virtually impossible to maintain them.

According to Ted Friedman, a Gartner research vice president, the emergence of SOA will mean that “data is going to be consumed by more and different applications and people, unlinking it from the silos.” It therefore needs to be portrayed in more and different contexts with a greater rate of change.

Such is the realm of SDO, the specification for Service Data Objects developed by BEA Systems, IBM, Iona Technologies and others. The multilanguage spec, available now for C++ and Java, applies the concept of disconnected data graphs to allow access and manipulation of data to and from relational, XML and other disparate sources.

Applications that access such data services will be easier to create and far less fragile, said Friedman. “SDO is one way to put some standardization around the idea [of data access],” he said.

BEA has supported SDO since the December release of Aqualogic 2.1, the latest version of its SOA integration platform.

“We see a growing need to be able to put information from [diverse sources] into a unified view,” said Paul Patrick, chief architect of Aqualogic. He said that in Aqualogic, BEA had devised a federated scheme to extract, normalize and present a unified view of data, but lacked the means to post changes.

“The front end has no idea where the data came from. That’s where SDO came in,” he said. “It offers a standardized approach to doing an intelligent update” by keeping track of data sources and returning changes when appropriate and ignoring the rest. “SDO gave us a way to know [what] needed to change and where.”

A related specification that defines a Service Component Architecture for assembling composite front-end applications is under development by many of the same companies, but has yet to reach its first release.

“The value of SCA is in how it puts services together for a common deployment model,” said Eric Newcomer, CTO of Iona, which is a leading driver of SCA. He characterized SCA as a critical specification for SOA’s assembly model. “Like any distributed application, the purpose of SOA is to share data and make access to data transparent. SCA tells services how to get composed into larger systems.” Now at 0.9, SCA is expected to reach version 1.0 by September, Newcomer said.

The initial focus of SOA development, Newcomer continued, was on objects and applications. “And we’re doing a pretty good job with that. Now we need to focus on getting data sources involved,” he said. Still, Iona’s Artix 4 ESB platform does not yet support data access methods described in the SDO spec. “SQL databases are what our customers need to access most,” he said.

SCA will be incorporated in the Eclipse SOA Tools Platform (STP) project that Iona proposed last September. “Eclipse is where [SCA and SDO] come together,” said Newcomer. “SCA relies on SOA metadata, and we see those coming together under one umbrella.” The next major release of STP is set for July or August.

EMAIL THIS ARTICLE

SEND FEEDBACK