On 30 November 2005, a consortium including BEA Systems, IBM, Iona Technologies, Oracle, SAP, Siebel Systems, Sybase and Xcalia announced two specifications aimed at helping developers build applications and components using service-oriented architecture (SOA) principles:

• Service Component Architecture (SCA) — A metadata model that describes the relationships and the deployment of services
• Service Data Objects (SDO) — A metadata-driven mechanism for representing data objects and their relationships to each other

SCA is an attempt to combat one aspect of Sun Microsystems' Java Business Integration effort by delivering a programming model for SOA — a non-Java-specific, metadata-driven model that describes the composition of services. BEA, IBM and Siebel have cooperated on the initiative, and SAP and Oracle have joined the effort, even though it competes to some extent with their own strategies for composition. Neither Sun nor Microsoft has joined the effort to date; each has a competing strategy to SCA/SDO already.

SCA’s assembly model should simplify the integration between runtime software and development software by providing streamlined, easier-to-use tools for deploying and managing complex service-oriented applications. SCA service descriptions are not only language-neutral, but also independent of interoperability protocols. In other words, services described in SCA do not have to be Web services and could use other access methods, such as Java Message Service. This model will help the adoption of services by simplifying and homogenizing the large number of programming models across environments.

However, Gartner believes that it will take at least 24 months before most users understand the need for SCA's composition capability, and the standard's impact will be limited during that time. Without Microsoft's direct support, many users outside the Java community are unlikely to use SCA. Although SAP and Oracle have declared support for SCA, the adoption of SCA may overlap with their own business service composition mechanisms, so their support is likely a hedge in case SCA takes off. Since the value of SCA to customers is in simplifying service composition, availability from application providers such as Oracle and SAP will be key.

SDO, which is an update to an earlier proposal from BEA, IBM and others, has been around longer than SCA and is built into more products. SDO's function of facilitating enterprise data integration is the most prevalent goal of many SOA initiatives, and will be a big reason why SDO will achieve official standard status more rapidly than SCA.

Recommendations

• Assume that SDO will become prevalent by late 2007, and seek out products that support SDO abstractions for data.
• Customers using products for service composition from vendors that support SCA should take advantage when SCA implementations are available.

Analytical Sources: Daniel Sholler and David Mitchell Smith, Gartner Research

Recommended Reading and Related Research

• "The Value in Java Business Integration Lies Beyond Java" — A business integration strategy built with OASIS (Organization for the Advancement of Structured Information Standards) or World Wide Web Consortium standards would better serve the needs of the IT community than one built on Java specifications. By David Smith, Daryl Plummer and Yefim Natis
• "Sun Gains Integration Solution With SeeBeyond Acquisition" — This deal helps Sun complete its Java Enterprise System and deliver consistently on its message of providing an SOA stack. By Daryl Plummer, Jess Thompson and Nicholas Gall

(You may need to sign in or be a Gartner client to access the documents referenced in this First Take.)