In this hour, you will learn about how Web services have been used in the real world. As part of this, you will see
Several case studies showing how Web services have been used to help companies achieve goals
Web locations with Web services directories that you can tap into or register your own Web service at
As you’ve seen in previous hours, Web services can be used to help solve a number of distributed and client/server computing problems. Now that you understand how to build them, it’s time to see some in action. Hopefully with this information at your disposal, you’ll be able to convince your boss that people actually do use this technology to solve real-world problems. You should also get a number of ideas as to how you could use Web services in your own organization.
As you’ve seen in previous hours, Web services can be useful both for exposing your organization’s internal systems for use by external entities and also for linking together systems that completely lie within your organization. To illustrate how a number of companies have used Web services to serve both of these purposes, while simultaneously providing real benefits to their companies, we will examine six examples. The first three show how some of the biggest names on the Internet are using Web services to expose their systems for use by outside developers. The second batch of three examples shows where companies have used Web services internally to help build systems, link together various applications, improve their bottom line, and reduce development time.
In April 2002, one of the largest and most well-known Web search engines, Google, decided to open up its directory of over three billion Web pages for access via Web services. This would allow application developers to integrate the Google search engine directly into their programs. The program didn’t have to be a Web site, though. Some possible uses of this service include
Automated systems that look for new or changed entries over time on a particular topic and report those back to the user
Information gathering and dissemination systems that look at the Web and try to find patterns across search results
Information games utilizing data found on the Web
Google has provided a beta version of its service for use with the only restriction being a 1,000 query per day limit on the account. Each developer must register for his own account.
How does this help Google? First, its engine is exposed to a larger number of users. Second, as part of its developer area, Google encourages the exchange of ideas on how to use its data engine. This gives Google new areas to look into adding to its service (much like Yahoo! has grown into more than just a Web Search engine).
The Google developer package can be downloaded from http://www.google.com/apis/download.html. You can examine the APIs that the Google Web services support by examining the WSDL file for them at http://api.google.com/GoogleSearch.wsdl.
Let’s give a brief example on how to use the Google API. We’ll work this example using the GLUE Web services toolset. Although the steps involved might be slightly different for whatever toolkit you use, the overall process is the same.
First, download the Google API toolkit and unzip it to some location on your machine. Included within that zip file is the WSDL schema file for the Google Web services. Next, open a command-line window and navigate to the webservice24hoursch23 directory, which is where our client code will live. Then type the following command, replacing <rootdir> with the drive and parent directories of the location where you unzipped the Google toolkit to:
wsdl2java <rootdir>googleapiGoogleSearch.wsdlThe WSDL program will parse the WSDL schema and produce a number of .java code files that form the interface layer for our client. The files created are
IGoogleSearchPort.java GoogleSearchServiceHelper.java GoogleSearchResult.java DirectoryCategory.java ResultElement.java GoogleSearchService.map
If we examine the IGoogleSearchPort.java file that is created, we see that the Google API can respond to three different calls. They are
doGetCachedPage()—. Sends back the HTML for a page currently stored in the Google cachedoSpellingSuggestion()—. Returns a suggested spelling for a passing in word or phrasedoGoogleSearch()—. Performs a Web page search against the Google index
Now that we have the supporting files, we can write a client. The client found in Listing 23.1 will perform a search on whatever search terms you pass in, fetch the results, and display the URLs. The Google search API has two limitations that you should be aware of. First, the doGoogleSearch method will restrict you to receiving 10 results at a time. If more than 10 matches exist, you’ll have to perform the search again, requesting the next batch of 10 results, and so on. Second, there is a limit of 1,000 queries per day. As a result, if you perform a search that has 50,000 hits and let it run to completion with the 10 hits per search, you’ll run out of queries before you can even finish the search.
Example 23.1. A Sample Google Search Client That Uses the Google Web Services
import electric.registry.Registry;
public class ourSearch
{
/**
* Description of the Method
*
*@param args Description of the Parameter
*@exception Exception Description of the Exception
*/
public static void main(String args[])
throws Exception
{
if (args.length != 1)
{
System.out.println("Include search terms enclosed in ".");
System.out.println("For example "Commodore Amiga 2000"");
System.exit(-1);
}
// This part will be different depending on your toolset.
IGoogleSearchPort search = GoogleSearchServiceHelper.bind();
// Your search key will be mailed to you when
// you register to use the GoogleAPI.
String key = "bV8vwfxQFHKmgaPdMwfu8jRaCkpgkBAS";
// Set optional attributes
// Invoke the actual search
// Do this in a loop since the max number allowed to be
// returned at a time is 10.
GoogleSearchResult result = null;
result = search.doGoogleSearch(
key,
args[0],
0,
10,
false,
"",
true,
"",
"",
""
);
// process the result
// First we'll just show the result metrics
System.out.println("Estimated number of hits:");
System.out.println(result.estimatedTotalResultsCount);
System.out.println("Search time:");
System.out.println(result.searchTime);
System.out.println("RESULTS:");
System.out.println("-------------------------------------");
// Now the actual results. The API restricts us to 10
// results per search, so we have to do the search over
// and over getting the next batch of 10 results...
ResultElement[] elements = null;
int startpos = 0;
boolean flag = true;
while (flag == true)
{
result = search.doGoogleSearch(
key,
args[0],
startpos,
10,
false,
"",
true,
"",
"",
""
);
elements = result.resultElements;
for (int i = 0; i < elements.length; i++)
{
System.out.println(elements[i].URL);
}
if (elements.length < 10)
{
flag = false;
}
startpos = startpos + 10;
}
}
}
If you’re using a toolset other than GLUE to build the interfaces, you might need to alter the code slightly. Also, you’ll need to replace the key value in the program with the one sent to you by Google when you registered. Compile the program code by typing
javac *.javaTo execute the search program, type
java ourSearch "Sams Publishing Java 2 Unleashed"You should get back the time that the search took, the number of estimated hits, and a listing of all the search results. You’ll probably want to press Ctrl+C to stop the program before you exhaust all of your query quota.
In July 2002, Amazon—the largest online retailer and one of the most popular Web sites around—provided a Web services interface to its inventory. This allows users to create their own interfaces to the Amazon store. For instance, using the Amazon API, it would be possible to build all sorts of comparison shopping interfaces that currently might not be available on the Amazon.com Web site. Rather than waiting for Amazon to build those capabilities, you can build them yourself. Even better, you could build your own Web service that makes use of the Amazon Web service and then post it for others to use. This provides Amazon with even more sales opportunities. Developers can make use of Amazon’s product descriptions, reviews, search systems, and wish lists, as well as other features such as the shopping cart.
Say, for instance, that you wanted to build a portal dedicated to motorcycles. In part of your site, you’d like to include links to the Amazon store for products related to motorcycles. With the Amazon Web services, you can now do that very easily without having to build your own commerce engine, shopping cart, and so on.
In fact, this arrangement has proven to be beneficial not only to Amazon, but also to members of its Associates Program. This program was started in order to allow other online retailers to link to Amazon for actual ordering of merchandise. The retailer receives up to a 15% kickback of the purchase price of any order originating through its site. The Web services engine has allowed such retailers to easily create enticing storefronts and at the same time drive up sales for both themselves and Amazon.
Prior to the Web services initiative, to build such a service required screen scraping and a lot of HTML rework to make the site be branded as the retailer’s and not Amazon’s. With the Web services, it is a much easier endeavor.
The Amazon.com Web Services Developers Kit can be found at http://www.amazon.com/webservices. The kit exposes two main areas of interest. The first is the Product Display area that allows users to search the product catalog and retrieve information about the products listed within. The second area is the Shopping Cart, which provides users with an API to add products from the catalog to the Amazon shopping cart, wish lists, and gift registries.
Much like the Google API, Amazon requires the developer to register for a unique product key that is passed during all Web service invocations to identify you. If you want to write a client that uses the Amazon API, you’ll need to register for one of these keys. (Amazon refers to them as Tokens.) Also, similar to the Google API, the Amazon API has restrictions on the number of results returned during searches, the number of reviews returned for a product, and so on. Check the API documentation for the specific restrictions.
The API provides a number of different search methods, categorized by the main type of search (for instance AuthorSearchRequest, UpcSearchRequest, AsinSearchRequest, and so on).
To develop a client that utilizes the Amazon API, you can perform steps similar to what we did in the previous Google example, instructing the wsdl2java program to read the WSDL schema found at http://soap.amazon.com/schemas2/AmazonWebServices.wsdl. Aside from the different classes and API calls, the overall process involved is the same as it has been throughout the book. Use the WSDL to make your interfaces, and then write your client making use of the interface classes.
Microsoft recently released a new version of its MapPoint Web site. This new version provides a Web services interface for developers to tie into. Microsoft, in a battle with other companies such as MapQuest, saw a need in providing a simple programmatic interface to its map database.
With the new Web services interface, developers can write software that, for instance, ties addresses in a sales database to the mapping system to fetch out driving directions for sales people. Another interesting capability of the service is reverse geocoding, whereby longitude and latitude information from a GPS can be converted to a street address. Web site developers can quickly integrate maps of areas—say a map of the surrounding area for a vacation resort or driving directions from the nearest airport.
Although competitor MapQuest does have a programming API to tie into its system, it is proprietary and not Web services based, which means that developers wanting to use it would require more time and effort to learn and use it than the MapPoint solution.
To reach the MapPoint.net technical documents and support, visit http://www.microsoft.com/mappoint/net/. There, you will find the MapPoint SDK. Microsoft has provided extensive documentation, including a number of examples in both Visual Basic and Visual C# showing how to work with the service. Being a Microsoft product, the documentation and interfaces are heavily centered around the .NET development framework. As such, it is recommended that you use .NET to build any systems that you want to hook into the MapPoint API. This doesn’t mean that it’s impossible to use other toolkits and languages, only that it will be more difficult because of the lack of direct documentation and support.
The MapPoint SDK includes support for four Web services:
Common Service—. A group of classes that provide common support for the other three services.
Find Service—. Locates addresses, points of interest, latitude and longitude coordinates, and so on.
Render Service—. Draws out maps of locations and routes.
Route Service—. Provides trip routing service capabilities. Can calculate driving directions and work with either waypoints or locations.
With these services, it is possible to create complex tools for finding addresses, planning trips, providing personalized driving directions and maps, and a host of other activities.
The services are provided on both development and production hosting environments. Use of the development (or staging) environment is free, but has limitations on the number of interactions that can be performed over a period of time. The production environment is a pay service, based on usage, but it does not have the same limitations and can scale much better than the staging environment. For your own personal development, use the staging environment. Only move to the production environment if you are building a system for commercial use and will be able to pay the usage charges!
The WSDL schema for the staging server can be found at http://staging.mappoint.net/standard-30/mappoint.wsdl.
Financial powerhouse Merrill Lynch has recently turned to Web services as a way to reduce its internal development costs and increase reusability of its internal systems. Although not a publicly available service, Merrill Lynch has seen internal benefits in the Web services approach.
Being a large company with a history in IT stretching back to the early days of computing, Merrill Lynch is probably the best example of where Web services can help with integration. Owning many systems, created over various generations of IT methodologies, Merrill Lynch, and other companies like it, have found it difficult to integrate and reuse features of one system inside of another. By embracing Web services as an interface to all of its systems, Merrill Lynch is able to reuse features of its existing systems when building new ones. In one case, this new paradigm took the company from an $800,000 estimated solution built using traditional methods to one costing $30,000 using the Web services approach.
The Web services paradigm has also allowed Merrill Lynch to provide more services to its partners by exposing some of these interfaces directly to them in an easy-to-understand manner. Gone are the days of partners needing special knowledge of the company’s systems in order to integrate. Now, it’s just a WSDL address and a few accounts that are generated, and that’s it.
Leading do-it-yourself home improvement retailer The Home Depot ran into a dilemma. It had been using a point-of-sale system that was homegrown, monolithic, and very hard to extend and modify. The system was client/server in nature and used UDP for communications between the terminals and the local server in each store. The system worked, but it wasn’t ideal. Although the terminal software was compact and fast, it also structured data into silos, restricting information in one area from being used in another. The information being passed from the client to the server was also being encoded in its own format. The company found the solution to have several problems, including
Not all the store systems had easy access to the data messages that were transferred between the client and the server. This data was often cryptic and proprietary. This made the sharing of the data between different applications very difficult to achieve.
There was no real contract or schema to describe the message sets in a standard fashion.
Internationalization meant changing code that parsed the byte streams and client code that created the byte streams.
Because the program was monolithic (one executable with many threads), regression testing of all functionality had to be performed by QA prior to release, requiring great time and expense, in addition to added complexity.
In the quest to find a better solution that would be more modular in design and allow for more reusability, The Home Depot decided to go with a phased approach to replace its system.
In the first phase, the proprietary data streams over UDP were replaced with XML data sent over TCP. Although this wasn’t a full change to Web services, it allowed for a gradual transition to SOAP and the more accepted Web services standards. With more than 1,500 terminals to be upgraded, a full cut over from the old mechanism to the new would not be prudent nor feasible. The decision to go to this phase was made at a time when Web services technologies were just starting to evolve, and their direction was still in doubt. By taking this interim step, The Home Depot was able to fix many of its existing problems by evolving its software to a halfway phase and waiting for the standards to catch up. Evolution, rather than revolution, is often more advisable when dealing with business systems.
In the second phase, The Home Depot is rolling out not only the system from phase 1, but also a number of new applications that will all tie into each other through the Web services mechanisms. Whereas old systems used to run on Novera and JRun Java application servers, the new applications will be hosted on IBM WebSphere and make extensive use of the Web services paradigm through Microsoft’s .NET offerings and Apache Axis for the Java-based systems.
The Home Depot has also found the switch to Web services beneficial—teams that previously were not able to share capabilities because of differing technologies (Visual Basic, Java, COBOL, and so on) now have the ability to leverage each other’s work. The Home Depot has found the ability to use WSDL to generate code for .NET bindings, and the generation of Java code for .NET servers to be an ideal solution. This synergy of technologies is allowing the company to speed up deployment of new applications and share capabilities among all teams, not just the ones using the same technologies. At the time of this writing, the company has just started its conversion of the systems in the store.
As a large provider of healthcare services in the United States and Canada, Providence faced a dilemma. It had a large number of dissimilar IT systems that needed to be linked together not only for company use, but also to provide access and interfaces for vendors and suppliers.
In an effort to help tie all of these systems together, a new project was launched. The goal was to pull together all of these numerous systems, provide secure and robust interconnection, and make all new systems comply with the federal HIPAA (Health Insurance Portability and Accountability Act) standards. This was no easy task.
Providence had already been a primarily Microsoft-based shop, so the company chose to use the .NET framework for building its solution. Visual Studio provided its developers with all the tools for quickly building Web services applications.
The Web services architecture also needed to run alongside and tie into the company’s existing Enterprise Application Integration (EAI) framework (rather than replace it). In this case, the fact that Web services are built on XML and are cross platform and language independent proved to be a large help to Providence because most of the EAI was developed in other systems such as Java.
One of the first steps Providence took was to develop a systemwide, profile-based authorization and authentication system. This would allow all applications to be able to verify who a user was and what he could do. This tool was written in Java, but it was easily accessible via Web services. Doing this allowed all new applications to share this common concept of a user and the user’s security capabilities rather than each system creating its own. This alone has saved Providence large amounts of time in developing new systems.
In order to handle Web services management and provide the necessary monitoring and accountability, Providence turned to a product by Infravio. This product acts as a middleman to monitor the Web services infrastructure and report any problem. This has allowed Providence to handle many of its HIPAA requirements that would have been very difficult to do without a Web services architecture.
Figure 23.1 shows the architecture Providence is using at a high level.
Now that you’ve seen how others have used Web services to build successful real-world solutions, we’ll examine where you can go to find services that others have provided for use. Many of these sites also allow you to list your own services for use by others. Some are strictly for listing free services, whereas others provide a framework for charging for your service. By looking through these sites, you should get a better understanding of what services are available to tap into across the Web and possibly find services that will provide capabilities that you might be looking for.
One of the more popular free Web services directories is run by xmethods.com. One of the best features of this site is that it lists the available services not only by name and function, but it also explains what style (document or RPC) and what tool the service was implemented in. So, for instance, in the case that you’re using Apache Axis as your interface technology and want to find services that also use Axis, you can simply look through the list to find them. Of course, with Web services and the SOAP/WSDL/UDDI standards, you can use any toolset to access a service built with any other toolset.
All services found at the xmethods site are free of charge and for noncommercial use. Although this means that you shouldn’t use them for commercial systems, you can still utilize the services found here for experimentation and learning or personal-use systems.
Some of the services available on the xmethods directory range from stock quote engines to FedEx package tracking services to services that calculate the distance in miles between two ZIP Codes.
To access the services found at the xmethods site, a UDDI interface has been provided. Depending on the toolset you use, the process will be different, but simply point the toolset to the URL http://uddi.xmethods.net/inquire to get to the UDDI listing. (Note: This URL will not work in a browser.) From there, follow the process for your toolset to look through the index and build the client-side interface to the service you want, utilizing the WSDL interface provided.
The xmethods site also has a relatively good mailing list in which members of the site can communicate and discuss problems and solutions. Free registration to the site is required for posting any new service to the site and can be accomplished by clicking the Register link on the main page.
The salcentral site acts as a Web services brokerage system. Much like xmethods.com, Web services are listed and categorized for visitors to see and use. Salcentral is different, however, in that it provides a pricing system by which you can easily charge for access to any service you post to its index. This is nice in that it eliminates the need for you to build these features yourself, and also puts your service into a centralized high-traffic clearinghouse environment in which more people are likely to see your service and pay to use it.
Salcentral also has a large variety of services listed on its site. At the time of this writing, its index included more than 600 services. Users are able to provide reviews and ratings on the various services as well.
In order to use any of the services on this site, a free registration must be filled out and completed. Once registered, simply select the service and click on the schema link to get the WSDL interface. From that WSDL, the toolset of your choice can build the necessary interface components for your client.
For services that you want to provide and charge for through the salcentral system, a special set of steps must be performed. The instructions for doing this can be found at http://www.salcentral.com/salnet/wpsubws.htm. Basically, it involves adding a few parameters to your services to capture username and password information so that users can be identified by the system.
In all, the salcentral site provides a great way to find and stay up-to-date on the Web services out there. The reviews, user-provided scores, and notes sections for each service can be a real help in choosing the one that is right for you and can be instrumental in providing a good interfacing experience for users of your services.
The remotemethods.com site also acts as a clearinghouse of Web services. The developers of this site have attempted to provide access to available Web services in a categorized manner, similar to the categories found on Yahoo and other top Web search engine sites. The classification system is multitiered and fairly extensive, which should help in finding the right service for your needs. Again, the services found here run the full spectrum from simple calculation engines to message-of-the-day joke servers to graphics charting systems.
Much like salcentral, remotemethods provides a mechanism for users to post reviews of the services for others to see and evaluate as well as a site-ranking system. Services found either in a category or via a search can be listed according to various criteria such as price, popularity, ranking, and date.
If you’re using the Microsoft .NET framework for building your Web services, one of the best sites to go to for finding other such services is the Microsoft UDDI server at http://uddi.microsoft.com. In order to use the services on this site, registration is required using the MS Passport system. Once registered, finding the services available on the site can be a bit of a daunting task because of the way in which MS has organized the information.
To get started, click on the search link on the left side of the screen. This will bring up the first page of the search criteria system.
Note
It is recommended that you make use of the Quick Help-Searching UDDI option in the upper right corner in order to better understand how to use this system.
For example, in order to bring up a list of all RPC-style services currently listed, follow these steps:
From the main search screen, click on the Services tab.
Click on the Add Category button.
Click on uddi-org:types.
Click on These Types Are Used for tModels.
Click on Specification for a Web Service.
Click on Specification for a Web Service Described in WSDL.
Press the Add Category button.
In the Service Name field, enter
%(the wildcard character).Then press the Search button.
If you’ve followed these steps, a listing of all matching services in the UDDI directory will show up in the left frame on the page, along with brief write ups on each. Clicking on one of the services listed will display information, including the WSDL address to reach the schema for this service. Simply point the Web services toolkit of your choice to that address to find the WSDL specification for that service and generate the needed client-side files to access it.
In this hour, we looked at how Web services are being used in the real world. We first examined a number of case studies documenting how real businesses have used Web services to achieve greater return on investments (ROI) and lowered their development costs.
Next, we examined a number of the publicly accessible Web services directories found on the Web. We saw how to find what Web services were available and briefly discussed how to get your own service posted to these indexes. We saw that there are already a large number of freely accessible Web services for use, and that number will certainly continue to grow rapidly as the technology matures.
With the information you have, you should now have a much better idea how to take your work and share it with others or find Web services that others have developed and use them yourself.
What’s an example of a useful system that could be built using a number of the Web services that we looked at in this hour? | |
How about a Web site in which the users could search the Amazon store for a listing of all the cameras sold there via the Amazon API? In a side panel, a list of links to pages containing reviews about that camera could be displayed from the Google API. And finally, FedEx tracking information for the package or stock prices for the camera company could be seen in another area utilizing services found on xmethods.com. | |
Why should I list my service on one of the service directories discussed in this hour? | |
If you have a Web service that you aim to make publicly available, you probably want somebody to actually use it. These are some of the most popular sites that developers go to when looking for a Web service to suit their needs. Therefore, listing your service on one of these directories will help to draw users to your solution. | |
Should I bother listing my service on more than one site? | |
Absolutely! Similar to Web sites, the more indexes your service is listed on, the more likely somebody will be able to find and use it. | |
Should I charge users to access my service? | |
This is entirely up to you. As we’ve seen, some of the directory services provide tools for making this possible. Standards in this area are still lacking though, so at this time, most public Web services are free. | |
Should I link to these services using UDDI or just the browser to find the service I want through the Web? | |
Again, this is up to you. If you’re looking for something very specific, it is usually easier to manually find the service you want through the Web interface. However, if you want to use the UDDI interface, nearly all the directory sites we examined in this hour provide one. |
This section is designed to help you anticipate possible questions, review what you’ve learned, and begin learning how to put your knowledge into practice.