ECMAScript gets XML

Better known by its original name of JavaScript, ECMAScript will soon be gaining XML extensions, according to a press release today from ECMA International, the standards body that took over responsibility for JavaScript from the original creator, Netscape.

E4X (ECMAScript for XML) adds native XML support to the browser-based scripting language, which web designers use to add client-side functionality to web pages. According to the release, BEA led the initiative that resulted in agreement on E4X, and plans to release a "publicly available implementation" for developer feedback. Brendan Eich of Mozilla.org, which inherited Netscape's browser code, neatly summarizes why the announcement is significant: "As more script authors encounter XML data, they will want exactly what E4X provides. This is a useful and innovative extension for developers across the Web.”

Personally, I feel that the sooner we have decent, solid XML support in popular web programming environments like JavaScript, PHP and Flash, the better it will be. While we're at it, how about an XML database that web hosting companies are as happy to support as mySQL? Imagine if, in a year or two's time, it becomes within the reach of every web designer to write applications that can hand off data between Excel, JavaScript, a hosted web server and remote services. It would unleash a torrent of creativity that hasn't been seen since the early days of JavaScript and Java itself.
posted by Phil Wainewright 12:52 PM (GMT) | comments | link

The tortuous path to SOA

Everyone seems to be buying into the concept of moving to service-oriented architectures, but it's probably going to be a good few years before any large organization has actually completed the journey. ZDNet's David Berlind describes some of the hurdles that have already been identified, reporting on a workshop discussion at Gartner's IT Symposion in San Diego this week:

• "Legacy applications do not give you an easy path to services-oriented applications ... understanding your legacy and how it can work in an SOA in a much more detailed way is something that all companies need to master."


• "Migration to an SOA could represent job changes for some members of your IT staff" (and offshore outsourcing of non-domain tasks).


• "Such a massive undertaking affects not only the IT department but the entire business ... The IT department has to know that the entire company is excited about the change such a move represents."

David doesn't mention how delegates felt as they left this workshop, but I suspect many of them may have decided to put SOA on the back burner, rather than forging ahead with a project that will a) disrupt legacy applications b) shake up the career paths of key IT staff and yet c) requires a huge evangelism drive across the enterprise.

The growing buzz around SOA is just another of those interlinked hype cycles that are going to disrupt the evolution of loosely coupled systems over the next few years. We're in the early stages (not mentioned on Gartner's hype cycle charts) when analysts start coining slick phrases that go along with the hot new concept — Gartner web services evangelist David Smith came up with "service-oriented thinking" in a talk this week. The next stage is that vendors will put SOA into their marketing messages, and the media will pick it up. Eventually, a few organizations will be emboldened to venture ahead with SOA projects, and the horror stories will start to emerge about the tough challenges they face.

Meanwhile, most organizations will be following a haphazard, unplanned path to SOA:

• Ad-hoc adoption of web services technology for application integration.


• Emergence of composite applications that connect multiple systems in unforeseen ways.


• Retroactive implementation of management systems to monitor the above.


• Dawning realization that adopting SOA might forestall a lot of this firefighting.

Which is better? You may feel that, if you're going to have to end up adopting SOA anyway, you might as well start off on the right foot. But it practice, it'll be pretty much impossible to sell it to the organization until the need becomes more evident to everyone involved. That's why most organizations will be following the piecemeal, unplanned approach.
posted by Phil Wainewright 5:08 AM (GMT) | comments | link

Microsoft embraces distributed services

Last week's announcements by Microsoft's business software division demonstrated just how far things have progressed since Bill Gates decided the company would be toast if it didn't "embrace and extend" the Internet. Although at times it didn't look as though Microsoft was going to make it, its current strategy around XML web services really seems to have started to pay dividends — even if Redmond hasn't been able to set the agenda quite as extensively as Bill Gates initially would have wanted.

I've written at more length on this in my ASPnews column this week, but to summarize let me highlight here the four key ways in which I believe Microsoft is now ahead of the game with the Business Solutions offerings it's now preparing to launch:

• Rich client diversity, ranging from letting users work directly with XML data in Excel, all the way to web services clients that will run on mobile phones.


• Using a blend of on-site software and online services, according to which does the job best, with no religion either way.


• Allowing data to flow across the network, and letting users take charge of those data flows.


• Decomposing monolithic applications into loosely coupled, easily reconfigured pools of functionality.

It seems hard to believe, but I don't see any other vendors embracing the service-oriented concept quite as radically as this. I suppose it helps if you have a proprietary architecture of your own (ie ..NET) that you can base it all upon, but that still doesn't lessen the magnitude of the achievement.
posted by Phil Wainewright 11:11 AM (GMT) | comments | link

