Clearing the view ahead: Frequently asked questions about Web services

Cut through the fog around Web services to see the future of enterprise software

Web services have been touted as the answer to government's woes about the lack of interoperability among information technology systems. With most agencies under pressure to improve the way they share information, you would think that Web services and their system-linking abilities would be a hot topic among IT staff and agency managers.

Yet you would be hard-pressed to find more than a handful of people, if that many, at any given agency who are well-versed in Web services technologies.

To some degree, that's understandable. It's a relatively new concept, even for technophiles, and hands-on experience with the technology is still limited. Nevertheless, a number of Web services projects are sprouting up around government.

"Web services are a lot more widespread now than people

realize," said Steve Seaquist, chief technology officer at Contemporary Technology and a contractor for the Small Business Administration. "Applications don't tell you when they are calling a Web service, so people may not realize how many there are, but they are out there."

Michael Beckley, co-founder and vice president of product strategy at Appian, a business software development firm, said he believes government use of Web services will soon move out of the early adopter phase. He said he expects Web services to be pervasive throughout government five years from now.

"Most people don't understand that by then e-government will be gone," he said. "Web services will make government be e-government."

First, though, a better familiarity with the technology is needed. What follows are answers to frequently asked questions about Web services.

FAQ: What is a Web service?

A Web service is a software-based, open-standards method for enabling two or more software applications to communicate across the public Internet or a private network, no matter what programming language the applications are written in or what hardware platforms they run on.

Services can perform a variety of functions, from processing simple requests for information to doing one or more parts of a complex, multistep business process. Web services are typically built modularly, which means they can be plugged together across the Web to create distributed applications.

It is also important to know what Web services are not. "People's understanding of the term is still limited," said Brand Niemann, a computer scientist at the Environmental Protection Agency and co-chairman of the CIO Council's Semantic Interoperability Community of Practice. "Some would [erroneously] call almost everything a Web service if it does something over the Web."

That's definitely missing the point, Seaquist said. The defining characteristic of a Web service is that it is an application-to-application connection, not that it can run on the Web.

FAQ: Are Web services really that important to government?

The push for more efficient and smoother government requires frictionless data sharing within and across agencies, and often with the public, but a lack of interoperability among systems even within agencies has stymied this goal. Web services could finally provide the necessary glue.

"We haven't really seen an integration technology like this before," said Greg Carter, chief technology officer at business software developer Metastorm. "The opportunity for the average Web portal developer and agency IT shop to build sophisticated applications with off-the-shelf tools and widely available knowledge is huge."

Web services completely remove the computing platform from the picture, said Charles Stack, founder and chief executive

officer of Flashline, which offers tools for managing software

development.

"Web services finally complete the migration away from the hardware," he said. "You don't even need a Web browser."

Components of Web services can be re-used, and application data doesn't have to be duplicated. Those features should lead to significant cost savings, said Rex Brooks, president of Starbourne Communications Design, a technology consulting and software development firm.

FAQ: Which Web services are the most important?

The two standards that everyone agrees make up the core of Web services are:

n Web Services Description Language (WSDL), which is based on Extensible Markup Language; entities use WSDL to describe what their Web services do and the format for sending messages to them.

n Simple Object Access Protocol (SOAP), used to encode the information in Web services request and response messages before sending them via a network.

Other standards are not as widely accepted, and their importance depends on the type of Web services you build and the software development approach you use. For example, Beckley said that Universal Description, Discovery and Integration (UDDI) is an important standard. It enables organizations to build directories that list the Web services they have made available for use, provided that permission is granted.

However, most Web services currently deployed, especially those in government, consist of two or more applications linking in a predetermined fashion, not the more ad hoc picking and choosing among components that UDDI theoretically enables.

Another up-and-comer that many people feel may eventually join the core group of standards is Business Process Execution Language, which defines a standard way of describing how business processes work and interact with Web services.

But, for now, the essentials are few.

"Web services have to utilize SOAP and WSDL," Stack said. "That's as far as we go."

FAQ: How secure are Web services?

Web services are probably as secure as anything else that must function on a network. If an organization is adequately covered by firewalls, well-designed security policies and encryption techniques such as Secure Sockets Layer, then these measures will also protect Web services.

Standards such as Web Services Security, which provides an authentication and authorization framework specific to SOAP messages, have also recently been developed. These are important, because Web services operating outside the firewall are open to everyone.

Still, Web services introduce concerns that keep some people nervous about security.

"With Web services, you have machines talking to each other, so an initial security error can repeat very quickly," Beckley said. For example, with the automated computer-to-computer connections that Web services enable, a virus on one system can be spread very quickly to other machines before someone detects it, especially if the application involves high transaction volumes.

