Columns

Getting what we ask for

• By Tony Baer
• December 31, 2002

At this year's Gartner Group Symposium, a gathering of CIOs, Web services rated a token mention at best. The highest priority to most CIOs was preserving or leveraging current technology assets, not taking risks on new ones.

While the show's theme, the ''real-time enterprise,'' might imply the use of Web services --  because they could simplify building interfaces -- using them as RPCs for sharing information may not be the most efficient way to go about it.

That Web services is not the first thing on CIOs' minds is not a surprise. Regardless of the IT budgetary climate, new technologies like Web services typically sneak in through the back door. And with Web services, forays may also come courtesy of the usual suspects, such as SAP, which is using the technology to drive its new ''xApps'' series of collaborative extensions to the R3 enterprise system.

Nonetheless, these baby steps for Web services will likely provide scant indication of the potential -- and problems -- the new technology will provide. Remember how Java first emerged through cute applets that animated browser screens? Today, Java is primarily associated with J2EE app servers that provide the heartbeat of Web apps. And you'll probably use Flash for those animations, instead.

The first generation of Web services apps, consisting of SOAP requests bouncing off specific servers, are likely to be just the beginning. Ultimately, Web services could liberate application logic, deconstructing it into self-contained requests for services, or agglomerations of services, that could be requested by any source and fulfilled from any target as long as the relevant standards are observed.

Today's Web services as EAI band-aids or Java-.NET bridges are likely to pale against the possibility of turning app logic into a free market, where service providers can bid on fulfilling services requests.

Does anybody remember the battle cry of the Internet changing everything? Today's technologies, SOAP, WSDL and UDDI, at best provide the means to publish a service, send a service request and look one up. Now, Web services are largely confined to carefully bounded environments where all the messages and players are known.

There is still value at this level. A Web services-based credit authorization application being developed by Concord EFS, a processor of bank ATM and credit card debit transactions, is intended to be a faster alternative to dial-up transactions, without the cost of a VSAT satellite dish. By upgrading the firmware on retailer POS terminals, the units can be equipped to communicate with the credit processor with SOAP transactions on a continuously open phone line.

Now let's assume that the remaining obstacles to Web services adoption fall away. And that a critical mass of missing pieces, encompassing security, authentication, encryption, message routing, quality of service, business process definition, workflows and choreography fall into place. The notion isn't so crazy, since standards proposals covering many of these areas are actively working their way through standards bodies such as the W3C and OASIS.

Now the real ''fun'' begins. Your enterprise systems have the necessary SOAP interfaces. The ''S'' in SOAP stands for ''simple,'' so it is not inconceivable that organizations could find themselves with dozens of SOAP interfaces that function, in effect, as point-to-point connections. The next problem is getting a handle on all of them, finding a way to reuse or at least track the flow of all that logic.

Now what happens when service requests pass through intermediaries? What if an incoming customer order triggers checks from external credit agencies, requests for bids from suppliers, renegotiating of procurement agreements and flexible bids conditioned on date of delivery? If messages are encrypted, and authorizations are certified by third parties, how can you ensure that the messages won't get corrupted, or that only authorized service providers are allowed to bid? And, if the terms are flexible enough, is there a way to determine when a transaction is complete, and if, under any conditions, a service request that is 80% completed will be adequate? And who owns the transaction and the obligation to complete it, anyway?

Although the technology pieces are not yet in place to support such a scenario, watch out -- we may soon get what we're asking for.