One of the driving goals of the original SOAP was for interoperability. As with any first draft, it left many things up for interpretation. A group of industry participants referred to as Soap Builders are working on interoperability among the various SOAP implementations. Interoperability issues are constantly changing; refer to http://groups.yahoo.com/group/soapbuilders for the latest status.
Many implementations of SOAP do not agree on how SOAP headers should be handled. One example is that the SOAPAction header is permitted to be null (no value specified), an empty string (no intent specified), or an arbitrary quoted string. The SOAPAction header indicates the intent of the message for its target. Some SOAP implementations (e.g., Apache SOAP) do not support dispatching using the SOAPAction header. Instead, they route based on the namespace URI of the first child element contained in the SOAP:Body element. SOAP also allows for un-namespaced body entries, which cause their own issues.
Some aspects of SOAP have not been implemented by all parties. One example is character set encoding. For a SOAP message to be understood, both the originator and the recipient must use the same encoding of the character set. SOAP does not force a particular encoding standard. For interoperability, SOAP also requires all message interchanges to use the same protocol bindings, such as HTTP. Although HTTP is pervasive, the ability to use other bindings may interfere with interoperability.
Many SOAP toolkits are used to generate WSDL files. Depending on the particular toolkit in use and when the service was first generated, you could run into schema incompatibilities. The early IBM Web service toolkits could generate WSDL based on the earlier XSD 1999 working draft, but an ASP.NET Web service would generate WSDL using the final XSD recommendation. Other toolkits handle this conundrum in different ways. The WSDL generated is important primarily because SOAP proxies are created from it.
The Apache SOAP implementation requires that all SOAP (RPC) envelopes be self-describing in terms of types. Apache SOAP does not work without every typed value being explicitly contained in the envelope, using the xsi:type attribute. This is not a SOAP requirement, and many implementations leave out this information.
Many SOAP interoperability issues can be directly correlated to the underlying language used to create and/or read the SOAP message. One example is that Java handles both floating-point numbers and dates differently from SOAP. The SOAP specification states that floating-point numbers can be represented as exponential numbers. Both the Apache SOAP and Axis libraries use Java's toString method to convert floating-point values to java objects. In Java, when a float has an overflow condition, it will output the string as "Infinity." The SOAP specification states that it should appear as "INF."
The decimal data type in SOAP can represent numbers up to 40 digits. In Java, to handle this decimal data type, we would use the BigDecimal class. BigDecimal has an upper limit, based on the underlying platform (Windows, Linux, Solaris, etc.) The current .NET implementation of BigDecimal allows up to 29 digits.
The date type in SOAP allows a dateTime type, for centuries, years, months, days, hours, minutes, and seconds. SOAP also allows an arbitrary number of digits to occur after seconds. Many implementations of SOAP on Java use the java.util.Date class for date support. Java supports precision only to the nearest millisecond, although .NET can support nanosecond resolutions.
Make sure you also avoid using either HTTP/GET or HTTP/POST bindings in your WSDL. You will typically see these bindings in services generated using Visual Studio. This may cause other toolkits to fail when generating proxies. This can be turned off in the Visual Studio Web service project.
Over the next couple of years, many public UDDI registries will be created on the Internet. The deployment of these registries may follow the same model as search engines, which typically are inconsistent and can point you toward invalid or irrelevant links. Today, no standardized mechanism allows a registry to remove outdated entries. This problem may or may not be solved by a registry's ability to synchronize with others. Synchronization may allow invalid entries to be removed globally but can also compromise registry security. Also, a Web service can appear in multiple registries.
The major interoperability issue in UDDI itself will arise from the nirvana approach to service discovery that many in the industry advocate. Using Web Service Inspection Language (WSIL) or similar approaches to discover a service automatically may be technically possible but not realistic from a business point of view.
The UDDI specification allows for a service to be categorized in a registry using taxonomies to describe its location, service, and product type. This can itself cause a potential interoperability problem, because UDDI is based primarily on self-policing that may prevent dynamic invocation of self-discovered Web services.
Many application servers use the Apache Xerces parser for its JAXP implementation. This parser will fail to read any messages that contain a byte order mark (BOM) for UTF-8-encoded SOAP requests. The BOM is legal in UTF-8-encoded messages and is sent by many non-Java SOAP toolkits.