What Interoperability Isn't

September 2, 2003

Will Provost

The single buzzword "interoperability" has grown to encompass a broad range of problems and potential problems. Sadly, it is no longer a precise term. To address the various so-called "interoperability issues" and to solve problems, we must first break down this large set. In so doing we find that many issues are not fundamentally about interoperability over message content: some are more traditional enterprise integration problems, some are merely conventional. Reasonable expectations about Web-service interoperability can be set only after the range of true interoperability issues is understood.

In this article we'll consider a few simple, common problems encountered in Web-service development. We'll challenge each of these apparent interoperability problems and sift them out into a few different classifications, many of which are really solved problems from other domains.

It Isn't Conventional ...

A colleague once pointed out an "interop problem" in an embryonic service design on which we were collaborating. I was building the service using Java, and so naturally had created an interface like this:

This fellow was going to be responsible for client/peer software built in C# for the .NET environment, and so he naturally found names like checkStatus and partNumber a bit jarring. He smilingly exclaimed, "We have our first interop problem!"

In fact, he was only half-joking. Microsoft style, of course, differs from Java in use of upper vs. lower case, use of underscores, and so on, and after a while any developer begins to see current practice as the one true path. We've all been on the wrong side of this sort of thing at some point, and it's grating to say the least. Convention mismatches certainly have real costs. There can be small losses of productivity and even an upward trend in code bugginess, partly because developers are human and find habits hard to break, and even because tools can still get the case conversions wrong.

That said, is this an interoperability problem? Most certainly it is not: no more than any matter of naming convention, no more than it would be had I chosen to call one of the methods status_check, or Shirley for that matter. In any distributed system, someone must name things. Often names are chosen by server-side developers, though sometimes not; the choice is made at a higher level, as a matter of business practice. Interoperability over names is achieved when a shared statement including those names is correctly observed by all parties -- even if some of the parties find the names awkward or dreadful.

It Isn't Integration ...

As the previous section shows, multiple parties often face challenges in operating together, but not all such challenges fit the more narrow definition of "interoperability issues" within the Web-services realm. Another case in point is a company that is considering adherence to a new industry specification, spelled out precisely in WSDL.

Between their own existing practice, potential cooperating businesses, and the standard itself, analysts observe a number of mismatches: over basic data types, structures, and interaction styles. Probably the simplest specific problem is the difference between the WSDL-described part number type and the fields the company currently holds in its databases: one is 8 characters and one is 6. This is mundane, perhaps, but is just the tip of an iceberg, and at any rate, surely such gritty challenges are at the heart of the Web-service interoperability problem?

Well, let's just say we're getting warmer. Yes, type mismatches are the stuff of interop failures. The question -- still, as with the naming-convention issue -- is, "Do these mismatches result from diverse mappings from a shared statement -- such as a common WSDL descriptor?"

They do not. In other words, what we're seeing in this case is not a problem of interoperability, but of integration. Yes, the same gruesome beast we've been fighting for all these years returns in a new disguise, and, in fact, our weapons will be the same ones. Part numbers don't line up? Well, somebody had better make them! The solution will likely be found at the business level first, and the technical level second. If anything, the implicit use of XML throughout the system offers a few new tricks to the traditional bag:

• A business deal that subordinates one party's model to the other's -- where an industry-standard WSDL is in play, this simply means retrofitting to the standard:

  Retrofitting.

• Agreement at some scope that a given problem can be safely ignored -- maybe received part numbers are only those generated by the company itself, and so it knows the extra 2 characters are dead?

  Ignoring the problem.

• A unilateral decision to "map it or wrap it" with an adapter component -- another traditional solution, but with XML in play the adaptation from one WXS type to another may be implemented succinctly using XSLT (more on this in an upcoming article):

  XSLT adapter.

Okay -- What Is It?

Ultimately, as the Web services community has defined it, the problem of interoperability is bounded by WSDL itself. That is, the promise of interoperability is that two or more parties, working from a shared statement of message semantics, can arrive at working components that will reliably adhere to those semantics, and thus will function together. WSDL provides the means of expression for those shared statements. How the parties arrive at a shared statement is external to the question of interoperability -- the typical modes are:

• Service developer invents the message types and interactions, and clients read the resulting WSDL

• Client defines requirements in WSDL, and services are built to those requirements (e.g. as attached to an RFP)

• Industry consortium hands down edicts as WSDL descriptors, and individual businesses choose to play in the newly created space

The very observant will note that to say the problem is bounded by WSDL 1.1 is to affirm that the solution defines the problem! This is certainly backwards, and challenges over what interoperability issues should be addressed by WSDL and WXS are healthy for everyone. Too, most languages right now cannot support every facet of WSDL or WXS, and so interoperability is an evolving concept that includes a slowly growing subset of these meta-languages. This is where agreements such as the WS-I Basic Profile are needed to hammer out an exact scope -- and to give it a name.

RPC Interoperability

Now let's consider some progressively harder classifications of true interoperability problems. With WSDL and WXS, and an abundance of tools that support them, passing and mutually understanding XML fragments is straightforward. This is all that's really needed for document-style services, and here (author cringes) the interoperability problem is more or less solved already.

Much thornier, but much more ardently sought, is the reliable use of XML to encode RPCs. RPC-style services are attractive because they offer to wrap existing distributed object systems such as DCOM and J2EE, and because they allow developers of new enterprise software to continue to think and work in terms of objects and components. The thorns start pricking when SOAP and XML -- the latter basically a data-oriented, not an object-oriented, language -- are asked to encode the sophisticated conversations common between enterprise software components. WXS is a wonderfully strong language, but it describes data, not behavior. WSDL bends WXS to describe message semantics, but how can this quite simple language express all the runtime expectations common to .NET or Java objects in complex systems? Consider just a few key challenges:

• Basic data binding is largely solved, but is not as simple as it might seem. Primitive numeric types don't line up perfectly between dominant languages, and so validation must be coded in tool-specific runtimes or even application code.

• Polymorphism is clearly desirable, but in the distributed case it requires dynamic class loading. Otherwise, every possible runtime type must be described in advance in the WSDL. Here we have both a tricky problem in the raw and a lack of a consensus choice of several possible solutions.

• SOAP cannot naturally support remote object references. Developers accustomed to DCOM, CORBA, or EJB must either use proprietary IORs or do without.

Thus if RPC-style interoperability is necessary for a certain development effort, it is wise to keep things as simple as possible. Many commercial tools offer solutions to some of the problems shown above, and others in the RPC area. Without a standard solution, though, one trades away interoperability (and possibly code portability) for richer semantics and ease of development -- not always, but usually a bad deal.

Contexts

So far we've avoided the dreaded state question, and assumed that each method invocation is made from a standing start. What about components that want sustained, stateful conversations? Without stateful services, semantics get awkward, transactions are impossible, and security credentials don't persist (without lower level assists such as HTTPS).

State preservation and context propagation are common elements of nearly all efforts towards the next generation of the Web services architecture. To facilitate development of stateful service features, various specifications such as WS-Security and WS-Transactions define well-known SOAP headers to carry contextual information. When these various approaches are adopted as standards, interoperability over such features will be possible.

In the meantime, those who can't do without are best advised to mimic the standards-in-waiting as closely as possible -- inside their own proprietary namespaces! Thus the architecture will be very closely aligned with the future, and when the time is right a switchover can be effected. Also, bear in mind that in keeping with the general "reader makes right" philosophy of SOAP, transitional endpoints and intermediaries can be written to accept either the proprietary or the standards-based header for a given feature, so that both old and new messages can travel smoothly. Intermediaries, in fact, might be written to "tidy up" the header set en route: