What's the use?

The biggest killer app of all for XML would be one that persuades the vast mass of users to structure their content in meaningful ways. It just needs to hit the right mix of incentive and access — incentive in the form of a payback that rewards the extra effort required, and an easy access path that keeps that initial effort as small as possible.

What I find frustrating as a user is that I can already see dozens of potential killer apps for XML, each of them offering huge potential payback. Count me in, I'm incentivized. But I've been frustrated in my attempts to identify easy access paths to any of them.

Take XHTML. My company is currently working with web designer Quinn Interactive to redesign the Loosely Coupled website. We already have a great new logo, thanks to Phil Quinn and his colleagues. Soon, we'll have a great new look to go with it, and of course we've opted for a fully CSS-driven, XHTML-compliant design. Adopting XHTML gives us huge extra flexibility in how we manipulate, present and syndicate our content to our readers and users, particularly if we use the format's built-in capability to mark up our content in a semantically meaningful way.

The catch is that there's very little guidance around as to what represents best practice in semantic markup of web content. Yes of course there are a handful of well-known schemas, most notably Dublin Core. But with no established body of best practice to refer to, how can we tell which ones are the popular ones and which ones are not worth a second glance? You have to either become or hire an expert before you can work out which elements of which schemas to use, and in what contexts. Is it any wonder, then, that no one is really exploiting the potential of XHTML for meaningful markup of content?

To my mind, this is yet another case of technologists coming out with technology and then not bothering to do the documentation. It's no good dismissing uninitiated newbies with a cry of RTFN (Read The Friggin' Namespace). We need more than pointers to schemas, we need catalogues of schemas, explaining which ones work where and which ones are up-and-coming. We need online documentation, with helpful tips from early adopters, like PHP's online manual. And we need use cases, lots of use cases, so we can 'view source' and see how others have done it.

The other thing we need is approachable tools, and we need them now. Simple, reliable, adaptable tools for reading and writing valid XML, and which allow us to add or delete our own schema elements, so we can start playing around with all those killer-app capabilities of semantically tagged content. Jon Udell drew attention to some of the potential of XPath a few weeks back, while noting how, "from a user's point of view, XPath query strings are pretty darned geeky." Yet if you can find a way of putting the capabilities of XPath into the hands of a smart writer like Jon, then "as you're writing the XHTML, the search possibilities begin to guide your choices" in how he structures his XHTML markup. If only someone would give us the tools.

Now, to cap it all, there's a new attempt to redefine RSS. The one good thing to be said about the Echo Project is that it's got a lot of use examples already. You can learn quite a lot about XML best practice just by having a look around at the markup samples put forward by this assortment of leading XML geeks. Nor do I think it's necessarily a bad thing to have a new, weblog-centric content and syndication format that redresses some of the shortcomings of existing formats. My favorite suggestion so far, for example, adopts the XHTML format of identifying elements with an "id" attribute, whereas RSS uses a separate "guid" element. But that doesn't change the fact that this is all a distraction from the fundamental issue, which is not the underlying structure but the usability of RSS and XML.

It really is a complete nonsense to imagine that, if only the techies could get the definitions right, then all the barriers to widespread use would be overcome. As Wittgenstein pointed out some time ago, the expanding universe of potential meanings will always outstrip the creation of rules to define them. It's not rules that are lacking, but ways of sharing the meanings. Access is the key — tools, examples, explanations and education. As soon as it becomes easy to exploit XML, then believe me, people will very quickly start mining its potential, and in amazing ways that we haven't even imagined yet. It's time the techies stopped talking about how wonderful all this stuff could be. I wish instead they would just make the effort to show the rest of us how we get started.
posted by Phil Wainewright 2:46 PM (GMT) | comments | link

Degrees of hype

When BusinessWeek runs a special report devoted to web services, you know the concept's reached the mainstream. But is this just hype, or is it the more mature "slope of enlightenment" that, in Gartner's hype cycle model, precedes productive deployment of a technology?

Earlier this year, I reported the observation that three separate groups of people are at three different stages of the web services hype cycle: "IT architects and business strategists may still be climbing towards the peak of hype, even while developers descend the slope of Dilbertian disillusionment that lies beyond." I think it's since become clear that the architects are off on their own SOA hype cycle (of which more later). But are business people about to indulge in the same unrealistic and irrational exuberance over web services? I don't think so.

I believe that, although concepts like web services and SOA are rippling in characteristic hype patterns through the techology community, we won't see similar hype about them in the business community. That's because the business community has had its own hype cycles, in comparison to which the hype around web services and SOA are little more than tiny after-ripples. Far from being empty bubbles, for business people these after-ripples are in fact the stirrings of enlightenment that come before the "plateau of productivity". Look back over the past few years and you can see that concepts that at one time were surrounded by exuberant hype among business people and investors are now reaching the mainstream with serious technology underpinnings:

• Application service providers (ASPs) have mostly disappeared, but now we have on-demand computing


• Internet data centers boomed and busted, but now we have server virtualization and utility computing


• Ecommerce exuberance gave us the dot-com frenzy, but now distributed online services are becoming an established feature of commercial activity.

I could refine this list, but the main point I'm making should be clear by now. Everything that's happening in on-demand, web services, SOA and the like may have a certain element of hype about it, but there's substance underneath, and the more important trend from a business point of view is that these technology concepts are actually delivering a realistic, pragmatic realization of the visions that drove those earlier peaks of expectation.

For business people, then, this is the real thing. But although nobody's going to get so excited they'll go soaring off into the blue yonder, there's still a hill to climb, and some technologists may find they get carried away from time to time. SOA is my case in point, but I think grid computing (as Sun's John Gage has just warned) and WiFi will also prove to be examples where the hype temporarily exceeds reality and a minority who invest too far, too fast, will get their fingers burnt.

