Making Web Services Inevitable

IBM has further positioned itself at the epicenter of the XML universe, by being the first player to announce a set of pieces covering everything from the database and application integration through security policy management and, of course, the web application server nerve center.

There is little question that IBM has gotten XML religion. XML, along with Java before it, provide the glue that accomplish using industry standards what Big Blue tried unilaterally a decade ago with SAA. At today’s briefing, IBM’s web services evangelist showed how a page of CICS transaction code could be transformed into a web service, complete with standard XML description language, without the programmers (or business analyst) knowing anything about legacy systems.

If it sounds too easy, it probably is.

Web services have become the latest catchwords in a market that previously had trouble learning how to spell EAI. In the latter case, it was the complexity of trying to package systems integration—which for many enterprises became a code word for bottomless pit. When integrating—or interfacing—an ERP system, developers often got hammered dealing with the unique ways that every application had for structuring data. Integrators learned the hard way that, just because two applications stored their data in Oracle, that didn’t mean that both applications could understand each other’s data, not to mention sharing overlapping processes with one another.

Web services are also being unleashed in a market that learned to spell B2B, but failed to embrace it. The notion that exchanges could improve business efficiency by providing a dating or matchmaking service, pairing any buyer and seller willing to agree on the right price, might have sounded good for buying priceless art or paper clips. However, it clashed against best practices developed over the past two decades, where trading partners actually shrank their lists of trading partners in favor of maintaining fewer, longer-term strategic relationships.

At first glance, web services sound like another step towards allowing anyone to do business with anyone at any time without having to prepare laborious handshakes up front. However, recent B2B experience has proven that most organizations do not want to conduct business like two ships passing through the night. Instead, taking advantage of the ability of web services to dynamically execute on the fly will actually require even more handshaking up front, for combination of business and technical reasons.

Recent B2B experience has taught e-commerce gurus that companies do not want to conduct business like ships passing through the night. Significantly, the web services examples cited by IBM involved making it easier for parties to conduct business from standard menus of transactions in situations where the identity of both parties is known to at least the initiator. This was anything but commerce at random.

There are good reasons for this.

Yes, XML standards appear easy and intuitive at first glance. They use the same ASCII characters as HTML, are easily parsed, and the standards have gathered virtually unanimous vendor acceptance. But there remain formidable barriers before XML-based service requests can magically connect with service providers to make e commerce truly frictionless.

Let’s start with technology. XML data, which is much fatter than conventional structured data or binary code, could add significant overhead to database processing and messaging communications unless some standard techniques are developed to compress or abbreviate it. Today, IBM, which now stores XML data as another DB2 Extender data type, offers the solution of federated databases that are deployed at any point along the network where the processing can be conducted most efficiently. However, when IBM rolled out an example of one of its customers—the Galileo travel aggregator, they talked about an enterprise that handles over 100 billion transactions annually. Just imagine if all those transactions all were conducted in XML.

Then look at the business side of the equation. Having a service description language does not necessarily mean that everyone in the same industry shares the same syntax. In the electronics industry, RosettaNet has begun the process of standardizing terminology and transactions, updating a process that many verticals conducted with EDI back in the 1980s. So more RosettaNets are needed in other sectors to get everybody talking the same language.

More RosettaNets must emerge in sectors outside semiconductors, for starters.

IBM, along with Microsoft and Ariba, have played a leading role in lining up web services as today’s number one e commerce IT agenda item. Are all the standards in place? Maybe, maybe not. According to IBM Internet technology director Rod Smith, maybe we need for yet a new set of APIs that define how to characterize the “endpoint,” where an XML web service transaction ends and a legacy system process begins.

But the emergence off standards is only the first step. To “do” web services, major verticals must spend the effort to define just what exactly it is that they do. As ERP experience taught many organizations, that could take some time.