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
"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."
NEXT STORY: Review: DeviceLock plugs holes