The reason I cite SOA is because I was sitting listening to presentations at Infoconomy's very useful Agile Business conference yesterday, and it suddenly struck me. Everyone is talking about how important it is to encapsulate every component of enterprise computing as a service. It's assumed as a given. But then what? All the vendors are talking as though that's the destination, but it's not. That's just base camp, when the hard work of managing, co-ordinating and asssembling all those services actually begins. BEA chief architect Adam Bosworth, interviewed by Business Week, highlights one aspect of this that's often overlooked:

"... as soon as you say that anything you deliver is a service, it has to run robustly. Imagine if you went home and your electricity was out periodically — you'd be very upset. With a utility, you expect utility-like performance. You expect it to run 24 hours a day, seven days a week. You also expect to always have enough [capacity] on tap ... Dynamic, on-demand hardware will probably take a few years. But when it arrives, web services is really going to live up to its potential. Then, anyone will be able to sell any specialty that they have as an on-tap, as-much-as-you-want-to-drink utility."

That innocuous little phrase "... will probably take a few years ..." says it all. Anyone who implements SOA without realizing what they're letting themselves in for is heading towards a very bruising fall into disappointment and despondency. There are major challenges ahead in adapting to a service-oriented way of doing things, and various tools and techniques will get their share of hype along the way. But these will be hype phenomena that technologists experience alone. When they pick themselves up again and get on with delivering and managing those services effectively, then business people will be delighted to find all their earlier ebusiness visions finally starting to come true.
posted by Phil Wainewright 2:25 PM (GMT) | comments | link

Loosely coupled EAI

New buzzwords may help to generate excitement about the latest developments, but they also often mask the continuity that lies behind them. One buzzword that's cropped up a lot lately is 'composite applications', and today Loosely Coupled publishes a feature taking a closer look at them: Composite approach lifts integration woes. But if you read the article, it becomes clear that composite applications aren't really anything very different from everything we've already written about here on Loosely Coupled. It's just a handy term for expressing a more loosely coupled approach to EAI, one that's founded on web services and SOA.

In truth, all our buzzwords seem to converge within the concept of composite applications. There's an underlying services architecture (SOA) based on web services (XML, SOAP, WSDL, UDDI) that requires a separate integration layer allowing communication between the various applications (that's ESB — enterprise service bus). It all has to be managed of course (services management). Overlaid on top of this technology infrastructure there needs to be some system for co-ordinating the interlinked processes (orchestration, choreology, BPM), while the assembled functions and information need to be presented to users in an integrated way (portal, rich client).

You can think of all this as new, or alternatively you can see it as just a new answer to an old problem. We're still trying to link enterprise applications together (EAI). We're just trying to do it in a more agile, adaptable and on-demand way (loose coupling). Sometimes, it makes more sense to show the continuity and progress that lies behind what we're trying to achieve, rather than aiming to show it off as the latest untried and untrustworthy new thing.
posted by Phil Wainewright 7:43 AM (GMT) | comments | link

Platform neutral

An up-and-coming new acronym is ESB, for enterprise service bus, which is a messaging infrastructure for connecting diverse resources within a service oriented architecture. Ronan Bradley of PolarLake has written a useful overview of why the ESB concept is important for web services, which WebServices.Org published to coincide with PolarLake's launch last week of its own ESB product. His final paragraph neatly summarizes the importance of having a neutral integration layer:

"It mediates the document exchange between the systems integrated. The mediation consists of validating the document, against both technical and business, transforming the document into the format required by the recipient, gathering other information required by the recipient and most importantly: handling exceptions, ensuring that they are dealt with appropriately, and also insulating the recipient from incorrect information. "

This is all very well said, but the one thing I wonder is why Ronan insists that this integration, while not being tied to a specific message oriented middleware (MOM) product, must be founded on Java Message Service (JMS). Actually, I don't really wonder, since PolarLake's product has precisely these characteristics, so it's his job to say that's the best combination. Another ESB proponent is Sonic Software, who I've previously praised for their ESB stance — see It's better by bus. Sonic's product, too, uses JMS as a foundation.

Clearly JMS is a popular choice. It's stable, it works, and it interacts very happily with J2EE servers, on which a lot of web-facing applications get built these days. But there are other alternatives. One of them is ebMS, the messaging component of ebXML, which also rather impressed me recently. However I was taken to task for this both by Doug Kaye and by John McDowall, while others emailed me.

For all its merits, JMS is tied to Java, which means it doesn't have the neutrality that a truly universal ESB needs to have. Likewise, ebMS, although it doesn't have to be used with ebXML, depends on the latter for all those higher-level mediation capabilities that Ronan Bradley cites as essential ingredients of an ESB. True platform independence will only be achieved with an infrastructure that's founded entirely and exclusively on XML and XML-based standards. Unfortunately, this means that anyone who wants a truly platform-neutral ESB is going to have to either build their own or turn to a third-party provider, neither of which is likely to be very satisfactory in enabling interoperability with other ESBs.

The important truth to grasp here is that the more we move towards interoperable service-oriented architectures, the more layers of platform dependency we're going to have to peel away. Moving to a JMS-based product, for example, will free an enterprise from being tied to a specific MOM infrastructure, but still leaves it tied to Java. True neutrality depends on achieving a level of abstraction from individual platforms that many vendors will be reluctant to support. And until standards have been agreed and best practice has become well established, many enterprises will find it onerous to maintain that degree of independence.
posted by Phil Wainewright 10:51 AM (GMT) | comments | link