Web Services FAQ
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
With all the industry hype regarding XML Web Services, especially with the pending release of Visual Studio .NET and the .NET Framework from Microsoft, information technology professionals are wondering how these technologies will impact them and the organizations for which they work.
NOTE
For a baseline understanding of the history and technologies involved, see the excellent description by Kenn Scribner and Mark Stiver here on InformIT, The Road to Web Services.
In my discussions with clients over the last several months, several major concerns appear time and time again. In this article, I'll address the top three concerns to give you an idea of how they are or might be addressed as Web Services mature.
Question 1: In the past, users had to go to my site to view information and thus view banner ads for which advertisers paid me or other services that I wanted them to purchase. If I allow users or other sites to access information programmatically via SOAP without a UI, isn't that equivalent to giving away my product for free?
Answer: Of course, the thought that runs behind this question concerns making money from Web Services. Here I see three distinct models for Web Services and how they'll be employed.
First, you'll see the widespread use of Web Services as a value-added service to existing customers or as a free preview to potential customers. This will happen first as developers become accustomed to the technology and can be implemented quickly. This will be the case because the existing infrastructure will already support manipulating the required information.
For example, the company for which I work, Quilogy, provides vendor-certified training to its clients. Currently, customers must visit our Web site to query course schedules and sign up for courses. However, Quilogy could publish a simple Web Service to provide this same functionality and then allow corporate clients to access the service. This would allow those clients to incorporate Quilogy schedules into their corporate intranets or other internal sites. In this case, Quilogy would not charge for use of the Web Service but would provide it to better serve existing clients.
In this stage, the only money that you'll make from Web Services is derived from the value of better servicing your customers. In using this model, security will not typically be a concern, although, in a minority of scenarios, authentication and authorization will be employed to customize client-specific information.
Second, you'll see the use of Web Services to implement electronic commerce between organizations in business-to-business scenarios. In these scenarios, Web Services will be used to transmit messages between business partners in supply chain, purchasing, and other applications. For example, Microsoft BizTalk Server 2000 can use Web Services to transmit data between organizations and kick off business processes through its Orchestration engine. In these cases, there will typically be an existing agreement in place between the business partners. On one end of the relationship, the revenue will result directly from the use of a Web Service, while on the other, the enhanced service, lower overhead costs, and more efficient processes all will serve to lower costs and increase business. In this model, organizations must be concerned with authentication, authorization, and encryption.
Finally, Web Services will be sold as programmable components publicly accessible over the Internet that can be snapped into Web-enabled applications. For example, a provider of weather information could create a Web Service that returns current conditions and local forecasts. In many respects, this model poses the biggest challenges because issues of registration (how do users find my Web Service?), authentication, authorization, and billing must all be addressed. Although general issues of security will be addressed in the next question, in these scenarios a Web Service provider would need to implement a subscription-based or charge-per-use infrastructure. In both cases, custom code that logs client accesses would need to be developed.
Question 2: If Web Services use XML and HTTP that is human-readable and can pass through firewalls, how can communication be secured?
Answer: Although one of the advantages of Web Services is that they are based on Internet standards, that doesn't mean that they can't also be secured. For example, because Web Services are served from Web servers, you can use authentication mechanisms built into Web servers such as Internet Information Server (IIS). In the case of IIS, you can use basic (clear-text), Windows, or digest authentication more or less transparently over calls to a Web Service when using Visual Studio .NET as a client. In addition, a W3C working group is currently developing a specification for allowing digital signatures to be embedded in XML, to allow for authentication using digital certificates. As an example of the kinds of technology being evaluated, see the XML Security Suite from IBM. In addition, Microsoft provides support for an implementation of XML digital signatures in beta 2 of the .NET Framework in the System.Security.Cryptography.Xml namespace.
Second, you can take advantage of protocol-level security by providing Web Services through Secure Sockets Layer (SSL) protected sites to encrypt the contents of the SOAP messages. You can also implement your own security schemes by manipulating the SOAP packets as they are being sent. The .NET Framework provides an easy-to-use extensibility mechanism to do just that, as discussed by David Platt in his Thunderclap newsletter. In addition, of course, third parties such as Entrust will provide add-on tools and utilities to facilitate secure communications.
Third, SOAP messages include headers in the HTTP packet that can be filtered by firewalls to prevent Web Service traffic on a network.
Finally, there will be scenarios where your Web Service needn't handle the authentication process at all. For example, Microsoft, in its Hailstorm initiative, looks forward to a day when clients use a single-sign-on service such as Passport. Once authenticated, the client accesses your Web Service with credentials that you validate with the Passport service to authorize them to use your service, in addition to discovering billing information and other data that the client has enabled you to see.
Question 3: Doesn't introduction of Web Services promote fragility in applications that consume them?
Answer: The answer to the question, in a word, is yes, although much work is being done in this area.
The general concern, of course, is that if a consumer binds to a Web Service over the Internet, the Web Service provider might change the interface to the Web Service without notice at any time, thereby breaking the client without warning. In addition, if the provider is offline for some reason, how can the consumer be alerted to the fact?
First, in general, it should be noted that because Web Services are described using XML, they are fairly resilient to change. Therefore, consumers of Web Services are not affected by changes to a Web Service such as the addition of a method that might break more tightly coupled technology such as COM. However, if the provider changes the method signature of a Web Service that is in use, the change will likely break the consumer. To alleviate some of these problems, development tools can be built that automatically update consumers based on the latest description of the service from the provider. For example, Visual Studio .NET includes an Update Web Reference option that re-fetches the Web Services Description Language (WSDL) document that describes the service and re-creates the proxy object used to call the service from the consumer.
Second, you need to be aware that the publication and discovery of Web Services is specified using standard APIs published by the Universal Description, Discovery, and Integration initiative. Basically, UDDI supports registries of Web Services that development tools can call programmatically to find and locate Web Services. Therefore, a development tool or custom code can, in theory, for example, access a UDDI registry to find an updated or alternative reference to a Web Service if it finds that the desired service is offline. Many vendors provide UDDI SDKs that allow for the creation and querying of UDDI registries.
Finally, it turns out that WSDL promotes the separation of the interface of the Web Service (its method descriptions) from the binding, which specifies the actual URL to call. In this way, industry-standard interfaces can be developed that are implemented by multiple Web Service providers. Coupled with UDDI, this means that consumers will be capable of automatically finding equivalent services if a service changes or is unavailable.
Although Web Service technology is definitely still maturing and there are concerns, the promise of programming on a global scale and the encouraging cooperation by vendors should alleviate these concerns and eventually fulfill that promise.