Last Wednesday, IBM and a coalition of middleware and development tool vendors announced their support for two specifications that could make it easier for companies to create Service-Oriented Architectures (SOAs). The specifications—Service Component Architecture (SCA) and Service Data Objects (SDO)—could simplify the tasks required to create and maintain networks of Web services. However, SCA and SDO will realize their full potential only if Microsoft joins the vendor coalition in endorsing them. Unfortunately, that endorsement is far from certain.
While Microsoft was notably absent from the coalition, the vendors that were present—BEA Systems, IBM, IONA, Oracle, SAP, Siebel Systems, Sybase, Xcalia, and Zend Technology—demonstrated widespread support for SCA and SDO. That support reflects a growing admission among software vendors that many of their customers find it far too difficult to develop Web services and compose applications from them. A big reason for this difficulty is the multitude of programming interfaces that Web services use to communicate with each other, with other types of code, and with data sources. An extremely short list includes SOAP, WSDL, JMS, JCA, JDBC, JAX, and older interfaces such as ODBC and remote procedure calls.
To create Web services today, developers must know the acronym soup of programming interfaces with which their services will interact and write code to those interfaces. If the interfaces change—for instance, because of the deployment of new applications that use different interfaces—the Web services must be modified. Such "hard wiring" between Web services and other IT resources creates a complex and brittle infrastructure that is costly to maintain, much less enhance. That runs entirely counter to the loosely coupled design philosophy that is the hallmark of SOAs.
This is the problem that Service Component Architecture and Service Data Objects aim to address. Put simply, SCA describes an SOA programming model that includes, among other things, a specification for how Web services and other types of code interface with each other. Software vendors who support the standard can wrap SCA interfaces around their existing interfaces. This could make it possible for developers to write all Web services to a single SCA interface instead of to multiple lower-level interfaces. Indeed, SCA-compliant development tools could allow developers to ignore interface programming and implementation issues entirely, freeing them to focus on business logic.
In like manner, SDO specifies a consistent method for accessing data from multiple sources, including relational databases, XML documents, Web services, and enterprise information systems. Instead of replacing existing access methods such as ODBC and JDBC, SDO specifies a class of components called data mediator services that would interface with those access methods. This could allow developers to write to the SDO interface instead of to multiple data access interfaces. While SCA is a completely new specification, SDO has been around for a couple of years. Though acceptance of SDO has been spotty, last week's announcement should give it a shot in the arm. By the way, SDO is part of the programming model that SCA specifies.
Besides announcing their support for SCA and SDO, the vendor coalition stated that they will submit the specifications to a standards body, with SDO due for submission soon. In the meantime, the coalition will develop Java and C++ implementations of both specifications. In addition, IBM intends to support SCA and SDO in some of its own languages. While the company has not announced which languages will gain, its COBOL and CICS offerings are likely candidates. I have asked IBM sources about ILE RPG support and will report on the company's answer once I receive it.
While SCA and SDO received ringing endorsements from several software market leaders last week, Microsoft had nothing to say about the specifications. That is not unusual, as the vendor coalition has not yet sought an endorsement from the software giant.
This news underlines the fact that, to a great extent, SCA and SDO address problems that programmers face when they are not using Microsoft tools and technologies. As Windows developers know, Microsoft's .NET Framework incorporates a programming model that does much of what SCA does...that is, as long as all programs are written to the .NET Common Language Runtime (CLR). In addition, the vendor's ActiveX Data Objects (ADO.NET) specification provides much of the functionality found in SDO.
Since Microsoft has its own SOA programming model, it makes sense to ask why the folks in Redmond would lend a bunch of Java-centric vendors a hand by supporting what could be seen as a rival model. While doing so would make Microsoft look like a champion of open standards, it would allow its competitors to make their middleware and tools easier to use...in other words, more like Microsoft's products. On the other hand, if Microsoft does not support the specifications, it could limit their usefulness. That is because most companies are using both Java and .NET technologies to build SOA-friendly applications. Without Microsoft's support, SCA and SDO could not ensure seamless integration across those applications.
I do hope that Microsoft decides to take the high road and endorse SCA and SDO. Perhaps SAP—a member of the vendor coalition that has close ties to Microsoft—can convince the company to sign up. However, I would not bet the farm on that happening. My gut feeling is that SCA and SDO face a long and difficult road to acceptance by Windows-centric software vendors.