I'm frequently asked about the difference between portability and interoperability, and am often surprised at how many people refer to one when they mean the other.

On the surface, the terms are pretty understandable: interoperability means that different systems will work together. Portability means that systems will work in different places. It's clear that enterprise customers need both. How many times have you heard an IT person say, "Our systems don't need to talk to each other?" or "Our deployment needs are never going to change?" (No doubt such folks still have 640KB PCs on their desks.)

But many developers overlook technology advancements and pretend they can go on deploying their applications on the same systems. This despite 64-bit processors waiting in the wings, whose architectures are rather different from those we use today.

Portability doesn't just mean being able to run on another system that you have now. It also means being able to run on another system that hasn't been built yet.

Some developers imagine their applications won't be around that long. COBOL programmers thought this way in the 1970s, but their applications show little sign of disappearing. In fact the opposite is true: there is good money to be made in maintaining COBOL applications today. (Perhaps this was job protection.)

But I think we prefer to add value by writing new applications, not constantly hacking on old applications to make them run on a new system. So how do we best achieve both portability and interoperability?

Sun was recently elected to the board of the WS-I (www.ws-i.org), an organization chartered with the development of Profiles that chart a course through the maze of XML and Web services standards to create a basis for cross-platform and cross-language interoperability. This is good - both the WS-I itself and Sun's election to the board.

The main benefit of the WS-I is the exclusive focus on interoperability, precisely because it's hard to get right. People are trying to do a lot of different things with the Web. It's easy to focus on just a few uses and determine the requirements that enable those to work. What's hard is figuring out what is needed for the whole breadth of requirements.

I truly hope that the WS-I is up to the task of charting that course through the many and sometimes contradictory standards, and that it will not get bogged down in politics.

Some organizations seem to have more trouble with the smoke-filled room than others. I remember the glorious failure of the ODMG (Object Data Management Group) standard. There was a completely incompatible operating mode written up in an Appendix of the spec to validate it, even though only one leading vendor would ever implement it.

The WS-I has been showing signs of rising above the smoke to do the Right Thing, with the draft of the Basic Profile requiring support for document-based Web services instead of only the overly simplistic RPC method. Document transfer is much more useful for real business-oriented Web services, even if some vendors have strong product focus on RPC.

Sun's inclusion on the WS-I board is good in part because so many developers use the Java platform for creating Web services, and also because Java has successfully achieved a high degree of interoperability through standards.

In his role as lead architect for the Java 2 Platform, Enterprise Edition (J2EE), Mark Hapner, Sun's representative to the WS-I board, has done a great job of ensuring that J2EE applications may be deployed across multiple vendors' solutions with fully secure and transactional interoperability.

But before we lift a celebratory beer at having solved interoperability, let's remember that this is only half the problem. Portability is where the Java 2 platform comes in.

An analogy may be drawn to writing in compiled languages instead of assembly language. Rewriting only the compiler can improve performance of an application, or allow that application to run on new processor architectures. It costs less to rewrite the compiler than to rewrite all our applications.

The Java platform extends this analogy to the rest of the system. The virtual machine may be enhanced to squeeze more performance out of existing hardware, or rewritten to take advantage of evolutionary or revolutionary system changes. The Java APIs that intermediate between the application and external services (including Web services) may be rewritten to reflect the evolution of those protocols. All without changing the application itself.

The Java Community Process (www.jcp.org) is how we standardize Java APIs and the required tests that ensure different implementations exhibit the same behaviors behind those APIs. The Java platform and APIs are developed and maintained by expert groups consisting of architects, senior developers, and technical visionaries from more than 450 companies. Specs and tests are required to achieve application longevity in a changing world.

The WS-I and JCP can together create a good deal of value. The WS-I defines the profiles that enable interoperability, and the JCP abstracts the protocols and services specified in the profiles within APIs. This allows the evolution of infrastructure without rewriting all the applications that utilize it.