Ah, the promise of Web services, the Internet-resident applications that have the major technology vendors united for the first time ever and consequently the entire sector abuzz with unbridled enthusiasm. According to its own rapidly spreading mythology, Web services -- where application can talk to application without messy human intervention -- is going to solve every lingering technical challenge. In the future, all your applications -- from the largest CRM system to the smallest utility -- will interact seamlessly, thanks to Web services. If you decide to sell something over the Web, you won't have to write a program to verify credit cards; just let your Web service go into the Internet marketplace and find an application to do that for you -- at a good price to boot.
And the early indications are that it might just happen.
Some day.
For now, CIOs and experts agree on only two things: that the name Web services is terrible and that there are enormous hurdles to clear before the hype becomes a reality.
Which isn't saying that CIOs aren't experimenting with Web services. For example, Motorola Inc. has a Microsoft Corp.-based B2B e-commerce application that handles about US$2 billion a year. One of the application's core pieces is its credit card validation function. "There are a lot of different credit cards out there, but [building the validation function] is logically pretty simple," says Toby Redshaw, vice president and director of IT strategy, e-business, business development and architecture for the Schaumburg, Ill.-based telecom company. "However, it is a bit of work to go and code it." Recently, Redshaw needed a credit-checking function for a new B2B application in a different business unit. Rather than build the new application from scratch, Redshaw transformed the existing credit validation function into a Web service by wrapping it with XML, the lingua franca of the technology, and plugging it into the new application, making it available for any other business sector. Redshaw estimates that the strategy saved between $100,000 and $150,000 in development costs. "I also saved time and started the idea that these things actually work," he says.
The Motorola example demonstrates how Web services can work in a controlled environment. But it also shows the technology's biggest weakness: deploying Web services over the Internet remains a challenge. There are areas, most notably security, where there aren't agreed-upon standards. The Internet is a poor platform for today's version of the technology -- Web services might have been built to run on the Internet, but the Internet wasn't built to run Web services.
Until the necessary solutions are created and gain widespread adoption -- which experts say won't be for another couple of years -- CIOs hoping to use Web services must come up with their own security and reliability solutions. Furthermore, while it is fairly easy to convert any existing application into Web services, CIOs must tread carefully -- anything they do now will have a big impact on their overall systems architecture in the future. The CIOs we talked to, however, are definitely not avoiding Web services. They are configuring workarounds and, perhaps most telling, keeping their Web services experiments safely in-house for the time being. They're seeing the promise of Web services with small-scale implementations -- but they're keeping the present-day reality firmly in mind.
The Security Setup
By far the biggest concern among Web services users is security. A recent survey, "Enterprise Development Management Issues 2002," by Santa Cruz, Calif.-based market researcher Evans Data Corp. found that security and authentication were the number-one hurdles for 48 percent of the 400 IT executives interviewed -- more than double that of the runner-up, bandwidth, at 22 percent. Mark Hansen, vice president and CIO of Long Grove, Ill.-based Kemper Insurance, says that security is actually two separate problems: one technical, one business-based. On the technical front, there are no industry-accepted security standards for XML. And even if there were, nobody is sure on the business side of what the contract language would have to be in order to convince CIOs that they could safely use a company that their Web services found on the Internet for important transactions. Who are you going to trust -- and how is that trust going to be validated -- in the ideal world of Web service talking to Web service?
While it's just a matter of time until standard security protocols emerge, it is enough to give a CIO trying to use Web services a headache. Currently, every XML security protocol on the market is a proprietary vendor offering and therefore not truly open. Hugo Haas, Web services activity lead with the Cambridge, Mass.-based World Wide Web Consortium (W3C), the standards setting group, says that at this point W3C hasn't even finished determining everything an XML security standard would require, let alone deciding on a standard. Until the security issues are cleared up, the one-time transactions that would come from a Web services "yellow pages" (known as universal description, discovery and integration, or UDDI) are only a dream.
Some companies experimenting with Web services over the Internet are doing so only with established business partners, skirting the issue of creating on-the-fly contracts and connections with unknown partners. Security becomes less of an issue if you are dealing with a limited number of users, says Perry Cliburn, CIO of early Web services adopter Hewitt Associates LLC. The Lincolnshire, Ill.-based human resources outsourcer offers 401(k), health plan management and data exchange via Web services to five of its customers and two third-party service providers. While some companies are offering secure Web services by setting up VPNs to essentially bring the user behind the company's firewall, Hewitt wanted to do Web services as close to the textbook -- using the public Internet, that is -- as possible, Cliburn says. "We could have bypassed the Internet and had a unique pipe that was a lease line, but we had to figure out how to do it [over the Internet] anyway," he says. Hewitt's Web services authenticate users based on private and public-key infrastructure (PKI) certificates, which are embedded in headers. According to Cliburn, all requests are made and responses given over an SSL-encrypted channel, and each Web services request is authenticated using a digital signature embedded in the header.
That solution results in the proverbial good news and bad news. Tim Hilgenberg, Hewitt's chief technology strategist for applications, says that it is a great way to tell client A from client B. The bad news is that it makes sense when you have a client A and a client B, and not an alphabet of other clients. The necessary protocol that describes what a particular application actually does (known as Web services description language, or WSDL), however, doesn't support PKIs: The PKIs have to be hand coded, which Hilgenberg says "is easy to manage with a couple of services. But if you have 1,000 services [across a set of clients] you don't want to be touching it by hand. That just isn't cost-effective."
Turning to the big picture, in all likelihood the security standards will be ready for one-off Web services -- such as getting a buyer's credit card verified for a one-time sale -- before you are. In the meantime, a handful of startup vendors, such as Grand Central Communications Inc. and Flamenco Networks Inc., are willing to serve as third-party authenticators for CIOs looking to get an early jump on the competition. But in a space this new, many CIOs are reluctant to trust a startup -- particularly one whose role depends on vendors' inability to agree on security standards.
The Reliability Runaround
In a recent speech, Joseph Williams, global chief architect for Sun One professional services in Denver, summed up Web services' other weaknesses as "all the '-ilities,'" listing reliability and scalability as the chief culprits, but leaving the door open for others.
Reliability and its attendant weaknesses have a common cause: the Internet and, more specifically, the HTTP communication standard, which just isn't a good fit for Web services. The big issue with HTTP is that it is connectionless and eventless, and it can't handle distributed transaction coordination the way common object request broker architecture (CORBA) can. In the middleware platforms of CORBA and COM (component object model), tightly coupled, internal software development worlds, data delivery is guaranteed. But the Web services world is loosely coupled -- delivery isn't guaranteed. Or not yet anyway. Ted Schadler, a group director at Cambridge, Mass.-based Forrester Research Inc., compares HTTP to a telegraph line and says that the machine-to-machine transactions in a Web services world require an open-line, telephone-like connection. Unfortunately, no one has figured out how to do that yet.
To be fair, HTTP works pretty well most of the time. But when you're considering sending sensitive business data, pretty well isn't reliable enough. "It's like the U.S. mail," says Hewitt's Hilgenberg. "It will get there 99 percent of the time, but if you want to guarantee delivery, you have to send it certified. HTTP is reliable 99 percent of the time, but there is a chance you could lose packets. For financials, you can't do that."
Prasuna Dornadula, senior vice president and CTO of CareTouch, a health services company in Concord, Calif., has set up a VPN in order to run a Web service that lets CareTouch patients schedule an appointment with any one of 5,000 physical therapists in northern California. The dedicated connection allows Dornadula to use IBM Corp.'s MQseries middleware to guarantee delivery. While the setup works for scheduling physical therapy sessions, Bernhard Borges, managing director for PWC Consulting's advanced technologies group in New York City, says that it doesn't make sense to use a messaging tool for the large financial transactions that Web services will eventually be used for. "The best you can do [with MQ] is know I handed it off," he says, "I don't know if you read it or not."
So Where Does This Leave the CIO
Assuming that the current level of industry cooperation continues, the current performance and security limitations shouldn't hold back Web services for long. Forrester's Schadler says that the Internet makes Web services so cheap that whatever problems there are now will eventually be solved. "Saying people won't use Web services over the Internet because of HTTP is like saying no one will use e-mail because the addresses are too hard to remember," he says.
Despite successful workarounds and inevitable solutions to Web services' shortcomings, it is relatively easy to convert an existing application into a Web service (Motorola's Redshaw can do it in three mouse clicks) -- and if a CIO followed the advice of many vendors and gurus they would. But CIOs should err on the side of caution here. While on the surface Web services seems to do away with the need for middleware that connects applications and databases, that's not always the case. In fact, Redshaw says that the opposite is true: Web services (at this point, anyway) is just another layer that uses middleware to connect to the data. Building a lot of Web services could prove fatal to a company that doesn't have a middleware-intensive, three-tier architecture in place. Redshaw likens it to erecting a fabulous skyscraper that's not connected to the city's electric grid -- you may have something great, but you can't use it.
Furthermore, Web services adds an extra layer of complexity that not all IT departments are in a position to handle. "When a program breaks, the hardware guy blames the application guy, the application guy blames the database guy," says Redshaw. "Now they can all blame the Web services layer." And building hundreds of Web services applications before installing an inventory system to keep track of them makes them impossible to reuse -- which is the reason for building Web services in the first place.
What all this really means is that between building a middleware-intensive architecture, an organized Web services repository and conducting trials with some established business partners, CIOs should have enough work to tide them over until standards emerge. The future is coming.
So What Is Web Services, Anyway
Motorola's vice president and Director of IT Toby Redshaw says of Web services, "If it is confusing, that means you are paying attention." And it is. Web services is Internet or other IP-based network applications built with four emerging standards: XML, simple object access protocol (SOAP), Web services description language (WSDL), and universal description discovery and integration (UDDI). That allows the applications to talk to each other -- no human intervention needed. What Web services is all about is interoperability of applications, be they written in Perl or Java or Windows or whatever.
This is how it might work: You start a website called HowLongCanILiveIn.com, which tells users how long their money would last them if they ran away to, say, Paris. And what the weather will be like. The thing is, you don't want to write programs for currency conversions and weather forecasting. So you put up your website with a client application (a Web service) that will go to the "yellow pages" -- UDDI -- to find listed services that will meet your needs. There, your client application downloads the WSDL that gives it the information it needs to invoke the Web service for, say, currency conversion. Never mind that the one you find was written in Java and your program is written in C++; the data is described using XML tags that both applications can understand. Your message asking for the currency conversion application is embedded in a SOAP envelope and shipped out on HTTP, the standard Internet transport protocol. Meanwhile, another application is doing the same for weather information. Within the blink of an eye, your first user has determined that with her current life savings, she can live in Paris for one month, which will be under partly cloudy skies and in the 70s. How about Costa Rica?
Note the use of the word emerging above. The standards are still very much under development.
Can't They All Just Get Along
Vendors claim to be trying to work on Web services together. They're not.
One of the reasons everyone is so bullish on Web services is that the major technology companies, including IBM, Microsoft and Sun Microsystems, are all supporting the same set of standards. Put mildly, this is a break from past tendencies. An encouraging sign came recently when executives from Microsoft and Sun shared a stage -- with no lawyers present -- to debate Web services in front of students in Boston University's MBA and MS program (and one CIO reporter). Gerry Miller, CTO for Microsoft in the Great Lakes, and Joseph Williams, global chief architect for Sun One professional services, spent the first 45 minutes exchanging good-natured barbs and agreeing that Web services has a bright future.
But the second half of the evening took on a different tone as the two sides took turns arguing the virtues of Java 2 Platform Enterprise Edition (J2EE) versus .Net. Each challenged the other side's commitment to open standards; Williams suggested that Microsoft was pulling "the old bait and switch," and that eventually .Net-based Web services will start to work better with Microsoft technologies. Williams pointed out that Sun was notified that the Microsoft-led Web Services Interoperability Organization existed only two days before it launched last February. Miller countered that Sun has formed an anti-Microsoft group called the Liberty Alliance.
Even the jokes were revealing. "Remember, they are a convicted monopolist," said Williams, warning against committing to Microsoft technology. "They weren't criminal charges," answered Miller: "We're just a monopolist."
Join the CIO New Zealand group on LinkedIn. The group is open to CIOs, IT Directors, COOs, CTOs and senior IT managers.