October 04, 2004

interop vs. portability

A couple entries from Tim Ewald and Michi Henning.

This old discussion between Don Box and Michi from 1999 is particularly telling, as well. In hindsight, I think they were both right. Protocol-oriented interoperability is the right way to go, but code portability is nice, as the success of J2EE has shown. But in a market-based software development world you really can only focus on interoperability or portability -- not both, or else you'll get the two confused. Plus, QoS & productivity is all that vendors have to compete on! One could forsee an open source solution that gets both right, perhaps...

My experience in complex environment has made me realize the ineffectiveness of portability in many circumstances. For exampe, JDBC, ODBC, etc. all claim "database SQL portability", but in practise the differences between concurrency models, performance, and features between DBMS vendors is so large that "SQL portability" is quite useless for most interesting applications. Packaged software applications like SAP or Siebel are crappy database users for this reason -- they wrote generic SQL instead of tuned, specific SQL.

Secondly, I would say the whole reason Microsoft has jumped behind XML is that they've bit the interop bug -- they'll be a good citizen of IT from now on, but they'll be damned if they'll reduce your switching costs -- once you go .NET, you're stuck with .NET.

Thirdly: J2EE seems to have hit an interesting sweet-spot here. It's almost like it's gone down the path of SQL. You get decent (not perfect) portability, proprietary features are reasonably isolatable, and it richly supports the interoperability of XML. Now of course, vendors are adding features to the software stack that are non-standard, such as BPM, Portals, etc. But even there are JSRs awaiting these features, promising code-portability.

So for those people that care primarily about portability (BTW -- Do such people really exist? Can people really claim they care more about switching costs than functionality and productivity?), 90% vanilla J2EE will have to suffice. For those that care primarily about productivity, either LAMP, modern Java frameworks (i.e. BEA Workshop, Struts, JSF, PicoContainer, AspectJ, etc.) or .NET will suffice.

Posted by stu at October 4, 2004 01:12 PM
Comments
Post a comment