IBM's 'on-demand' computing: Smoke and mirrors?

"On demand" is IBM-speak for a secure transaction and workflow-enabled service-oriented architecture (SOA), which itself is marketing-speak for Web services, which in turn is marketing-speak for a collection of protocols (very few of which are officially standards) that make the integration of dissimilar systems via remote procedure and data calls possible. Can we abstract this any further?

Last month, IBM started beating the "on-demand computing" drum, claiming that no other solution provider was capable of delivering it--whatever "it" is. My colleague Dan Farber recently wrote about how IBM uses the term "on demand" to encompass a potpourri of terms, including open standards, self-managing, secure, flexible, dynamic and lower costs.

I decided to peel this onion a bit further to find out exactly how IBM justifies its claim to be light years ahead of the competition. I asked Big Blue's director of WebSphere marketing Scott Hebner to set aside the buzzwords for a minute, and show me the beef. I wanted to know the tangible evidence of IBM's remarkable advancement.

Hebner started with a plausible explanation of how applications servers -- like IBM's WebSphere and BEA's WebLogic--are used differently today than they were a few years ago. "The bottom line," said Hebner, "is that in the application server world, there's a shift in how customers are using them and why they're buying them." Hebner recounted history saying, "Back in the early phase of application servers, the primary use was to extend a pre-existing application. For example, in online banking, a bank would use a Java 2 Enterprise Edition-based (J2EE) application server, some Java servlets, and Enterprise Java Beans (EJBs) to wrap an existing application and offer it to its customers on the Internet. This constituted 70 percent to 80 percent of application server usage." I'll buy that.

"But," continued Hebner, "through 2001, a shift away from browser-based interfaces started. That shift had to do with new application development, enterprise modernization, and integration. These were new applications and inherent in any application development, where you are integrating the network, you need to modernize 30- to 40-year-old assets. For example, insurance companies started taking back-end batch processes and CICS (IBM's transaction-oriented Customer Information Control System) claims processing software and replacing them with Java front ends and integrating them into other systems." OK, the story still sounds reasonable.

Hebner's contention is that the gradual emphasis on the application server has led us to a third phase, where it's no longer simply strapped on to the software stack. Rather, it's the anchor tenant and now choosing an application server has become a critical platform decision. "The elements of the platform have become more important," says Hebner. "The tools, the business integration software, the portals, the commerce capability, and wireless stuff are all extensions of the application server that, taken together, define a software platform." So far, this sounds a lot like what I hear from Oracle, Microsoft, BEA, Sun, and every other application server vendor. It's a long setup to the on-demand part, but we're getting closer.

Hebner went on to say that the choice of platform is more critical than ever and that the ability to deliver "on-demand" computing should not escape the buying criteria of an organization that's in the throes of such a decision. Implying that J2EE is purely a commodity and that Windows isn't even in the picture, Hebner advised moving up the stack to a layer above the application server where differentiation truly exists, and where, according to him, IBM is the only game in town.

"Now," said Hebner, "the decision should have less to do with the choice of J2EE kernel and more to do with the platform's on-demand capabilities. Don't get me wrong. You will still have a J2EE kernel with adapters for integration, Web services capabilities, and a highly programmable environment with portals on top. But now, the emphasis should shift to finding solutions that handle integration and that allows you to do it in a more dynamic way. In other words, something that can manage business processes that span network nodes. This is where we believe J2EE is insufficient. There needs to be something else--a service oriented architecture (SOA) that's more than just J2EE with Web services. It's all that plus integrated business rules, integrated workflow, and transactional capabilities."

Is that it? Is that what on-demand means? Enabling application servers with business process and transactional capabilities? Almost. Said Hebner, "Giving people easy access to the choreography of business processes across network nodes is what moves them into the service-oriented realm. It allows people to reconfigure the behavior of their applications on the fly. To have the ability to dynamically reconfigure application helps the business become more on-demand. .NET doesn't have integrated business rules, or dynamic provisioning of services, or the transaction management capabilities in a Web services-oriented environment. No one does."

Peeling the onion further, I asked "No one?" Hebner replied: "Do workflow products exist? Yes. But none of them are Web services products."

Hold on. Stop the presses. This very subtle disclaimer about the Web services context is the linchpin to IBM's claim, one that turns the notion of on-demand into a house of cards. Hebner continued: "None of them can handle flows, business rules and transaction roll-back. Over the next few months, we'll deliver a new version of the WebSphere application server with transactional integrity, business rule capability, provisioning, and dynamic security. It's not delivered in anything else."

There you have it. It took a while to get to the core of the "on-demand" onion and when I got there, I was still unconvinced. Not of IBM's ability to deliver an application server with transactional integrity, business rule capability, provisioning, and dynamic security. That, I believe it can do. But, what of the categorical statement that no alternative exists to IBM's offerings -- not from the usual list of competitors or even by mixing and matching best of breed products?

To set the record straight, as I said earlier, "Web services" as a phrase is itself an abstraction of a collection of protocols. In a B2B world, who wouldn't want integration that is secure, transaction-oriented, and well choreographed between two or more parties. Without those basic fundamentals, the whole idea of Web services, let alone the more abstract "on-demand" or "SOA", is a complete sham.

Furthermore, beauty is in the eyes of the beholder. IBM may say it's the only company to offer such functionality in the context of Web services, but if you read the fine print, you'll learn that IBM's sense of entitlement is tied to the company's definition of Web services. That may be different from how BEA, Sun, Oracle, Microsoft, or you define Web services.

