Web Services in Theory and Practice

Page 1 of 3

      Bookmark and Share

People work on the road, in airports, at home, and at the office. No matter where or when they're working, they want the same access to content that they would have if they were sitting in their office. In these days of random hacking and other senseless acts of computer violence, how do you give the people what they need to do their jobs wherever they may be while avoiding long delays or sacrificing computer security?

Certainly, part of the answer to the question of access has to include the Web—if for no better reasons than its ubiquity and familiarity. At best, though, it's only part of the answer because it's not enough to build an interface from computer systems that opens them up to the Web; there are too many security risks involved and too much time can be lost while custom software solutions are developed.

Still, the Web provided enough of a start and stimulus so that about five years ago, technologists could begin crafting the other parts of the answer: Web services. Today, they are still hard at work making the vision of Web services a reality, and some progress has been made. More needs to be done, but now is the time for companies to begin developing strategies for making the most of what Web services offer now and will offer in the future.

"Web services" is an umbrella term for services that take place over the Web, use Internet protocols, and may or may not involve the use of a Web browser. Toufic Boubez, CTO of Layer 7 Technologies, a Web services firm headquartered in San Mateo, CA, says that the term is a bit of a misnomer and not nearly powerful enough to convey the strength of the broad array of services under development.

Boubez ought to know—he has spent much of his career envisioning and creating Web services. Before helping to found Layer 7, he was at IBM for years and was part of the IBM Consulting Group and co-author of one of the Web services standards. "The original concept started in 1998 when we were working with XML," he recalls. With people just starting to embrace the Web, it was evident to the team that the Web had untapped resources for business. "We asked ourselves: How can you make this technology easier for businesses to use?"

The first step in the process was to make it easier for companies to build applications that used the Web to some degree. Web services toolkits started to be available at the end of 1999, and companies have worked steadily since then to create Web services software solutions. Dozens of companies now offer Web services modules or offer their expertise to companies that wish to incorporate Web services into how they do business.

It is possible, of course, for companies to develop Web services in-house by writing custom code suited to their needs. The problem with the do-it-yourself approach is that companies don't operate in a vacuum. Today, companies strive to add value and develop ways to stay competitive—and they are also searching for ways to do this before everyone else does. It's important to be in the game early, and waiting until the code is developed in-house takes too much time. "For organizations that are trying to be more nimble, the idea of starting from scratch to get new capabilities going doesn't work any more," explains Judith Hurwitz, principal of Hurwitz and Associates, an IT industry analyst firm based in Cambridge, MA.

This need for speed was something that Web services technologists understood from the beginning, even if it wasn't clear how to accomplish this goal. Over the last several years, though, technologists have realized they need to use a modular approach. The services have to be broken down into components that hook together and can be rearranged as needed. The plug-and-play concept that Windows PC users have come to expect must be embraced by Web services developers.

This is not an easy way for your average Web developer to think. "The reason we are not further along in the development of Web services is that it has taken some time for people to get the idea that they could make something new [as in modular software], rather than reinventing what they already had [reworking old code]," says Boubez.

Page 1 of 3