A Programming Model v A Data Model

There's been criticism of Java EE's complexity recently, but any enterprise-level system will be complex because it serves the needs of a particular customer base. This article gets to the bigger issue: the Java story is a common binary execution format, which gives portability, while the SOA story is a common text interchange format, which gives interop. Since the OO Way is to start with the entities, it's hard to object to a data-centric view of programming - which conveniently leads naturally to a focus on interop. But for the article to dismiss portability in favour of interop is wrong, I think, because no-one stays on the same hardware+VM implementation forever. Portability is the basic "ility" on which sit the others, including interop.

Moreover, the article expounds a peculiar anti-VM approach that I can only imagine is aimed at the CLR as well as the JVM:

Fundamentally, the virtual machine approach to distributed computing is through the serialization of objects leading to remote method invocation, while SOA runs on the exchange of messages between services with contracted interfaces.

It's true that IIOP gave binary wire formats a bad name, but there's no reason why a (Java/C#) VM can't have a mapping layer that converts serialised objects to XML messages, and vice-versa. We just need a canon to help practitioners overcome thorny but arguably avoidable XML-OO mapping issues.

PS JoelOnSoftware has an entry today promoting functional programming techniques for scalability. Prime among them is first-class functions, i.e. treating code as data. On some level, this gels nicely with SOA's data-driven approach...how long before we see an enterprise service bus that can transport code-as-data in messages? (This is what Alex and Karen's Distributed Java project does, though they're atop a binary wire format.)