Orchestration, choreography and cohesion

In matters of business process, choreography is a bit of a sideshow. So it doesn't really matter whether or not Microsoft takes part in the W3C working group that it walked out of last week. Microsoft has already independently agreed a set of specifications with IBM and BEA that is rapidly becoming a de facto standard through market adoption. According to Jeff Schneider, CEO of Momentum Software, it's already there: "BPEL4WS won — there is no confusion about winners — just confusion about who lost."

I think Jeff may be right about BPEL4WS. But he's wrong to imagine that's the end of the story. BPEL, as its name suggests, is only concerned with the execution of business processes. This means it comes into play only after you've defined what the processes are going to be. You still need to model the processes, provide a framework for them to interact with each other, and co-ordinate the resulting activities.

Choreography (some people prefer to call it orchestration) provides that framework for interaction and co-ordination, going further than BPEL4WS and its companion WS-Coordination on their own. So why do I call it a sideshow? I believe the concept of choreography is fundamentally flawed.

The trouble with virtually all the business process frameworks that have been proposed is that they're too enterprise-centric. There's still this notion of a central controlling character somewhere, pulling all the levers. It's implicit in the very words used: orchestration and choregraphy both assume a conductor, composer or artistic director who's carefully designed the composition and whose hidden influence is holding it all together. In a single enterprise, that's often no bad thing, and it sells well to enterprise managers, who are rarely comfortable with the notion that they don't have a clue what's going on at any given time. But it's not compatible with a truly flexible business process architecture, and it utterly breaks down when you try and co-ordinate processes outside of the enterprise in a multi-party B2B environment.

In the real world, business processes are executed by people with delegated responsibilities for their actions, who have freedom of choice within certain guidelines. This is true even within a corporation, but even more so when processes cross multiple independent businesses. The only realistic framework for automating the interactions between each of those individual agents is one with the lightest possible co-ordinating touch. The best analogy is musical or dramatic improvisation. None of the players knows their lines in advance. Instead, each individual is free to improvise within certain rules of harmony, rhythm and behavior, thus preserving the coherence of the overall performance.

The principle of autonomous behavior is built into algorithms that underpin several business process execution platforms. It can be expressed mathematically by a form of algebra known as pi-calculus, which Microsoft has built into its BizTalk platform, and which BPMI.org developer Intalio has built into its BPML-driven systems (indeed, all the BPMI.org specifications are based on pi-calculus). But if the process framework hasn't been designed to allow autonomy in the first place, then the platform can't insert it.

The only specification, to my knowledge, that explicitly caters for this lightest of co-ordinating touches in its interactions is business transaction protocol (BTP) from OASIS. Its concept of 'cohesion' is the word that best sums up this light co-ordination between autonomous participants. And that, in my view, is what standards bodies should be focussing their attentions on rather than more directed notions like choreography and orchestration. A little cohesion would resolve most of the remaining differences that separate the various parties.
posted by Phil Wainewright 5:58 AM (GMT) | comments | link

Lipstick applied to an old face

The above phrase didn't make it into the final version of David Longworth's latest article, Radical promise of BPM, but it comes to mind in relation to Commerce One's launch last week of its new Conductor platform. The vendor's makeover deploys web services as a platform for B2B integration and the development of composite applications, and BPM is one of the buzzwords Commerce One is keen to latch onto.

A Line56 article quotes Current Analysis analyst Shawn Willett saying that "lots" of Conductor's 11 pre-launch adopters are "attracted by the BPM piece" of the Commerce One offering. (Interestingly, the list includes Eastman Chemical, one of web service networking vendor Grand Central's earliest customers, perhaps indicating that Eastman now aims to bring in-house some of the capabilities it has previously relied on Grand Central to provide).

But as David's article makes clear, if you talk to some of the leading figures in BPM, the one thing they don't do is provide application integration platforms. If that's what Commerce One is promoting as the foundation of its BPM capability, then it's guilty of what Howard Smith, co-chair of industry body BPMI.org, warns of in the article: "Many companies are describing their products as BPM when what they're really doing is relabelling existing products".

True BPM provides a mechanism for linking processes irrespective of the underlying application infrastructure. It's not about integrating software, it's concerned solely with integrating the business activities that run on top of the software. This aspect of BPM is something of a radical concept in IT, which makes it difficult to get across to the average IT buyer, and the vendors need to do a better job of articulating that message to differentiate themselves from the pretenders that are leaping aboard their bandwagon.
posted by Phil Wainewright 1:59 AM (GMT) | comments | link