The Portability Pitfall
Unless you’ve been living under a rock, you know that the big IT news this month is the new détente between Microsoft and Sun Microsystems. Once bitter enemies, these adversaries have agreed to lay down their arms and work together in the spirit of interoperability — at least in principle. There are many facets to this thawing of relations, including joint licensing, settlement of lawsuits, and a hefty check, but both sides claim that the real motivation for the agreement is to improve interoperability between each vendor’s products — because, after all, their mutual customers are demanding interoperability.
If you look closely at what Microsoft and Sun are actually saying about interoperability, however, then there are some ominous signs that the two vendors aren’t truly seeing eye-to-eye on what interoperability is really all about. The fundamental difference lies in the distinction between interoperability and portability. These two approaches to assuring successful distributed computing in a heterogeneous environment are fundamentally different, and unless Sun and Microsoft can come to terms with the respective priorities of interoperability and portability, then the new-found relationship between these two vendors is doomed to failure.
Two Perspectives on Distributed Computing
Before we can discuss the benefits and disadvantages of these two distributed computing approaches, we must define the terms “interoperable” and “portable.” Two applications are interoperable if messages sent from one system running under one environment can be understood by another system that might be running in an entirely different environment. Interoperability is a core value proposition of Web Services, which provide for interoperability through the use of standards-based messaging and Service description formats. In contrast, distributed computing functionality is portable if the software component will run on different runtime environments, typically on different systems, but on a common runtime infrastructure. Portability is a core value proposition for Java, whose Java Virtual Machine (JVM) architecture supports its “write once, run anywhere” mantra. On the flip side, the Web Services’ mantra would be “write once, access anywhere.”
Microsoft’s basic approach to distributed computing centers on interoperability. .NET’s use of Web Services provides interoperability between .NET-based applications and applications written on different platforms, whether they are .NET, Java, or even COBOL. In addition, Microsoft’s plans for the future of .NET in the Longhorn release of Windows and its application development framework codenamed Indigo are to incorporate Web Services-based interoperability at every level in the Windows environment (even among Windows applications on the same box), not just between Microsoft and non-Microsoft-based applications. Portability, however, poses a threat to Microsoft, because it means that application functionality written on a non-Microsoft system could be ported to a Microsoft system, and vice-versa — cracking the shell of Microsoft’s dominance on the desktop, and increasing dominance of the server infrastructure. If it were a simple task to take a Windows-based app and port it to Linux, say, then there would be a good reason for Microsoft to be afraid. Thus, Microsoft can only support distributed computing paradigms that center on the notion of interoperability, rather than portability.
For Sun, the situation is the opposite. Portability is at the core of their software strategy, because it underlies their plans for Java. Sun hopes to seed as many systems as possible with JVMs — not just computers, but also mobile devices, peripherals, and all manner of high tech gadgets. In Sun’s perfect world, every high tech device would have a JVM that supported seamless portability of Java-based applications across all form factors and operating systems. Interestingly, then, true interoperability is a threat to this vision of “Java everywhere,” because as more applications interoperate through standards-based interfaces, they no longer require the common runtime environment that Java provides. After all, if your Java app interoperates with my .NET app, then why do I need to run a JVM at all?
Pros and Cons of the two Approaches
Nevertheless, in spite of the dichotomy between interoperability and portability that might threaten the Sun/Microsoft relationship, there are broad gray areas where interoperability and portability complement each other. This clarity is particularly notable when the pros and cons of Web Services-based interoperability and Java-based portability are stacked up against each other:
|
Web Services-Based Interoperability |
Java-Based Portability | |
|---|---|---|
| Pros |
Loose coupling between Service consumers and producers Coarse-grained Service interfaces Contract-based development Appropriate for heterogeneous platforms and operating systems Imposes no requirements on runtime Useful in environments of frequent change |
High levels of programmatic control High network performance Works well in occasionally connected situations Reduction of coding necessary in multi–device scenarios Greater control over data validity |
| Cons |
Poor performance due to XML overhead Limited programmatic control Limited use in occasionally connected situations Limited enforcement of data validity |
Tight coupling to runtime environment Heterogeneous environments a challenge (“write once, debug everywhere”) Less flexible in environments of frequent change |
Basically, the loose coupling and agility benefits of Web Services come at the expense of increased overhead and limited programmatic control. By limited programmatic control we mean that a Web Service consumer doesn’t have the ability to change the internal programming of a Service without sacrificing the loose coupling benefit, while in the Java world, developers can change an application any way they like and distribute the new version to users.
The Best of Both Worlds
The table above clearly indicates one situation where solutions that combine interoperability and portability make sense — the occasionally connected application. Whether on a PDA, cell phone, or roving laptop, applications may not have continuous access to Web Services located on a network somewhere. Distributed computing infrastructures that resolve this problem by offering portable applications that interoperate when connected have a clear opportunity here. (Whether Java is the best choice for building mobile applications is another question.)
However, there’s a much broader story about Java and Web Services that is important to tell. After all, isn’t Java a great language and platform for Web Services? The answer is of course, just as C#/.NET, perl/Linux , COBOL/Mainframe, or other language/runtime combinations have great value propositions for building Web Services. Ask either of the two leading Java application server vendors whether their platforms are suitable for Web Services, and they will tell you not only that yes, they are, but also that Web Services are what their application servers are increasingly being built for. The point is that Java is great for building interoperable applications that must operate reliably in both tight coupled and loosely coupled scenarios, but portability is no longer a required core value proposition for such applications, because the interoperability promise of Web Services and SOAs offers a broader value proposition to a wider range of customers.
The ZapThink Take
So, if IBM and BEA Systems are fine with emphasizing the interoperability benefits of building Web Services with Java while deemphasizing its “write once, run anywhere” portability message, then why isn’t Sun latching onto that same message? The fact of the matter is that the new relationship with Microsoft marks a critical crossroads for Sun. Their first option is to separate the portability message from the core Java message, relegate portability to a benefit for occasionally connected systems, and jump whole hog into the interoperability value proposition of Web Services. This option leads to a great business opportunity for mobile Java and a solid relationship with Microsoft that can truly threaten their joint competitors. Or, Sun might take their second option, which is to continue to run with their core portability message, even though it contradicts the interoperability story that they and Microsoft have been touting. If Sun takes this road, they risk falling out with Microsoft and ceding their Java leadership position to IBM and/or BEA once and for all. In either case, Sun must evaluate how to position itself in the new universe represented by its newly minted friendship with Microsoft.