The World Wide Web Consortium has announced that Version 1.2 of SOAP - a key foundation-level technology for companies building Web services - has achieved "recommendation" status.

Recommendation status means SOAP 1.2, a set of rules for exchanging structured information among systems or organizations, is a fully vetted standard that has gone through a rigorous public-review process and substantive interoperability testing.

By contrast, SOAP 1.1 was a de facto standard that was never vetted by the W3C or any other standards body, said Don Deutsch, vice president of standards strategy and architecture at Oracle and a member of the W3C Advisory Board.

The W3C's XML Protocol Working Group, which was responsible for SOAP 1.2, identified and resolved more than 400 technical and editorial issues raised about the prior version. The group later tracked seven SOAP 1.2 implementations from various W3C member organizations and independent developers to ensure their interoperability.

Expanding scope SOAP 1.2 provides a more precise description of the processing model and removes ambiguities that sometimes led to interoperability problems for those trying to implement Version 1.1, said David Fallside, chairman of the W3C's XML Protocol Working Group and a senior technical staff member at IBM Corp.

"By providing the processing model in greater detail and expanding the scope of cases that it covers, you significantly reduce the chances that two different people sent off to implement the specification would come up with implementations that are not interoperable," Fallside said.

But it's unclear when vendors will adopt SOAP 1.2. Deutsch said Oracle is committed to supporting the standard, but he couldn't say when that will happen because "to do anything meaningful" with SOAP, most tool kits depend on another standard, the Web Services Description Language (WSDL). The W3C is still working on WSDL 1.2. Deutsch said it will take "some time" for vendors to fully support all the features of SOAP 1.2, so during the transition period, SOAP 1.1 will co-exist with SOAP 1.2.

Mobile media Jason Bloomberg, an analyst at ZapThink, said he thinks it will take a year or two for SOAP 1.2 to work its way into products. In the meantime, "vendors and end users are going to be annoyed at times at the fact that there are two (versions of SOAP)," he said. But he added that work is ongoing in the Web Services Interoperability (WS-I) Organization to create profiles on how to use standards such as SOAP.

Users will have to wait for SOAP 1.2's improvements, such as protocol-agnosticism. SOAP 1.1 confined users to sending messages over HTTP, but with 1.2, they will be able to choose other protocols, such as SMTP, TCP/IP, BEEP (the Blocks Extensible Exchange Protocol) and IBM's MQSeries, Fallside said.

"We expect a lot of people will flow XML messages over HTTP, so there is an HTTP binding for SOAP. But you don't have to use it," he said.

Bloomberg said HTTP was never designed for system-to-system communications. "HTTP was really designed for hypertext. HTTP is synchronous, and it's not secure. It's not reliable," he said. "So it's definitely good to support other protocols for different uses, whether it's message queuing protocols or asynchronous messaging protocols of other kinds."

Division of Labour The W3C group working on SOAP 1.2 split the specification into two parts - essential SOAP (which includes the processing model, the extensibility framework and the message construct), and optional elements, such as the rules for representing a remote procedure call (RPC), encoding SOAP and describing an HTTP binding. Fallside said the separation breaks the old perception that SOAP is merely RPC over HTTP.

Another key change in SOAP 1.2 is that it's based on the XML Information Set, which provides a way of describing the information conveyed in an XML document. By contrast, pointy brackets were paramount with SOAP 1.1, which was based on XML 1.0 serialization, Deutsch said.

"The upshot is more flexibility in the representation of messages, so you can tailor or customize for your application/business requirements," he said.

Fallside said this will be helpful for companies that need to send more compact messages between applications via an extremely low-bandwidth connection. He said he expects that most companies will still use XML representations, since that will allow them to use off-the-shelf tools and applications.