Javaworld:

A Java VM must ensure that it interprets byte codes according the to VM specifications. Those specs, in turn, go a long way to ensure that a piece of byte code produces similar results across VMs. In the world of XML-based Web services and SOAP, no such specifications exist. Indeed, SOAP interoperability is already an intense discussion topic on mailing lists. Do you believe that differences in data encoding mechanisms and, consequently, on-the-wire incompatibility, could lead to the fragmentation of the XML-Web services world similar to how Unix fragmented - for example, "Apache SOAP Web service," or ".NET Web service," or "SunONE Web service," similar to HP-UX, SunOS, or Linux?

Rob Gingell:

Such differences would damage the premise of Web-based services architectures using those protocols, because you'd really get no interoperability between products. Since the whole point was to be able to construct functionality out of possibly unrelated services, that would represent either a fatal flaw or limit to the application of the protocols.

That needn't happen, though. To a large extent network protocols enjoy some of the characteristics of binary standards in that they're presented with very hard "yes or no" constraints and standards with respect to interoperability. I think we won't really see problems at the SOAP level. Instead, we might see Web services interoperation problems at the "application layer" of the stack that is using SOAP as a session layer protocol: That application layer might embed a bunch of non-specified information such that you get interoperability only by sharing implementation. A hopeful sign here are activities like those of the SOAP Builders group, an organization of developers from across the industry doing interoperability testing.

Javaworld:

If differences in XML-based data encoding could lead interoperability problems between Web services, would it not be better to use Java bytecode as data encoding for Web services, and turn Java into an open-source Web services standard?

Rob Gingell:

If you define "web services" as a network architecture that uses HTTP as a transport, SOAP as a session layer, and XML as a presentation layer, then you couldn't literally do that. Cynics might argue that that was the whole reason "web services" was defined the way it was. You could, of course, have a different protocol architecture defined as you suggest - Jini^TM does exactly what you describe.

Jini addresses the sort of issues you're concerned about: It solves the problem of specification by sending an implementation around to compensate for underspecified elements of a service: "You don't know about this, but here's the code that makes it possible for you to know." Jini thus addresses the semantic problem that data, alone and underspecified, potentially presents.

The basic problem is underspecification, which results from any or all of laziness, obfuscation, or failures of imagination. Various technology bases differ in how easy, or hard, they make it to underspecify something that appears to be working. The abstract version of this problem relates to how one creates a hierarchy of classes that can be rationally subclassed without creating the problem you describe. For XML, or anything else that's a data structure, it's about creating data that can be extended and still be useful by those who don't understand the extension.

In Jini environments, the only real common practice you need is to be using Java technology. From that presumption, an application can provide you all the semantic extension you need through mobile code. Mobile code, in turn, is enabled by the abstraction of the JVM, which makes the underlying hardware's instruction set unimportant. Which seems like a great idea, unless you're a business that's dependent on what that instruction set is, or dependent on implementation-defined behaviors. But that's an area for cynics to delve into.