Columns

Not so fast

• By Tony Baer
• October 1, 2001

Not surprisingly, when it comes to getting two applications to communicate, the best way is the time-honored, point-to-point batch interface.

Originally, the problem was data access. When client/server technology emerged and separated data from logic via standard SQL databases, the way seemed clear for applications to start talking.

The good news was that, by separating logic and data tiers, apps could grow more flexible. By leveraging ERP and other off-the-shelf packages, developers could now focus on building applications that delivered real business value, rather than reinventing the wheel with another financial reporting system.

But the bad news was that although multiple applications used the same databases, data access was far from transparent. For instance, SAP AG's clustered tables used Oracle as little more than an SQL-based file system. J.D. Edwards & Co. recently broke off its Siebel Systems alliance because, in the words of company CEO and chairman Edward McVaney, "The software was difficult to implement and didn't support our business model."

A few years back, the EAI guys devised a "better" answer: Use our message brokers, adapters and SDKs, and you can stop developing all those point-to-point interfaces. But implementing those generic EAI interface engines proved as daunting as the point-to-point connections they replaced, because the problem was not simply integrating data, but melding conflicting business processes.

Will integration get easy?
Over the past year, Web services have emerged as the "next big thing" for e-commerce. Web services use XML standards to provide a platform- and application-independent way for business processes to interact on the Web. Although few enterprises have any idea what Web services are or how to incorporate them into their applications, the standards have gained such momentum that even rivals like Sun and Microsoft have hopped on the same bandwagon.

Using Web services, a company that wants to check its trading partner's inventory and, if items are available, submit a procurement would send an HTTP-based SOAP message that glides through the recipient's firewall. At the other end, the request queries a directory built using the Universal Description, Discovery and Integration (UDDI) protocol that stores services that use standard Web Services Definition Language (WSDL) syntax. Emerging standards such as Web Services Flow Language (WSFL) will provide a standard for describing the workflows by which service requests obtain responses.

Now the best part. Doing all this is supposed to be easy. Using the latest frameworks coming from Microsoft, IBM or any of the J2EE app server vendors, e-business components could be deployed as Web services through simple wizards.

Now, repeat the above process, but apply it internally. A field sales representative completes a customer order using a CRM system, a process that triggers a query to the ERP system for pricing and availability. Sounds a bit like EAI, doesn't it? And if that's the case, could Web services replace all that messy EAI work with a bunch of wizards?

Not quite. The syntax that defines Web services has yet to be defined. Today, conducting a keyword on a UDDI directory—if one exists—could easily degenerate into the equivalent of a Google keyword search. That dictates the need to roll your own process framework, which involves the same process definition (and in some cases, reengineering) activity that you would have done in that EAI project. Also, a standard syntax for managing and prioritizing those processes has yet to emerge.

Then there is the sheer bulkiness of XML data. Compared to a normal transaction, where raw data is processed using known parameters, XML data is embedded in a self-declarative document. Not only is there more data to process, but there are additional processing steps, such as discovery. So, if you want to conduct your enterprise transactions as Web services, be prepared to buy a lot more hardware.

In the long run, Web services technologies could simplify some of the integration process, such as building application adapters. But they won't replace more efficient forms of transaction processing, and they won't avoid the biggest chore of integration: messing with your business processes.