The lowdown on Web services
- By Brian Robinson
- Jun 17, 2002
Just about anybody working on e-government applications is familiar with Extensible Markup Language, which is fast becoming a popular solution for exchanging information across the Internet. XML, however, is just one component of an emerging concept known as Web services.
Still something of a mystery to many information technology professionals, Web services nonetheless are expected to be pervasive in the not-too-distant future, an essential part of every agency's toolkit for quickly fielding useful and cost-efficient e-government applications.
Web services, software written to link systems over the Internet, are intended to simplify the development of Web-based applications by automating the underlying processes needed for systems to interact online. Whereas XML tags information so that it can be recognized by systems, the other three standards work more behind the scenes, automating processes so that applications know how to handle that information.
Industry is certainly leading the government toward wider use of Web services standards. Officials at the Office of Management and Budget also are encouraging agencies to incorporate Web services into the 24 cross-agency e-government initiatives.
That's because the Web services standards, taken together, provide a relatively easy way to tie legacy systems together. They also help slash application development costs and prompt innovative ways to deliver on the citizen-centric mandate issued by OMB.
But achieving this vision might take a while. Concerns about the interoperability of Web services across platforms and the security of Web services-based applications could delay or derail the use of the standards.
Perhaps, observers say, as early adopters such as the Agriculture Department, the Army and the Environmental Protection Agency deploy systems using Web services, the strengths and weaknesses of the standards will become better understood.
A New Computing Model
Web services is based on four open, nonproprietary standards: XML, Simple Object Access Protocol (SOAP), Web Services Description Language (WSDL) and Universal Description, Discovery and Integration (UDDI) (see box, this page).
These standards provide a way for systems to communicate with one another via the Internet and enable applications to make calls to others to run certain routines.
The approach is analogous to computer operating systems. Microsoft Corp.'s Windows, Apple Computer Inc.'s Mac OS and Unix each provide an underlying set of processes on which programmers can develop applications. Without that platform, they would have to write much more extensive code.
Web services standards could lead to a new model of computing, said Steve Ekblad, project manager at the Information Technology Center at the USDA's Natural Resources Conservation Service in Fort Collins, Colo., which has developed geospatial Web services to help people access mapping data from various databases.
Now users can do what's known as asynchronous computing, he said. In the past, users retrieving information from a variety of sources had to process that data before forwarding it to a server.
By managing the flow of information, Web services-based tools make it possible to break up that sequential process. Now a user can make requests to a number of computers and rely on those systems to process the data and return the results as soon as they are complete.
This model cuts down on the time it takes to finish a job because it spreads data processing across multiple systems and the end user's desktop no longer creates a bottleneck.
The ability to move away from traditional single process, single data access computing means "we can finally move to [a form of] distributed parallel computing," Ekblad said. "That's something we only talked about 10 years ago, and now it's here."
Web services applications also can be reused by others in government without any need to rewrite or redesign them, said Avi Hoffer, chairman and chief executive officer of Metastorm Inc.
The ability to fit together parts of different Web services to create new ones "could cut application development time by 75 percent or more, because people won't have to reinvent the wheel each time," Hoffer said. "I would think people in IT groups [in government] would also be able to make the case that Web services could be a great way to spend money."
But Web services do not have to be complex. Brand Niemann, a computer scientist at the Environmental Protection Agency and a self-described XML evangelist, envisions government agencies taking a simpler approach to Web services — using XML to tag data, then deliver it from one application to another on different Web servers.
This approach does not require the more advanced functions in the standard set of Web services. All agencies need to do is deliver XML data from one place on the Web to another using the popular Hypertext Transport Protocol. SOAP, which is based on HTTP, is more sophisticated and, therefore, offers more capabilities, he said, but you don't need it to move XML data.
"Actually linking applications is the frosting on the cake," Niemann said. "Integration is important, but people are confused [about Web services] because it is about something more basic than that."
The EPA has several XML Web services projects in place, with more planned for the near future. Other agencies also have working examples, such as the Army's Electronic Bid Solicitation system, which uses XML Web services to update potential bidders on Army procurements.
At this stage, few agencies are actively developing applications that use the full Web services suite of standards, but most agencies likely will.
Energy Department officials, for example, said they do not use Web services now but are looking to integrate them into future "corporate" applications.
"With our participation in numerous 'Quicksilver' e-government initiatives and our own internal e-government project, we expect to see many opportunities arise to put these Internet-based standards to use," said Karen Evans, DOE's chief information officer.
An OMB-led interagency E-Government Task Force recommended a set of 24 initiatives last year. The goal is to substantially reduce IT costs by integrating agency operations and investments.
Toward that end, Mark Forman, associate director for information technology and e-government at OMB, is requiring agencies to include XML Web services in the budget plans they submit to OMB as one of the ways of complying with the e-government initiatives.
Even Congress is putting on the pressure. Sen. Joe Lieberman (D-Conn.), chairman of the Senate Governmental Affairs Committee, is considering requiring agencies to use XML in his recrafted E-Government Act of 2002.
Much Work Ahead
Clearly, the federal government is just beginning to make use of Web services, and several major issues must be addressed before the standards begin to permeate agency projects.
One chief concern is whether Web services can handle what users expect. In their current form, they provide basic system-to-system communications, which is useful, but observers say they fall short of industrial-strength application integration.
"There's probably enough there as Web services are currently defined for them to allow for basic integration" of applications, said Christine Axton, a London-based analyst with technology consultant Ovum. "But that's not the same as doing enterprise application integration, because Web services don't do such things as complex data transforms."
True application integration is not just a matter of connections between applications, she said, which is what she sees Web services currently providing. Developers also must allow for transactional security, quality of service, complicated billing and contracting mechanisms, and so on.
Axton believes the Web services concept is important and deserves strong promotion, and over the next few years, it could change the way applications are developed, delivered and used. But early overselling created a mix of expectations and confusion, she said, and that could lead to a backlash by potential users.
Experts say compatibility among Web services tools also is a concern. Given the history of standards making, and the propensity of vendors to develop their own proprietary and incompatible "flavors" of open standards products, members of government organizations such as the CIO Council's XML Working Group are reluctant to endorse the use of Web services until they are convinced that vendors are intent on a true set of open Web services standards.
The main industry body dealing with the issue is the Web Services Interoperability Organization (WS-I), formed earlier this year by IBM Corp. and Microsoft, along with about 50 other companies including Hewlett-Packard Co., Oracle Corp., BEA Systems Inc. and Intel Corp.
Bob Sutor, IBM's director of e-business standards strategy, said the WS-I focuses on ways to ensure the interoperability of basic Web services standards by developing guidelines in the areas of basic connectivity, secure and reliable message delivery, and coordination of transactions and workflow. The organization will also devise tests that will give the WS-I stamp of approval to products that pass them.
"I think we'll be done with the work on the core [set of guidelines] in 12 to 24 months and with the implementation phase another year or two after that," Sutor said. "Then Web services should be broadly applicable for use both inside and outside the firewall."
However, that doesn't cover every issue that users of Web services will have to consider. For one thing, Web services are not a complete solution to every IT problem. They are not suitable for transmitting large data files, for example, so IT managers will still have to consider other ways of shifting big blocks of data around the network.
Also, although Web services run over the existing Internet infrastructure, that doesn't mean architectural considerations specific to Web services can be forgotten.
"Deploying Web services will be a fairly complex thing," said Scott Spehar, vice president of Cisco Federal. Besides requirements for security, efficiency and quality of service, "there will be a significant increase in the traffic carried over the network, as well as an uptick in bandwidth demands because of the increased need for back-office data warehousing."
And not everyone will rush to rewrite their applications to incorporate Web services technologies, said Sue Aldrich, senior vice president of the Patricia Seybold Group Inc. and author of a recent report on Web services. Established companies with large customer bases such as SAP AG, for example, will provide Web services interfaces, but they won't make changes to the applications themselves.
Nevertheless, she predicts that Web services will show "a steeper adoption curve and will infiltrate more of the applications portfolio than previous application technologies."
Web services will be in the majority of business applications by 2005, she predicts, and even the cautious will deploy them in most of their applications by 2006.
Robinson is a freelance journalist based in Portland, Ore. He can be reached at email@example.com.
At a glance
Standards behind Web services
* Extensible Markup Language is a streamlined version of Standard Generalized Markup Language, developed by the International Organization for Standardization to define the structures of different types of electronic documents. XML can be used to store any kind of structured language and encapsulate data so it can be shared between otherwise incompatible computer systems.
* Simple Object Access Protocol (SOAP) is based on XML and Hypertext Transport Protocol. It provides a way for applications — including those running on different operating systems — to communicate and work together through remote procedure calls implemented via HTTP.
* Universal Description, Discovery and Integration (UDDI) describes how to publish and discover information about Web services applications. It is a Web-based directory where someone can search for particular Web services and what they do.
* Web Services Description Language (WSDL), based on XML, describes the kinds of software applications, or services, available on a particular network. Once someone develops a Web service, they can publish its description and link in a special UDDI repository. When someone wants to use the service, they request the WSDL file so they can determine its location, function calls and how to get to them. They use that information to construct a SOAP request to a server.