Around 15 years ago there was a cascading switch failure in the telephone network along the Eastern Seaboard of the United States. Phones stopped working. So did air traffic control, because information about air traffic was communicated between control towers using the phone network.

The failure was caused by incompatible implementations of the interswitch trunk protocols. These specs, while very long and detailed, are necessarily imperfect. With the best of intentions, different development teams interpreted the specs in different ways. When one switch started to fail, it sent out messages its neighbors didn't understand, and they failed. And so on, up and down the coast.

Such failures don't happen very often, because the standards are very good, the implementations are faithfully executed, and the systems are thoroughly tested. This stems from business motivations that make quality the highest priority.

When I moved from telecoms to databases, I was frankly appalled at the lack of formal specification and testing. Eventually I realized that this was an optimization with different goals. Business applications aren't like the phone network, which has to be all but 100% reliable - when was the last time you didn't get a dial tone? Failures are simply unacceptable.

Failures in e-mail and back-office applications are more acceptable in part because their scope is limited - between the applications are human correcting abilities and response times. When systems go down, we restart them and suppliers don't necessarily notice.

So why am I bringing this up?

Web services are turning back-office and desktop applications into something that's more like the phone network than what we're used to. Systems connected directly to one another lose those human correcting abilities and response times.

Reliability is more important in a world in which applications from different vendors written in different languages with different frameworks running on different hardware all have to interoperate correctly. Just as with the phone network, Web services will fail unless we have good specs faithfully implemented and thoroughly tested.

Good specs need to be thorough and unambiguous. If different "correct" implementations produce different results, how will programmers and consumers use them?

Faithful implementations need to follow the specs, but it is easy to find standards whose implementations are deliberately incompatible. HTML and Kerberos come immediately to mind.

The Java Community Process (JCP) addresses these issues by requiring that a specification be accompanied by a Technology Compatibility Kit (TCK) and a Reference Implementation (RI). The RI shows that the specification can be implemented, and to unearth ambiguities. The TCK verifies that the RI and any later implementations are faithful.

The value of Java standards depends on the completeness of these elements, and the integrity of those who implement them. If we measure that in terms of adoption, we're doing very well. Analysts estimate that there are about 3 million Java developers, and there have been over 1.3 million downloads of the J2EE platform 1.3 SDK.

There are around 15,000 tests in the Compatibility Test Suite (CTS) for J2EE version 1.3, and that number will increase substantially for version 1.4. The thoroughness provides assurance of portability of applications.

Application portability is the Java platform's "dial tone," thus the specifications are only available to those who commit to run the tests and ship only compatible implementations.

This is why developers and deployers need to be concerned with those who may claim to implement a specification, but who fail to demonstrate compatibility by running the tests.

Next time you're thinking about what platform to use for Web services, remember these questions: Is there an unambiguous specification? Is there a thorough test suite? Has your vendor run and passed the tests?