They're overhyped, sure, but this new way of doing business over the Internet holds great promise. Learn WHY Web services are important, HOW companies are using them and WHAT you can do to help your company's Web services strategy succeed.

Admit it. You were tempted to skip this story because a) you have no idea what Web services are or why you'd need an essential guide to them; b) you're vaguely familiar with Web services and think the topic is so technically esoteric that only the tech-heads need to worry about it; or c) you've heard so much hype about how Web services will radically change the way companies do business that you're certain the technology's been vastly overrated.

Well, it's a good thing you've decided to read on. Because Web services do represent a fundamental shift in the way companies build and use software. They can make it easier to link complex business systems, saving your company time and money and, in turn, letting it respond more flexibly to business demands. You must learn the basics about Web services - even if you'll never have to write a single line of code yourself - because CIOs have a crucial role to play in ensuring the success of any Web services strategy. And trust us, you will need a Web services strategy, because Web services won't just fade away.

WHAT'S IN A NAME

One of the more confusing things about Web services is the very term itself. The word services conjures up visions of people paying for something and getting something back. But at the most basic level, Web services are just a new flavour of standards-based software technology that lets programmers combine existing computer systems in new ways, over the Internet, within one business or across many.

Web services let companies bridge communications gaps - between software written in different programming languages, developed by different vendors or running on different operating systems.

For example, The Bekins Company, which handles logistics and transportation for manufacturers and retailers, relies on a network of trucking partners to ship tons of big-ticket goods coast to coast in the US. It needed a faster and more reliable way to let its trucking partners know about excess freight sitting on the loading dock, waiting to be shipped - faster than phoning and faxing. Until recently, getting Bekins' mainframe-based scheduling system to talk to its partners' transportation management systems would have meant painstakingly hand-coding links to each one - years of work. Yet by using Web services, Bekins was able to let its system talk to any of its partners' systems - and to let those partners talk back - over the Internet. And it was able to do that in just three months.

That sounds simple enough. But to add to the confusion, the term Web services is used in several ways. It describes the overall approach to stitching software programs together and building new systems over the Internet. It can refer to the specific software that links two or more systems; you could say that Bekins "wrote a Web service" to share information with its partners. People talk about the day when companies will be able to "rent" ready-made Web services from other companies - and the day when consumers will eventually be able to subscribe to Web services too. What unifies all the term's uses is the notion that Web services run over the Internet - or Internet protocol-based networks, such as intranets - and are built on a specific set of software standards.

The technology is drawing such huge hype because it promises (once again) to make it easier for companies to integrate software and reuse software that they or others have already built, historically an expensive and time-consuming process.

Why do Web services hold such promise? First, they run over the Internet, which pretty much every company is connected to, and over intranets or other Internet protocol-based networks. Second, major technology vendors, including BEA Systems, Hewlett-Packard, IBM, Microsoft, Oracle and Sun, have agreed to support a set of standard software technologies - an unlikely level of cross-industry cooperation.

The Web services approach doesn't necessarily make earlier integration technologies obsolete. But it makes types of integration possible that would have been hellishly complex otherwise. Bekins, for example, first considered using CORBA to tie its freight scheduling system to its partners' transportation management systems. But Randy Mowen, Bekins' director of data management and e-business architecture, says he found 50-odd standards that he'd have to follow, and a dearth of documentation. "We kind of abandoned it before we got too far along," Mowen says. "It never really materialised because of the complexity."

HOW DO WEB SERVICES WORK

In contrast with the more traditional means of integration that came before it, Web services offer a more flexible - or "loosely coupled" - way of linking applications. Web services work like an old-fashioned telephone switchboard. If Mr Smith wanted to ask Miss Jones out for an ice cream soda, he didn't need a direct wire from his phone to hers; he went through the switchboard operator, who plugged in the connection and then disconnected it when he and Miss Jones were done speaking. Mr Smith could also use the same technology to call Mr Johnson at the bank. Likewise, if Mowen's programmers write a Web service that pulls information from Bekins' freight scheduling system, it can send that information to systems at suppliers A, B and C; the code doesn't have to be rewritten for each partner.

Using the switchboard example, in order for people to communicate over the phone, parties on both ends need to agree to use standard telephones, answer their phones when they ring and speak the same language. Web services standards perform similar functions. The most important of these standard software technologies is XML. For Web services to work, both sides need to be able to speak XML.

Web services aren't used to build new systems from scratch. Rather, they're a tool to use with existing computer systems that you want to stitch together to create something new. "You still need your customer relationship management application, your core database, your application servers," says Evan Quinn, chief analyst at the Hurwitz Group, a Massachusetts-based consultancy. "You still need to have a good infrastructure and rich computing resources. If you don't, Web services aren't going to do much in the business world." Many CIOs will have business-unit heads asking if they can use "this newfangled Web services stuff" to build them a sales-force management system. The savvy CIO will point out that a better use of Web services would be to have the new sales-force management system tap in to information from the accounts receivable system so that sales reps can find out whether their customers actually pay their bills.

