Interoperability and Fragmentation

Some things are beginning to seem a bit clearer to me as a result of
recent discussion.

First, I think that there are some people, perhaps including myself, who
had an expectation that if we defined a Web service architecture well
enough that then one could guarantee, or at least hope, that any two Web
services conformant to that architecture would interoperate.  I now
think that this expectation was as misguided as would have been Humphey
Bogart's (as Rick) had he come to Casablanca for the waters.  Those
waters are just not here.  As WS-I is showing us, the only way to
guarantee interoperability is to constrain very tightly to particular
specs and even to interpretations of those specs.  Such an interoperable
profile is useful pretty much at a given point in time.  WS-I has
labelled their current profile "number 1", with the clear expectation of
numbers 2 through N, with interoperability across profiles yet to be
determined.  An architecture that actually guaranteed interoperability
would fairly rapidly become irrelevant, I think.

Moreover, I think it's pretty much time to wake up and smell the coffee
on the fragmentation issue.  Yes, fragmentation is not good.  It is,
however, a FACT and it doesn't do any good to ignore it.  There has
clearly been a major bifurcation of Web services due to genuine parallel
development between ebXML and the W3C (with ebXML probably first on the
ground).  I am currently attending an energy industry vertical meeting,
and let me assure you that if anything is ignorable here it is W3C Web
services.  This group is in the process of committing to ebXML and
developing rather specific implementation strategies.  W3C Web services
are just not taken very seriously (for business transactions -- they are
certainly being used internally for operations behind the firewall).
This is because key specs are viewed as immature and because there are
gaps or competing specs in areas of functionality necessary for business
applications.  W3C Web services are, in this context, simply not viewed
as a serious player at this time.

It seems to me that it would be best, to put it mildly, if this WG
defined an architecture that encompasses both branches of this
bifurcation, at least at the higher levels of the architecture.  If it
gets much more specific on one side as a map for the future so be it,
but I think that a Web services architecture that completely excludes a
major current implementation of Web services would not be very plausible
or useful.  This architecture should not, in my view, be constrained by
current specifications but should provide a context and framework for
those specifications and for specs to come.  That is, the function of
SOAP should be the fundamental unit of the architecture, not SOAP
itself.  If, then, SOAP is the only reasonable realization of that
function on the radar screen, that's really great.  But in the case of
interface definition I think we have two clearly viable realizations at
present.  It would be nice, of course, if the framework could provide
some guidance as to how those realizations might converge or
interoperate in the future, but I have no idea whether it is possible to
do so.

In addition, such a framework that guides specifications rather than
being constrained by specifications can continue to be useful into the
semantic generation of specs that some people expect to appear.  A
specification constrained architecture would, at best, become irrelevant
and at worst would be a hindrance to progress.

I believe that this direction is pretty consistent with the re-factored
architecture.  In other words, I think that this is actually pretty much
what we are doing.