How does IBM define Web services? From what I can tell, it's what I described before--a collection of protocols. But IBM's unique twist is in its belief that the Web services protocols found in WebSphere more closely track the evolving standard specifications than other vendor's collections, such as BEA's WebLogic, Oracle's 9iAS, Sun's N1, and Microsoft's .NET. Therefore, IBM feels it's more entitled to say that WebSphere is a Web services product, whereas other solutions-- despite their current ability to offer security, transaction integrity, and workflow in a SOA-based framework--are not. It's basically a very clever, somewhat deceitful way to manipulate the market landscape. .

To set the record straight on the definition of Web services, the hope is that one day the phrase "Web services product" will imply support for a robust collection of standard protocols that handle everything from basic message passing and security to transaction integrity and roll-back to choreography and workflow. By standard, I mean anointed as a standard by a recognized standards-setting body.

Although a lot of work is underway, currently no such collection of standard Web services protocols exists. Forget about security, transactions, or choreography and workflow for now. Of all the eventual Web services-specific protocols that will be in that collection (in other words, not HTTP, XML, and other protocols that are used for other purposes as well), not even the most basic one --SOAP (Simple Object Access Protocol)-- is a standard yet. SOAP is currently in the World Wide Web Consortium's (W3C) candidate recommendation phase, which is as about as close as a specification can be to becoming a standard without actually being one. Even the next one up the stack --Web Services Description Language (WSDL)-- is still in draft mode. Other than WS-Security, which OASIS is working on, barely any standards work is taking place for the rest of the stack. There's even a war between two choreography specifications that could derail the idea of Web services standards altogether.

Without real standards in place, no company can claim to have a standards-based Web services product. In fact, beyond support for the specifications that are currently works-in progress (SOAP, WSDL, and WS-Security) all other functionality -- especially that which is related to workflow and transaction integrity --- is delivered through purely proprietary means.

The most any vendor can claim at this point--especially in the realm of "on-demand"--is that they have a service-oriented architecture that provides the B2B functionality and integration capabilities that can withstand the rigors and needs of today's complex business environments. If IBM were to say this about its offerings, I'd be inclined to agree. Unfortunately for IBM, falling back to this more genuine description of its offerings makes it more difficult to say that it's the only solution provider that offers such capability. BEA's director of Web services strategy John Kiger had a succinct viewpoint on this topic: "IBM is blowing smoke." I couldn't agree more. Kiger went on to say that "IBM provides a toolkit that has implementations of early specifications. That's not the same as providing customers with a production environment. This is a common tactic of IBM's. Between our WebLogic application server and BEA Tuxedo, you have everything you need to deliver a transaction-oriented infrastructure in a production Web services environment. We support the current XML, SOAP, and WSDL specifications and, in terms of choreography and workflow, we're doing exactly what IBM is doing--supporting the Business Process Execution Language for Web Services (BPEL4WS), which we co-authored with IBM. In fact, at the BEA eWorld event this week, we're announcing that BPEL4WS support is available now in the beta of WebLogic 8.1. We expect 8.1 to ship in the summer."

Furthermore, on the subject of BPEL4WS support, Sun developer tools vice president Richard Green said choreography and workflow functionality have long been supported by a variety of companies shipping proprietary integration platforms, including Sun. "Sun's current shipping version of the Sun ONE Integration Server provides superior functionality to what is defined by either the BPEL4WS or WSCI specifications," Green said. BPEL4WS and the Web Services Choreography Interface (WSCI) are the two specifications involved in the aforementioned war.

Stoking the flames of that war, Green said, "Unlike WSCI, as of this time BPEL4WS has no standing as a legitimate standard since IBM and Microsoft have not submitted this specification to any standards body for formal standardization."

The submission Green is referring to is the first baby step that any specification must take before it will be considered by the W3C. That submission eventually led to the formation of the W3C's Web Services Choreography Working Group.

According to BEA's Kiger, "The W3C may indeed have a predisposition to WSCI, in that the group's formation was related to the WSCI submission." If that's the case, then IBM's "on-demand" house of cards really falls down because its support of the WSCI competitor--BPEL4WS--means that WebSphere is not tracking the evolving Web services standards and instead following a proprietary route. In other words, it can't claim to be the Web services product it says it is.

But Kiger also warned me not to assume that just because the W3C working group's origins can be traced to the WSCI submission that WSCI itself will be come the official choreography and workflow standard. "It's not clear at this point what the ultimate product will be or how close to WSCI it will be," Kiger said. "The process within the W3C is an open process. All players can bring whatever they want to the table." That includes BPEL4WS. Fortunately for BEA's sake, it doesn't matter which way things go. Not only is it a co-author with IBM and Microsoft of BPEL4WS, it's a co-submitter of WSCI to the W3C.

Whichever way the choreography and workflow wind blows, one thing is certain. When you lift up the hood on IBM's marketing-speak, there isn't a whole lot to the claim that they're the only ones that can do what they define as "on-demand" computing. There are plenty of other options and all of them will support whatever standards emerge or those companies will quickly become irrelevant.

Aside from the Windows vs. Java difference between .NET and all the J2EE-based offerings, what's do you look for in the way of differentiation between the major application server platforms? Share your thoughts with your fellow ZDNet readers or write to me at david.berlind@cnet.com.