An Extensive Examination of Web Services: Part 4By Scott Mitchell
So far in this article series we have examined the standards involved in Web services, looked at creating Web services with Visual Studio .NET, and have examined WSDL and creating proxy classes to consume a Web service. While we have discussed the mechanics of Web services - what they are composed of, and how to create and consume them - we have had little discussion on business uses for Web services. In this article we will discuss how and where Web services can be used in an enterprise. We'll also look at how Web services are being used by businesses today.
The Utility of Web Services
When faced with a task, it is important to choose the right tool for the job. Web services are the right tool for some jobs, and the wrong tool for others. In my opinion, Web services are an ideal candidate for tasks that need to accomplish one (or both) of the following:
- Data transfer between disparate systems
- Provide a platform-independent interface to hide complexity for a system that is utilized by many clients
To see why Web services are an ideal fit for these types of challenges, let's consider two different scenarios and see how Web services can be utilized.
Transferring Data Between Disparate Systems
For the first scenario, imagine that you work as a wholesaler, selling widgets to redistributors. (These redistributors, then, resell the widgets to the public.) There might be a variety of retailers you sell to, and these retailers need some way to get the latest information about your widgets for sale. They might want to know what types of widgets you carry; what your inventory looks like; the cost per widget; and so on. Clearly you need to provide your inventory information to these resellers in some electronic format.
There are a number of challenges here, the main one being providing this information to a variety of clients who are likely using a hodge-podge of technologies. That is, retailer A might be running their business on Windows 2000, while retailer B might have their data servers running Linux. Clearly picking a technology that focuses on one platform - such as providing the data as a binary dump of a MS-SQL database - is not an option.
One platform-neutral option might be to just post the data on a Web site. That is, as the wholesaler we could export the data we want to share to a tab-delimited text file and then just post that on a Web site URL that only our retailers can access. While this is clearly platform-independent, it has one major downside: we have to tell each of our retailers how to parse our data. While this is no big deal from our perspective, this might be a major headache for retailers, especially considering that they may be buying from multiple wholesalers. If each wholesaler has their own data format, our retailers are going to have to write a lot of code to access the data.
A better approach is to use Web services, since Web services provide both the platform neutrality and a standardized means for accessing the service and for serializing and deserializing the incoming and outgoing data. Since Web services are built on standards, there are already many toolkits designed to allow for Web services and consumers of Web services to be built quickly and with minimal effort. (For example, in Part 3 of this article series we saw how using VS.NET one could build a Web service consumer in a matter of minutes.)
Data transfer scenarios are common in any industry where there are central repositories of information that need to be accessed by independent actors. For example, in the insurance industry there are a number of independent insurance salesmen who sell policies from a variety of companies. These independent sales forces need to be able to access the policy data from the insurance carriers periodically. Scenarios like these are prime candidates for Web services.
Providing Interfaces for Complex, Distributed Systems
Another ideal use for Web services is in providing a platform-independent interface to a complex, distributed system. To understand how Web services can fit in here, imagine that you work for a large Fortune 500 company that has been in business for quite some time. More likely than not, there are a number of different, independent systems used by various departments in the enterprise. For example, there may be an HR system that manages employee information, new hire information, benefits information, and so on. A system for the sales department manages current and prospective clients, past client activity, information about the sales force and their activities, and other relevant information. There are likely numerous other independent systems for other organizations within the enterprise.
More likely than not, these systems were spec'd, developed, and deployed at different times. Hence they might use different technologies and platforms. The HR system might have been created using COBOL back in the 70s. The sales force might be using a system that was designed using DB2 and C++ in the 80s. The IT group might be running their systems using VB 6 applications and components talking to an MS-SQL Server database. The point is, there are a variety of systems created a mishmash of technologies.
The challenge: make these systems interoperable. That is, a developer working on an application that ties into the HR's system should be able to easily reference the sales system. The ideal solution here is to put a Web services interface on each of the various systems. The Web service interface provides a uniform method by which all systems can be accessed, and hides the implementation complexity. That is, when an intranet developer wants to create an intranet page that displays information showing this month's top-selling products, she doesn't have to worry about how the sales system is tapped into - rather, she just connects to the Web service interface provided for the sales system, and invokes the appropriate methods to get the information needed.
The diagram to the right illustrates placing Web service interfaces on the various systems, and shows how a client can communicate directly with the interfaces so that it doesn't have to concern itself with the specific protocols or libraries needed to communicate with the specific system.
Web services make for excellent interfaces for legacy systems. By encasing legacy systems with a Web service interface, clients that wish to communicate with legacy systems don't need to use the antiquated protocols and procedures to do so. This can be especially annoying if there are a multitude of different legacy systems, each which requires its own custom protocols to communicate with. Too, Web services reduce any notion of platform dependency that may exist with legacy systems.
In a related vein, Web service interfaces are a good choice when moving from outdated legacy systems to newer ones. We all know that a big challenge of porting a distributed system is that all the clients that use the legacy system must also be ported to start using the new system. This process can be simplified if Web services are used as an interface to the legacy systems. This way, all clients talk to the Web service. Once the legacy system is ported to the new system, only the Web service interface needs to be updated - the existing clients can keep using the Web service interface as they had before! This demonstrates how interfaces can provide a layer of abstraction that makes ports and other changes less painful.
How Web Services are Being Used Today
The vast majority of companies using Web services today are using Web services to provide solutions to scenarios similar to the ones we examined. Typically, Web services are built for use inside an enterprise, behind the firewall, as a means for interoperability among disparate systems. Web services are also commonly used to exchange information between business partners. For example, an airline company like American wants to make its flight data available to travel agents. Furthermore, American might have a business relationship with Hertz Rental Cars where customers that fly American and rent Hertz get some sort of bonus or savings. In such a scenario, Hertz and American would likely need to share data amongst themselves, and Web services would be an ideal conduit.
Web services can also be built for public consumption, although this isn't done very often today. The main reasons against creating publicly-accessible Web services is that for many business sectors doing so doesn't provide any return to the bottom line. Furthermore, letting anyone hit your Web service adds to the demands placed upon the service which, if not properly managed, can lower the overall quality of service. (A notable exception are Amazon.com's Web services, which can be accessed by developers worldwide.)
In this article we discussed how Web services can be used in the real-world. Typically, Web services are utilized to solve data transfer problems and to create platform-neutral interfaces for distributed systems. Web services for data transfer is typically used for data transfer among business partners, but such data transfer could be opened up to the general public. Also, depending on a company's internal computer infrastructure, data transfer might be difficult even within an enterprise, and therefore might mitigate the use of Web services internally.
In addition to data transfer, Web services are ideal for creating interfaces for complex, distributed systems. These interfaces provide a platform-independent means to access a system. These wrapper interfaces are typically needed for legacy systems that use antiquated protocols for communication and information exchange. With a Web service interface, only the Web service needs to be intimate with the legacy system's outdated protocol - clients wishing to use the system can simply talk to the Web service interface.