Getting what we ask for
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
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
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
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,
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
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
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
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.
Tony Baer is principal with onStrategies, a New York-based consulting firm, and editor of Computer Finance, a monthly journal on IT economics. He can be reached via
e-mail at email@example.com.