Web services interoperation
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?
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.
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?
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 - JiniTM 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.