This month's Web Services Edge conference marks four years since the first detailed W3C note on the Web Services Definition Language (WSDL) and nearly five years since the first public specification of SOAP.

You may be wondering, why hasn't the uptake of Web services matched the bold predictions made when it was first launched? There are certainly more developers thinking about Web services with the advent of service-oriented architectures (SOA). However, the number of successful public Web services projects seems to be limited to a few high-profile companies like eBay and Amazon that have published APIs and end points, or developers who have been able to implement services internally but with a narrow and well-defined set of services - still a long way from the smart application that could self-select services at runtime.

There are many factors that can slow the adoption of a new technology. Sometimes it's a technical barrier, competition from an alternative technology, or simply customer reluctance to move to something new. To shine a light on some of the issues that developers experience with early Web services, I can share some of my own experiences with adopting Web services into the J2SE platform.

One common request for J2SE 5.0 was to add Web services, however, even back in 2001 there was some concern over whether Web services was really ready. Unfortunately, we later discovered an issue that would continually dog many other early Web services implementations, namely interoperability. The issue in this case was that the order of mapping XML back to Java for static stub and dynamic proxy-based JAX-RPC calls was not made a requirement in the specification, and implementers of the specification already had products that didn't match the reference implementation. By its very nature, the Dynamic Invocation Interface (DII) method of calling JAX-RPC was unaffected by this change. The result was that you compiled a Web service with one client runtime, but it may not necessarily work with another JAX-RPC engine. In the case of J2SE, to prevent shipping an incompatible technology, the expert group reluctantly agreed to pull the JAX-RPC specification from the platform.

One of the business problems that Web services was to address was interoperability. Why did the W3C have to create a further Web Services Interoperability profile, and is this going to be the final answer to building a full SOA-based application?

The recent history of computing has been one with specifications drawn up by one or more companies or organizations. Companies and organizations then compete on implementations of those specifications, which then become the resulting standard. Although this has now become accepted practice, this process is not without its flaws.

First, most of the parties that contribute to those specifications have already built or are currently building their own implementations and will often simply modify their own implementation to match the specification. Then, in an effort to be the first to support the new specification, those same parties will often have to make compromises, especially when it comes to the behavior of the API or other places where the specification is unclear.

To be fair to the specification writers, it's hard just to get an agreement on a well-designed, clean API. What happens inside those APIs, the behavior of the implementation, or what should occur if an API is called in one of the myriad possible sequences is beyond the scope of most specifications.

With that in mind, applying that specification methodology to Web services that are designed for a language- and OS-neutral platform and yet deliver flexibility was never going to be easy. To address some of these pressing issues, the Web Services Interoperability Organization (WS-I) was formed. The first fruit from that collaboration was the Basic Profile 1.0. Last year saw the introduction of an updated Basic Profile 1.1. Yet if you want to use SOAP binding or SOAP with attachments, you need to follow the additional WS-I profiles. The WS-I profiles by their very nature try to define a minimal set of functionality that should work, and as a consequence consign many early Web services technologies, like styles of WSDL encoding, to the trash bin. Even with a restricted set of supported functionality, code examples, and guidelines, the WS-I still makes no guarantees about interoperability. It begs the question: Can Web services fulfill its original promise of dynamic configuration and discovery, or is it yet another useful distributed service that needs to be deployed by architects like the other distributed services that came before it?