That calls for a greater vigilance with Web services, he said. However, he questions whether there's enough knowledge about the security needed for Web services, because up to now most have been developed to run only behind organizations' firewalls.

"That's a more basic security than is needed for Web services exposed to the world," Beckley said.

Different kinds of security are needed depending on the application, Niemann said. For example, with medical services, security is crucial because of privacy mandates, he said. Other applications might have less stringent security requirements.

"However, I would agree that security is still a major drag on Web services commercialization," he said. "We need to demonstrate that interoperability has increased and that it can be done securely, on an ongoing basis."

FAQ: Are some applications not suited to Web services?

Because Web services are such a boon to integration, one might be tempted to apply them to every situation, but sometimes they would be inefficient or simply wrong.

For example, it would be overkill to use Web services to meet the basic administration needs of an agency, Brooks said.

"For communications within an agency, it would be better going point-to-point," he said. "Using a Web service for this would be like going around the globe to get around the corner."

Similarly, using Web services to transfer large volumes of data such as those produced by satellite imagery would also be a misuse, because that type of transaction is inherently point-to-point.

Web services are also not a good fit for situations in which network connectivity is subject to interruption, such as on military ships at sea. The loss of a ship's Web connection would mean trouble for people who depend on Web services to deliver up-to-date information.

But some applications are a good fit with current Web services technology. For example, at one point, experts thought Web services would not be good for applications that handle large numbers of transactions because the SOAP and WSDL packaging for each file would probably end up larger than the source data.

"But we've proven that even the very largest organizations such as the Army can now send large numbers of transactions over the Web," Beckley said.

FAQ: How long does it take to build a Web service?

The answer depends on what you mean by "build" and what you use to do the building. Making an existing application available as a Web service is easy if it was built in a component-based fashion or is already compatible with some of the standards, such as XML. But if the application has to be rebuilt and other parts of the organization have to be consulted, the whole process could take weeks or more.

"Where there's just a few parameters to consider and the service that's needed is simple, then it might be a matter of just wrapping everything in the SOAP envelope," said Adam Hocek, chief technology officer and president of Broadstrokes, a software development firm specializing in XML. "But where you have to come up with a description of the XML document and a schema for that, and some complexity is involved, then it will take longer."

SBA makes the Web services connection

To illustrate the system-spanning benefits of Web services, think of an application that handles transactions inside an agency and with external partners, said Steve Seaquist, chief technology officer at Contemporary Technology. The company is a contractor for the Small Business Administration.

SBA's guaranty loan process fits the bill. Borrowers apply to SBA for a loan, and SBA guarantees the loan or a portion of it against payment default. A number of companies package various loans together to make it easier to get a guaranty from SBA, Seaquist said. They offer that service to the banks that provide the loans, and in return the banks pay them a fee.

Those consolidators "have their own application compliance software and have a need to be able to submit loan information [to SBA] directly from their own systems," Seaquist said. "So we gave them a Web service that they could call, passing [Extensible Markup Language] data [to SBA], which we could then input directly into our system and validate to see if they met the criteria for a loan guaranty."

If everything matched, SBA officials could issue a loan guaranty number in seconds, during the same Web services transaction. Previously, applicants for guaranty loans filled out a paper form and mailed it to SBA, where employees then keyed in the information by hand.

"Using Web services this way, we can now guarantee over 100 loans a day," Seaquist said.

— Brian Robinson

Web services and SOA: One and the same?

Web services and service-oriented architecture (SOA) are frequently mentioned in the same breath, but are they the same thing? If not, which comes first?

For Appian's Michael Beckley, there is no argument. "All new [Web services] should be built on top of an SOA," said Beckley, Appian's co-founder and vice president of product strategy. "Then you build them using business process management tools, and you know you've thought through what needs to be shared and what needs to work."

An SOA is a software development and management approach in which independent application components are built and can be called on to work together to handle some business functions, such as processing loans or providing requested information. Web services are one type of technology among many that can be used to create applications that comply with the vision of the SOA's developers.

Although the creation of an SOA should precede the deployment of Web services, reality might dictate otherwise, said Jeff Schneider, chief executive officer of Momentum Software. In some cases, agency officials might ask their technology staff to build Web services for integrating small, time-sensitive projects, so there's no time to outline an SOA strategy.

"But even then, they should be aware that SOA is a theme that is coming to [information technology] departments everywhere," he said. "So they'll need to pull that together at some point."

IT specialists can build a Web service, deploy it and operate it without an SOA, said Robert Stalick, CEO of IT services firm Internosis. "But what happens when you put it in place that way without such things as configuration control?" he asked.

You will only be able to extract the real value of Web services if you think about them in terms of an SOA, Stalick added.

— Brian Robinson

NEXT STORY: Review: DeviceLock plugs holes