When Java technology first began to emerge as a transforming force on the Internet scene years ago, its licensor, Sun, coined a slogan that succinctly described the vision of the new development language and runtime environment: "Write Once, Run Anywhere". Previously, the vast majority of business applications had to be written in such a way as to couple them tightly to an individual run-time environment (Windows, Unix, Linux, etc). Java programming language broke the mold by providing a specification for a virtual machine that would allow programming logic written in the Java language to be compiled and run on any platform fully implementing that specification. Java programming language, in effect, defined the concept of portability.
There is a catch, however; just because an application is portable doesn't mean that is is capable of being integrated or is interoperable with other applications. In other words, while a key benefit of Java programming language is to allow developers to break free of the restrictions imposed by individual operating systems or hardware platforms, Java programming language did nothing that other languages don't also do for interoperation. Whether they write in Java programming language or some other language, application developers have the same difficult time integrating and interoperating with "foreign" environments. Developers have, for many years, sought solutions that allow such cross platform integrations to occur without incurring huge investments in buying or developing the necessary technology. Note that while Java technology does have built-in capabilities for interacting with non-Java platform environments, using those features severely limits the portability of the Java application. Also note that adherence to the Java specification doesn't guarantee interoperability even between Java technology only applications.
The key lesson: Portability is important, but it's not enough.
The Java 2 Enterprise Edition (J2EE) specification is a prime example of how Java technology helps to create portable applications yet does nothing to help (or hinder) interoperability. By portable, we mean the ability to take a J2EE application running on one vendor's implementation (of, for example, JMS) and deploy and run it successfully on another vendor's implementation of the same specification. By interoperable, we mean the ability to have one vendor's implementation communicate seamlessly with another vendors. These are extremely different concepts and J2EE simply does not recognize interoperability between implementations as a key requirement.
The challenge with this is that while imagining that companies wishing to integrate their supply chain, customer relationships, resource planning and other essential business processes will all use a single development platform (for example, J2EE or .NET) to do so is a nice thought, reality teaches us that no one platform or operating system will be sufficient to meet the needs of the customer. Interoperability between multiple platforms is vital.
The role of Web services in enterprise application integration scenarios is to make it easier to tie applications running on heterogeneous platforms together; to help them overcome the communication gaps that arise from decisions to use one development environment over another; and to help abstract such choices so that business developers no longer have to keep track of what operating system or what development environment or what technology decisions have been made.
In the second installment of Best Practices for Web services, a series of articles focusing on deriving best practices for the design and implementation of Web services within an enterprise, the point is made that "Web services will affect the implementation of business, integration, and application patterns whenever there is a boundary -- between businesses, between applications, between logical components of a solution, etc. -- across which information must be exchanged." This is perhaps, the most important piece of information someone needs to understand the differences between portability and interoperability. That is, portability (the part that Java technology provides) is the ability to move the logical components of a solution from one platform to another and still make it work; while interoperability (the part that Web services provide) is the ability to allow those logical components to work together regardless of the platform upon which they are deployed or the development tools that were used to build them.
Vertical and horizontal abstractions
To help illustrate the distinction with greater clarity, you need to go back and examine the fundamental design philosophy behind technology platforms like J2EE technology and .NET versus the emerging Web services architecture being defined by the various Internet standards bodies.
J2EE is a specification that defines an infrastructure into which application components written in the Java language can be deployed and run in a way that allows them to take advantage of certain key services (security, transactions, asynchronous messaging, etc). Vendors implementing J2EE technology in their tools are required to implement a common set of core application programming interfaces for those services that, in theory, allow components conforming to J2EE specifications to be moved from one platform implementation to another. The goal is, and always has been, to decouple business applications from individual operating systems and hardware technologies.
Figure 1. The vertical portable component model

What you can see illustrated in Figure 1 is the basic model that portable component development environments all follow: An application component interacts with system services through a set of common programming interfaces that are backed with vendor specific implementations. By programming to those common programming interfaces when integrating security, transactions, calls to a database, or other essential tasks, a business component can be ensured that when it is time to change the underlying operating system or hardware, it will continue to function. Boiling it down, portability is about abstracting the interfaces that a business application uses to communicate with the underlying system upon which it is running. Portability does nothing, however, to abstract that interfaces an application uses to communicate with other applications.
Figure 2. The horizontal interoperable service model

Figure 2 illustrates the role that Web services technologies play in terms of abstracting the communications interface between business applications. What you see here is the same basic philosophy seen in the vertical portable component model (that is, by using common abstract interfaces to system services, an application becomes portable) applied to the horizontal relationships between business applications (that is, by using common abstract interfaces to other applications an application can become interoperable). Without such horizontal abstractions, applications running on multiple platforms would not be capable of communicating with one another due to the many differences that exist in the way those platforms are put together. Just as Java and J2EE technology allows you to move a business application from one technology platform to another, Web services allow you to integrate business applications running on different platforms.
Portability and interoperability: the right blend
As we've already stated, a portable application is not necessarily an interoperable one. Equally so, an interoperable application is not necessarily portable. Experience dictates that you need the right blend of portability and interoperability to create successful EAI applications. The way to get that blend is to not tie yourself to any one platform, development environment or operating system, and to embrace the reality that customers use and rely upon many different types of systems; and that the business relationships those customers wish to forge with their partners and customers do not confine themselves to the rules of any single platform specification. Most critical, however, is to understand that portability and interoperability are not synonymous concepts.
- See Best Practices for Web services, Part 2 for more information.
- Visit the Web Services Interoperability Organization home page. to learn more about industry efforts to ensure interoperability between technology vendors implementation of Web services specifications and standards.
- Visit the W3C's Web Services Activity home page to learn more about the effort to define Web services standards.
- Visit Sun's Java Web site to learn more about Java and J2EE technology.
James Snell is an architect and strategist for the emerging Internet technologies team within IBM's software group, where he plays an active role in the evolving architecture and implementation of Web service technologies. He is a coauthor of the book Programming Web Services with SOAP, published by O'Reilly & Associates. James can be reached at jasnell@us.ibm.com.
Tom Glover is Senior Program Manager of Web services Standards for IBM Software Group. Currently he is the President and Chairman of the new Web Services-Interoperability Organization. His leadership is focused on driving an industry-wide understanding of Web services through articulating the business value this rapidly maturing technology offers. Working within the growing Web services community, his vision is to make interoperable Web services a reality. You can contact Tom at glover@ca.ibm.com.




