 | |||
|
Friday May 25 2001 Web Services 101 What Are Web Services? Today, the two most popular technologies used on the Internet are e-mail and the World Wide Web. Over the next few years, we're likely to see another Internet technology become very important: "Web Services". Web sites are basically designed to share information and provide interaction between a person and an organization. Looking at the home page for a typical news site will, for example, let you see the headlines for the day, or looking at a stock market site will let you see the current position of your portfolio. These two interactions are examples of information exchange - you make a request and you're provided with information. However, over the past few years we've seen web sites capable at providing a deeper level of interaction, for example buying a book from Amazon.com, or trading shares. A Web Service is a kind of web site that tries to remove the human element. Instead of you browsing to a specific page and looking up a specific stock price, a piece of software does it instead. Data is Everywhere The Web contains an astonishing amount of information. Pretty much anything you could wish to find is published on the Web somewhere. However, as we've said, the Web is geared towards being interpreted by humans, which means that the data contained on each page is hard for software to understand. Imagine you wanted to write a piece of software that e-mailed you with your current stock portfolio positions every hour when the market was opened. Before the Web, you'd have to negotiate with your broker to be included on some data feed, and that feed would have to somehow be connected to your office. This approach is likely to be extremely expensive and require a lot of effort to put in place. Now that we have the Web, the information is at our fingertips - there are plenty of sites out there that can provide us with up-to-the-minute quotes that we can use in our application. It's relatively trivial to write software that downloads a Web page into your computer's memory, and if we know of a page that reports our market positions, it's easy to get the price data. However, this data is not in a format that the computer readily understands. This means each time we request the Web page we have to process that page in order to extract the pertinent data. This is fraught with problems, not least of all is that because the Web site is geared towards human interaction, any changes to the way the page looks will potentially "break" the software that extracts the data from the page. What we need is another site, specifically geared towards providing other pieces of software with data in a form that can be readily understood by software. How about if the site simply decided to provide stock prices in the form of a web page of plain text? Instead of searching through the HTML mark-up which tells the browser how to display the stock prices in a manner which is pleasing to the eye and navigable by human, the computer program could simply read through a column of raw data, like this: NASDAQ 15/01/2001 16:25:03 CSCO 22.22 Cisco Systems AAI 9.9 Airtran Holdings IBM 118.35 International Business Machines ... Again, that's great, provided the site didn't change its format at all, ever. What if it decided to include information on whether the shares were up since opening of trade, and by how much? That still poses a risk of our program being broken. And while, in this case, it's obvious to us when writing our program exactly what each piece of data there means, for a more complex application, that may not be the case. Imagine a weather site, providing similarly formatted data: WEATHER 15/01/2001 16:25:03 Los Angeles CA 17 30 27 W 37 1004 29 19 ... Are the numbers minimum temperatures? Pollen counts? Barometric pressure? What units are they in? The site would have to provide some human-readable documentation explaining their data format. Web Services avoid this basic problem by marking up data using XML, the eXtensible Markup Language. This provides rich, computer-readable information about the data it contains, and it also builds on various XML-related standards, such as XML schemas, which provide even more information about the data. Data about data, meta-data, is one of the key foundations which make Web Services possible. Why Develop Web Services? Web Services can be used to create new revenue streams, create new business opportunities or offer value-added services over and above your competitors. Let's look at an example of comparison shopping. A comparison-shopping site allows a customer to quickly search across many different online merchants looking for the best price. An example of one of these sites is called DealTime. If you've never used one of these sites before, all you do is search for the product much as you would on a normal e-commerce site. However, instead of coming back with a single price, you're given a list of prices to choose from. In order to provide this service, the company needs to have a list of sites that should be included in its aggregation. Now, the company has to employ a team of business developers to find and establish relationships with the merchants. In some cases, the business development team might not be able to establish a relationship with the merchant, but the company may choose to include the merchant in the aggregation regardless. Once the company knows which merchants should be included in the aggregation, it needs to know what products the company offers. In this instance, a Web Service could be employed to return the merchant's catalog. If the company tried to do this without a Web Service, it would either have to negotiate for the merchant to send over a copy of the database, or if the company were unable to establish a relationship with the merchant, the company would have to literally walk each page on the site trying to build the information. That's an arduous task fraught with difficulty. Once the catalog has been built, the company then needs to get the current price for each item in the catalog. Again, using a Web Service the company can simply say, "What's the price of this widget?" Without a Web Service, the company would have to download the Web page and extract the price information. What I'm driving at is that although aggregation can take place without a Web Service, it's far easier to use a Web Service both from the perspective of the aggregator and the merchant. But, what's your motivation as a merchant? Simply, it's an issue of "not being included". Because it's far easier (and therefore cheaper) for the aggregator to work with a Web Service, it's likely that given time the aggregator will choose only to deal with merchants that provide a Web Service. Therefore, you might end up missing out on opportunities that your competitors can take advantage of. That aside, working with aggregators using Web Services is going to be easier for you, as you never have to worry about negotiating with them, nor do you have to worry that changing the appearance of your site will "break" the aggregation process. Using a Web Service also has advantages to the merchant itself. The vast majority of merchants ask that customers pay for purchases using credit or debit cards. Processing these credit cards either involves passing the customer over to another site to get the card validated, or installing software on the server computer that powers the Web site. Alternatively, the merchant could use a Web Service that would accept a credit card number, the amount of the transaction and return "yes or no". Conclusion In this brief discussion, I hope I've illustrated some of the ways that Web Service can be used in business. In later articles we'll take a closer look at how you can build Web Services and other types of business that can take advantage of them. Read Matt's other article for Web Services Architect: Microsoft and Web Services. Keep up to date with all the new articles and features on
Web Services Architect: |
