Choosing the Right Technology

As you've already learned, XML Web Services have a great deal of flexibility, but they aren't the right choice for every situation. While you could write all your applications using only XML Web Services, this would not be the best approach. For one, XML Web Services are not high performance components and would cause local applications to be too slow to be useful. Web Services don't provide the “stateful” programming environment that many developers require. They will provide information on demand, much like a Web site.

However, XML Web Services do make sense in a number of scenarios, some of which are documented here as examples.

Read-Only Access to Data

There are many cases in which users or applications require read-only access to data living on servers outside your company or organization. Directly integrating with the outside company is typically not allowed for security reasons, and even if you were integrating with them directly, there is always the problem of data conversion and formatting. All you really need is a copy of some piece of data at some point in time to allow your application to continue doing what it needs to do.

For example, if you go to get stock quotes, you are getting read-only data. You can use this data in a variety of ways in your own application, but your interaction with the stock quote provider is on a read-only basis. You may be requesting a single real-time quote, or you may be retrieving extensive financial data on a company through a service that aggregates this information from hundreds of companies.

In this situation, using an XML Web Service would be a great solution. The provider of the data can create a Web Service that responds to several types of inquiries, from a simple real-time stock quote to a request for information about a company. These types of inquiries are published as part of the Web Service, and companies needing this data can code their applications to use the Web Service to retrieve the data. The company providing the data benefits by making its data available to more customers, who might even be paying for the data. The companies using the data benefit by not having a huge consulting bill for writing custom integration software and, at the same time, getting the data from the provider for use in their applications.

Write-Only Access to Data

Some systems provide you write-only access to data. If you submit an order to a company, you are essentially writing the data into their system. You may have some options for modifying the order before you send it, but typically, after the order is sent, it's a done deal.

For example, many Web-based stores (including my own) do not stock inventory; instead, they have a distributor send the product directly to the end user. The distributor makes a little bit of money on every product, but they're really in it for the volume. As the store selling the product, I want to automate the process of sending the user's order to the distributor and not have to key the order in a second time to the distributor's order system.

An XML Web Service at the distributor could help alleviate these problems. With the proper authentication, the Web store could send a payload of data to the distributor to place an order. This would be done as soon as the end user confirmed the order. The Web store would then get status information back from the distributor indicating that the order was placed, back-ordered, or whatever status was provided. This information could then be presented to the end user as part of the Web store interface. The end result is that data duplication is kept to a minimum, the user's experience is not confused by forcing them to look in several places for status information, and the Web store is able to handle more orders than they might if they had to manually key in every order that came via the Web site.

Read/Write Access to Data

In many situations, you may need a combination of reading and writing data via a Web Service. In the Web store example, the distributor Web Service may return status information on all the products, including whether those products are in stock or on back-order. The Web Service at the store may then send back another packet to cancel the back-ordered items but leave the other items on order. That information would then be updated in the distributor's order database.