ESB everywhere?

With all eyes focused on Microsoft's Professional Developers' Conference in Southern California, few people have noticed webMethods reinventing itself at its own conference across the country in Florida.

The former poster child of EAI is now calling itself "the industry's first web services infrastructure company." The claim is a little specious (which industry does it mean? Has it not noticed that dozens of web services infrastructure companies already exist?). But there can be no doubt about the strength of its determination to recast itself in a web services mould; and its portfolio has grown so fast in recent weeks that it is indeed in danger of having the most complete web services infrastructure offering of any vendor.

This week's additions include a pair of products that, in any normal circumstances, ought to be anathema to any self-respecting EAI vendor:

• WebMethods Express is a low-cost, standards-based tool for point-to-point integrations. It's designed for use in small projects or by budget-constrained businesses. (According to a report in Computerworld Hong Kong, it's particularly targetted at Asia's cost-conscious smaller companies.)


• WebMethods JMS+ is a message broker based on the JMS messaging standard. When used together with Express, the two products create an Enterprise Service Bus (ESB).

Last time I was speaking to an ESB vendor (the likes of Sonic Software, Polarlake, etc) they were telling me that ESB was an idea that's set to obsolete traditional EAI platforms. WebMethods has obviously decided to follow the old adage, 'If you can't beat 'em, join 'em,' and come out with its own ESB.

That's all very well, but how does that fit in with what most of webMethods' customer base have got in place at the moment? Is webMethods recommending they rip it all out and replace it with the vendor's brand new range of low-cost alternatives? Customers would not be pleased to hear such advice, so instead webMethods is carefully maintaining a party line that its new ESB offerings are but a stepping-stone towards its more expensive conventional offerings.

"A significant number of customers ... do not require the breadth and depth of functionality that is found in the webMethods Integration Platform," says Kristin Weller, executive vice president of product development. You bet they don't. Over time, that small but significant number of customers could well rise close to 100% of the total. WebMethods is making a smart move in allowing them the choice of doing so within its product range, rather then forcing them into the arms of upstart competitors.

Meanwhile, webMethods has shown further cunning in its use of partnerships to pursue certain technology directions that are no longer strategic for its long-term survival. This allows it to stay competitive in these smaller, more specialized (or sometimes just plain dead-end) markets without being committed to major product development costs.

Back on the other side of the North American continent at Microsoft's conference, the ESB acronym was not much in evidence. But Sonic's David Chappell reckons the concept lies at the heart of Microsoft's vision for application-to-application communications in the next version of Windows, in the form of a component codenamed Indigo. "From what I can tell," writes Dave, "[Indigo] combines messaging, Web services, and SOA. Sounds like an ESB to me." He follow this up with a catalog of quotes about Indigo that add up to pretty convincing case, including this from no less than Bill Gates himself: ".. a Web services communication bus built into the OS."

It is telling, though, that a bus that is quite unashamedly 'built into' an OS qualifies for consideration as a quasi-ESB. Of course, the reason why Microsoft wouldn't go around calling Indigo an ESB is that one of the characteristics of current-generation ESBs is that they're all based on Java messaging. ESBs will only really be worthy of the name when they can transcend individual environments, be they Java or Windows — in which case they will be some form of web services bus, which implies a need for a different acronym.

Whatever you call them, though, and whatever standards-based messaging they end up being founded on, there's no doubt that they're becoming more prevalent. When vendors converge on the same concept from such different points of origin as Microsoft and webMethods, it strongly suggests that it's emerging as something worth rallying round.
posted by Phil Wainewright 12:37 PM (GMT) | comments | link

Pandora's desktop

What demons will be unleashed if information workers gain complete access to real-time enterprise information at the desktop? We may start to find out within a year or two. We already know many of the obstacles and pitfalls that will beset us along the way, thanks to the efforts of pioneers who've set out to remove those barriers. Several of them get a mention in this week's Loosely Coupled feature article, Integrating information at the desktop. Some of the most challenging barriers are:

• Security. You can't do it without a distributed identity infrastructure that allows you to manage information about who has access to what resources, and at what levels of authorization.


• Standards. Your systems need to be speaking the same standards, or if they're not, your systems infrastructure needs to be able to translate reliably between them.


• Speed. Real-time means subsecond response times between machines, and within a few seconds when delivering to users. That requires a powerful information delivery infrastructure.


• Semantics. Data gets labelled in different ways in different contexts. You can't combine data from different sources unless you've already reconciled those different meanings.


• Service views. These crucial building blocks define the resources that are available to be combined into meaningful information.


• Usability. None of this is any good if no one knows how to make use of it.


• User acceptance. The final barrier is making sure users know what they're doing and why they're doing it. By definition, you're giving them something they've never dealt with before. How will they know how to handle it?

I'm gratified (though not surprised of course) to find the notion of loose coupling recurring again and again when people talk about these new approaches. Indeed, it's so central and familiar to people in such circles that my notes [with my emphasis added] show they've begun to create new verbs and adjectives from it:

• "What we've built is the definition of loose coupling," says Jim Green of Composite Software. "We've loose-coupled the application logic from the historic details of the data."


• "Everyone has this loosely coupled notion of web services," one customer told Westbridge Technology's Kerry Champion, "but [continued the customer] we're actually seeing some tensions between achieving loosely coupled-ness and maintaining an adequate security dimension."

posted by Phil Wainewright 7:12 AM (GMT) | comments | link