The Babel Paradox

The syndication format RSS provides a microcosm of the problems XML will face in the future, because it's the first truly real-world deployment of XML. I know that's a bold statement to make when there are many serious commercial applications of XML in the e-business world. But all of those deployments follow a model in which you first of all define your vocabulary (your XML schema, your DTD, call it what you will), and only afterwards do you build your infrastructure and start communicating.

Real life just doesn't work like that. People coming from different perspectives all have their own different meanings for individual words and concepts. People's needs and understandings shift over time. Unintended consequences occur. A predefined vocabulary with definitions that are set in stone becomes a straightjacket that kills agility and responsiveness.

That's the root of the problems with RSS, which doesn't have the rigorous central definitions of heavyweight XML implementations like, for example, ebXML. That's why I call RSS the first truly real-world deployment of XML, because it's the first one that's really confronted the problems that arise when you get broad adoption of a common XML vocabulary. The problem is, it ends up meaning different things to different people.

Jon Udell, who's one of the three members of the advisory board set up last month when Userland Software transferred ownership of RSS to the neutral Berkman Center for Internet & Society at Harvard Law School, has been manfully grappling with some of these issues this week. He's been recording some of the exchanges and discussions in his weblog, culminating in an insightful entry today, An RSS/RDF epiphany, which explores the role that RDF might play in bringing external XML vocabularies into RSS (or indeed into any XML document, whatever its core vocabulary).

RDF, on which the W3C's Semantic Web project is based, acknowledges the mutability of definitions, and attempts to solve this problem by creating a hierarchy of definitions that theoretically can always transform back to the intended meaning. It's a courageous attempt to resolve the challenges of nailing down shared meaning, but its fundamental flaw is the assumption that there always is a canonical meaning somewhere, if only you could pin it down. Wittgenstein, as I've mentioned previously, long ago established what a chimera that notion is: "If rules are simply verbal formulae, what the rules 'mean' can always be contested."

This is why I'm calling this the Babel paradox. According to the biblical story of the Tower of Babel, the peoples of the earth became so powerful by speaking a common tongue that God came down to earth and destroyed their unity. But the paradox is that they were never as powerful or as unified as they believed themselves to be. Soeaking the same language doesn't mean you share the same perceptions, values and motivations. It wasn't God that scattered them into separate tribes, but their own lack of common cause in the face of adversity.

The Babel Paradox is that humanity can never have one language. Each individual has their own perception of the world. All communication is compromise. We are forever loosely coupled.

That's not to say there isn't a solution to these challenges. But we need to understand the true nature of the problem. The only truly workable solution will be one that accommodates uncertainty, imprecision and change. RSS is proving to be a wonderful experiment in establishing the extent of those factors in the first really global real-life implementation of XML. If we can solve it for RSS, it will be a cornerstone achievement.

UPDATE: Traduction française. Omar Rabhi has very kindly translated and published this posting in French on his weblog. Interestingly (and in further illustration of my point), the French for 'loosely coupled' is faiblement couplé, which literally means 'weakly coupled'. They do this because the direct translation lâchement couplé would imply a cowardly, contemptible liaison. It looks like French advocates of SOA are going to have a hard time selling the benefits of loose ('weak', 'cowardly') coupling.
posted by Phil Wainewright 1:40 PM (GMT) | comments | link

All paths lead to management

Bridging between J2EE and .NET isn't about tools, it's about infrastructure. This week we publish an article looking at how companies are bringing the two environments together, and it may come as a surprise to find that connecting web services between the two isn't difficult. But connecting the supporting infrastructure is quite another matter.

This just reinforces the message that deploying web services isn't something you can afford to let happen spontaneously. Web services are a great way to solve point-to-point integration problems, but if you leave it at that then you're just stoking up problems for later on. The difficulties come at the infrastructure level, when something goes wrong and you can't find the cause, or when multiple services need to be joined together in a process and suddenly you discover you haven't got a shared messaging infrastructure they can all use.

I had imagined that our J2EE/.NET article this week was going to be a change from the web services management theme of the previous two weeks' articles. In the end, it's just been a reminder of the importance of getting up to speed on services management.

On that note, CBDI Forum published an excellent commentary this week on web services management. This short item succinctly highlights all the vital issues:

• A concise comparison of the two proposals just submitted to the WSDM committee at OASIS


• The positive impact on the timetable for standards definition


• Performance considerations as the main arena where vendors will differentiate competitively.

Fortuitously, there's been a sudden outbreak of news stories about J2EE and .NET. Microsoft is rumored to be preparing a heavyweight version that will compete with J2EE for mission-critical deployments. The Apache Foundation has launched the Geronimo project to create an enterprise-class, open-source J2EE platform. In other words, Microsoft is moving .NET upmarket while Apache lowers the entry-level cost of enterprise-class J2EE.

Moves like these will make it increasingly unlikely that any enterprise of any substance can enforce homogeneity on one or the other within its organization (even if that were desirable). That makes it all the more important to plan for a web services infrastructure that will support and manage both.
posted by Phil Wainewright 8:24 AM (GMT) | comments | link

Integration, reuse and assembly

It's good to see BEA promoting the message that development and integration are one and the same thing. The notion of reuse only has any value if it allows companies to use existing software assets without having to start over and rewrite them from scratch. Therefore it logically follows that, if you develop with the intention of reusing existing assets, you're going to have to integrate them into your new applications.

BEA's chief marketing office Tod Nielsen ("We believe that integration and development will become one") should go one step further and add the word 'assembly' into his vocabulary. Too often, integration is assumed to apply 're-development' — the existing software components are individually modified to make them compatible with the new application. That's not a very scalable approach, of course, because each separate integration requires a new modification, and sooner or later something will break.

Assembly regards each element of the application as a service rather than as a component, and adds them into the new application without requiring internal modifications. Although the application supports integrated processes and workflows, the underlying software is loosely assembled rather than tightly integrated.

Another way of looking at this is to divide development into two completely separate disciplines:

• Software development is the creation of new software code that executes a unique function.


• Applicaton development is the assembly of those individual functions, bundled as services, to automate processes for users.

Once you've made that distinction, you can create the useful rule that application developers should never write software. Either they reuse some existing functionality exposed as a service, or if they really can't find what they need, they request a new service from the software developers. This seems to me like an excellent way of encouraging maximum reuse.
posted by Phil Wainewright 2:12 AM (GMT) | comments | link