HOW ARE WEB SERVICES BEING USED NOW

Companies testing the Web services waters are generally tackling internal software integration projects first, chiefly because in-house projects are less risky and easier to test-drive. "People will integrate applications, processes, business flow, even content," says Gary Hein, senior analyst at The Burton Group, a Utah-based consultancy. At Texas A&M, for example, the IS department wrote Web services that authenticate users' identification; it is also working on Web services that would pull information from several legacy applications and present it over a Web page so that students can check their schedules and their tuition accounts online.

Some Web services pioneers have already started to develop external applications, which use Web services to connect to trusted business partners. Overall, however, it will be 12 to 18 months before most mainstream companies start building Web services that cross corporate firewalls, Hein predicts.

Perhaps the biggest Web services hype - and the biggest doubts - surround future uses of Web services. Vendors and analysts envision a world where companies will list their Web services in public online directories. A company might be able to assemble a whole business by piecing together Web services created and maintained by other companies. For example, a company looking for a way to check the credit histories of its customers could have its order-processing software automatically scan the Web to find companies that offer a credit-checking Web service, figure out which company offers the best deal, negotiate it and then hook up to that company's Web service on the fly - even if the two companies never did business together before.

But David Schatsky, research director and senior analyst at Jupiter Media Metrix in New York City, believes that this expansive hype won't become a reality any time soon. Too many technological and business questions remain unanswered: How will security be handled? How will companies make sure that the company delivering a Web service will keep the service up and running reliably? How will companies pay for the use of Web services? Who will be held accountable if a Web service fails to deliver as promised? "Using Web services to dynamically discover and interact with business partners - maybe ones that you don't already have relationships with - is risky," Schatsky says. And according to Jupiter, it's a risk most companies don't plan on taking any time soon; only 16 per cent of IT managers interviewed said that their companies plan to pursue this type of Web services use by mid-2002.

WHEN ARE WEB SERVICES A BAD IDEA

Even when it comes to application integration, Web services aren't always a good choice. There may not be any reason to use Web services to link two software offerings developed by the same vendor, Hein says, since those packages probably already know how to communicate with each other.

Likewise, Hein says, the Web services approach isn't necessary if a company is able to dictate certain key parameters that software on both ends of the transaction will use. In other words, if software developers agree that both of the applications to be integrated speak French, there's no reason for them to speak Esperanto. And Hurwitz's Quinn notes that if the applications in question have already been integrated in one way and "you have a new integration requirement between these applications, it would probably not make sense to use Web services. After all, you already have the integration facility and expertise in place."

Another drawback is that today, Web services standards just can't deliver the same guaranteed, high-level, bullet-proof performance that you'd get from traditional business applications. Until they do, you won't want to use Web services in a situation where transaction speed, reliability and security are of the essence. Vendors are working on new specifications to address these weaknesses, but it could be another 18 months before such specifications become standards and get more broadly adopted, Hein says.

OK, if you're not a programmer, you'll probably never have to write a lick of XML. But there are a few things you can do to help get your company ready for Web services.

Be realistic about how quickly your company needs to implement Web services. Web services won't be something that's hyped and then disappears, Hein says, but the technology hasn't achieved industrial strength yet, either. His advice? Don't rush out tomorrow and insist that the entire company and all its partners change over to a Web services approach. Instead, keep an eye on the Web services market, which he expects will grow in the next year to year and a half, and start experimenting internally.

Lend a sceptical ear to vendors' marketing claims. Vendors will go on and on about how they've had umpteen people involved in the development of XML since 1997, or they were the first to roll out beta code that supports such and such standard. And they'll claim that this has put them way ahead of their competitors when it comes to Web services support. Take those claims with a grain of salt. "It's too early in the development of Web services to make a strategic call on which vendor is the best to wed yourself to," Schatsky says. The best strategy is to work with a vendor that you already have a relationship with until the market matures.

Make sure that your company's up-coming business applications support Web services standards. Schatsky advises CIOs to add Web services support to the checklist of things they'll need from business application vendors - most will offer such support by late this year.

Recognise that deploying Web services is as much of a business problem as it is a technology problem. Yes, vendors will roll out more Web services-enabled software and (one hopes) agree on more sophisticated standards. But companies won't be able to point and click away the hard work of deciding which computing resources should be integrated internally, which ones should be shared with partners and which should be opened up to consumers. "Just because you have an easier-to-use technology doesn't mean you change the world's business models overnight," Quinn says. So while the IS department is experimenting with internal uses of Web services, CIOs and other business executives should be thinking about future business opportunities afforded by the technology.

