OASIS Ramps Up SDO Efforts for SOAs
The standards group formed a technical committee to foster the Service Data Objects specification, an approach for handling data in service-oriented architectures
The nonprofit OASIS standards group has created a technical committee in support of the Service Data Objects (SDO) specification at OASIS. The SDO spec, which is a subset of the Service Component Architecture (SCA) spec, aims at simplifying data handling in service-oriented architectures (SOAs).
The advantage of implementing the SDO spec is that developers aren't tied down to specific data types or frameworks in an SOA, according to advocates for the standard.
"By offering a common facility for representing collections of data -- regardless of data source type -- SDO gives application developers a more simple, unified programming model and enables tools to work across heterogeneous data sources consistently," stated IBM's Shawn Moe, convener of the OASIS SDO Technical Committee, in a prepared statement.
According to a white paper (PDF) by the Open SOA group, the core SDO spec permits the use of any query language (SQL, XPath or XQuery). It works with object-oriented databases, relational databases or XML data sources.
OASIS initially began working with the Open SOA group in March of this year to develop the SDO spec. Currently, 11 Open SOA partners are behind the SDO spec. Those Open SOA partners include major SOA solution providers, such as BEA Systems, IBM, Oracle and Software AG.
Microsoft is not a part of this effort. Sun Microsystems initially wasn't part of the effort either, but the company later joined the Open SOA SDO effort as a partner. Some analysts early on suggested that SCA might be an attempt to get around Sun's Java Business Integration (JBI) effort.
In the battle over promoting SOA software, two standards typically get mentioned: SCA and JBI.
SCA provides a description of service components and how those components work together, according to a white paper (large PDF file) by David Chappell of David Chappell & Associates. SCA components can be built with Java or other languages or they can be built using Business Process Execution Language or the Spring Framework. Chappell adds that SCA is a new way to create Java business logic in an SOA and that it is an alternative to older methods, such as EJB and JAX-WS.
JBI, on the other hand, is a standard supported by Java Community Process JSR 208. JBI provides a Java runtime environment.
The Open SOA group sees SCA as generally complementary to JBI, according to a note posted by Mike Edwards of IBM. However, SCA supports types that don't run on a Java Virtual Machine, such as C++, he added.
Jason Bloomberg, senior analyst at ZapThink, noted in an interview that SCA supports C++ and Python, but lacks a .NET implementation. He added that both SCI and JBI will be "marginally helpful" to architects. After all, the focus of architects is not on component architecture, but on service architecture, so architects aren't typically thinking about Java or .NET frameworks, he explained.
Bloomberg described SCA as a way for some vendors to coalesce on the component structure in their products, but "SCA and JBI are mostly about vendor politics and hype," according to ZapThink's Web site.
OASIS is planning a series of four free Webinars to provide more information on SCA, beginning on Dec. 10. For more information, go here.
Kurt Mackie is senior news producer for the 1105 Enterprise Computing Group.