One of the typical complaints about standards is that there are so many of them to choose from. For web services, beyond the basic stack of SOAP messages, WSDL service definitions, and UDDI service registries are a bewildering array of security, management, and connection protocols that enjoy varying levels of vendor support.
The only problem is that most of the standards already in place are aimed at very low level. They are designed to help requests and responses connect over the wire. They are not designed for connecting components and data. Unlike Java or .NET frameworks, a component development metaphor for web services has been missing.
The new proposals by fall under two families: Service-Component Architecture (SCA), which would provide standard APIs for assembling components from existing bodies of services, and Service Data Objects (SDO), an update of an earlier specification first proposed by IBM and BEA which abstract the service assembly from the data source.
Until now, developers have had to understand how to construct the right headers for security-enabled SOAP messages and service definitions. More importantly, they also had to know specific APIs to the underlying middleware, and understand the table or header structure of the data source, regardless of whether it came from a relational database or XML data store.
In effect, with the proposed specifications developers could simply bind at the component or data object level, without having to know what is running beneath it.
The proposed specifications include a language-neutral model for assembling service objects, plus a Java-based implementation that will be co-authored by BEA, IBM, IONA, Oracle, SAP, Siebel, and Sybase. A parallel C++ implementation will be co-developed by IBM, BEA, IONA, and Sybase. Additionally, BEA, IBM, Oracle, SAP, Siebel, Xcalia, and Sybase will jointly develop a Java-based SDO implementation, while IBM, BEA, and Sybase will develop a C++ version.
The obvious missing link is Microsoft and its .NET programming model. We would welcome Microsoft, said Karla Norsworthy, a vice president at IBM, who also said Microsoft was not engaged at this time.
In effect, the web services world is traipsing over old ground, but with a difference. Java, .NET, and CORBA have long had component and data object constructs, but they were based on their own underlying technology. As a result, vendor support proved a huge issue. And in the case of CORBA, reference implementations and compliance tests were absent.
This time around, the attempt is to separate construction of the component from the language, underlying application, and database against which it is being implemented. And the vendors promised run time code, not just paper specs. But as yet, there were no questions answered as to compliance tests or reference implementations.
Another distinction is that CORBA always assumed tightly connected components. To lesser extents, the same has been true for Java and .NET.
We went to great expense to differentiate loosely and tightly coupled bindings, said Ed Cobb, a vice president of technology and standards at BEA. He explained that using SCA and SDO frameworks, services could be tightly coupled inside their own containers, or originating applications, but designed for loose coupling externally with other service objects.
None of the proposed specifications are yet considered ready for submission to standards bodies. The first step is publishing the specifications.
The next steps are to release runtime code and solicit feedback, kick off an Eclipse project for developing the tooling for building SCA components. Oasis and OMG were mentioned as possible targets for handle formal standardization efforts. IBM also said it is looking into developing SCA implementations for legacy languages or environments such as RPG, CICS, or COBOL.