Web services are undoubtedly a work in progress, and the grand Web services scenarios envisioned for the future won't happen without a serious bit of work on the technology side and the business side. But if you start experimenting with simpler Web services now, you'll be in good company - and you'll also be ready when Web services really start to take off.

Early Adopters

In the next year, how will your organisation use Web services? Here's what CIOs say.

60% - To integrate applications behind the corporate firewall.

53% - To integrate with external applications of known suppliers, customers or partners outside the firewall.

23% - Do not intend to deploy the technology in the next year.

20% - To become a provider of Web services to third parties.

16% - To dynamically discover and interact with external applications of third parties.

Source: Jupiter Media Metrix, from a Jupiter/ERI Executive Survey in June 2001 of 471 IT managers.

Microsoft Always Has to Be Different

Its grand plan for Web services is no exception to the rule.

Microsoft's Web services strategy makes things a bit more confusing for people trying to understand Web services, largely because its strategy is so broad and so different from what other vendors are doing. Known as Microsoft .Net, the strategy encompasses more than just development tools. The software giant plans to offer free and paid subscription-based online services for consumers - say, ones that let consumers keep a calendar online or get reminders when they need to go to the dentist. Other Web sites will be able to build on those basic services. The initiative, known as .Net My Services, will debut some time this year.

What might the .Net My Services world look like? Here's a hypothetical example: let's say a consumer subscribes to Web calendar and e-mail alert services from Microsoft. When she goes to the Jiffy Lube Web site and wants to sign up for an oil change at the branch near where she works, the Jiffy Lube site can ask for access to her online calendar. If she agrees, the site could find a free time slot in her schedule, write in the appointment and even arrange to send her an e-mail alert at work the day before. Jiffy Lube would need to pay "some nominal yearly fee" to be certified for and participate in the .Net My Services network, says Adam Sohn, a project manager in Microsoft's .Net platform strategy group. Microsoft also expects other companies to develop similar consumer-oriented Web services. Still, some fear that Microsoft's plan will give it too strong a hold on consumer information.

A Refresher Course

Web services rely on the following software standards.

XML (Extensible Markup Language) : A common method for describing data, XML lets programmers write their own tags to identify information in a document and put it into context. Industry groups are getting together to define their own XML dialects. For example, the shoe industry might agree on one tag to represent shoe size, another to represent shoe colour and so on.

SOAP (Simple Object Access Protocol) : Describes how one application talks to a Web service and asks it to perform a task and return an answer. SOAP makes it possible to use Web services for transactions - say, credit card authorisation or checking inventory in real time and placing an order.

UDDI (Universal Description, Discovery and Integration) : A virtual yellow pages for Web services that lets software discover what Web services are available and how to hook up to them. Major software vendors are working together to develop a public UDDI registry that will enable companies to find one another's Web services over the Internet.

WSDL (Web Services Description Language): If you think of UDDI as a virtual yellow pages, WSDL is the little blurb associated with each entry that describes what kind of work the Web service can do - say, that it can give you access to a database of postcodes.

Get Down to the Nitty-Gritty

Here's a blow-by-blow account of how The Bekins Company built its Web service.

OK, take a deep breath. It's time to get down to the nuts-and-bolts details of how an excess freight scheduling Web service was built at The Bekins Company, an Illinois-based firm that handles logistics and transportation for manufacturers and retailers.

According to Randy Mowen, Bekins' director of data management and e-business architecture, Bekins already had a home-grown, mainframe-based scheduling system, written in Cobol; many of its larger trucking partners already had their own transportation management systems, written in God knows what.

In the first phase of the project, Bekins' programmers used a Java programming tool from IBM to write a "tonnage broadcast" application - essentially, to suck information about excess freight out of the mainframe-based freight scheduling system (what the shipment is, where it is, how big it is, where it has to go and what rate Bekins would pay for the shipment) and put it on an IBM application server.

Bekins' partners could view the excess freight information - smaller partners, through a Web page, larger partners, by logging on to Bekins' network - but they could not pull it into their own systems, manipulate it and send information back. By writing a Web service interface to the tonnage broadcast system, Bekins can now send XML messages about the excess freight to its partners. The partners meet Bekins halfway; their software understands the dialect of XML that the Bekins software speaks, imports the excess freight information and sends XML messages back, bidding on a given job.

Of the 200 to 300 partners taking advantage of the tonnage broadcast feature when it launched in November, Mowen says, about a third are using it as a Web service. In the next phase of the project, he adds, Bekins will be able to broadcast excess freight information to cell phones and PDAs.