The following is excerpted from "Web Services: A Manager's Guide," by Anne Thomas Manes with permission from publisher Pearson Education, copyright 2004, publishing as Addison-Wesley.
There are many compelling reasons to use Web services.
It seems as if everyone is at least playing with Web services. Almost every software vendor is building support for Web services into its platforms, languages, and tools. Web services enable any-to-any integration, supporting any programming language, any runtime platform, and any network transport. Technologies such as SOAP and WSDL are simpler to use than traditional integration middleware technologies, and they offer much more flexibility. When combined with domain-specific industry standards, Web services enable unprecedented dynamic interaction. More to the point, they can make it easier for your partners and your customers to do business with you. Best of all, the low cost, pervasiveness, and simplicity of the technology lets your existing staff do more with less.
Web services can be used for many types of applications. Nearly every application requires some integration effort, so I'm sure you can find a way to use Web services in almost any project. After you get a little experience under your belt, you'll very likely adopt Web services as a standard integration technology. When you're just getting started, though, it's always best to limit your scope. Start small. Spend some time learning about the technology. Then you can apply your learning to larger projects. One nice feature of Web services is that you can use them incrementally. There's no need to tackle an enormous project all at once. I recommend that you use Web services in places where they are likely to have a big impact.
Bell Ringers
Which applications would benefit most from Web services? Where should you start? What are the key criteria that should ring a bell your head and make you think, "This is a job for Web services"?
Heterogeneous Integration
The first and most obvious bell ringer is the need to connect applications from incompatible environments, such as Windows and UNIX, or .NET and J2EE. Web services support heterogeneous integration. They support any programming language on any platform. One thing that's particularly useful about Web services is that you can use any Web services client environment to talk to any Web services server environment.
For example, JPMorgan uses Web services to connect Excel spreadsheets to UNIX-based financial data. JPMorgan operates the global wholesale businesses for J.P. Morgan Chase. JPMorgan is a leader in investment banking, asset management, private equity, custody and transaction services, middle market financial services, and e-finance. The firm has financial analysts in more than 50 countries around the world. These analysts needed a way to upload and download financial, forecast, and other relevant data used in their spreadsheets to and from various legacy application systems.
Knowing that it's difficult to find a single-vendor solution that would allow it to connect Excel with various UNIX-based systems, JPMorgan decided to use Web services. Web services permit the firm to use the right tool for each side of the equation. JPMorgan created a set of Web services using Systinet's Web Applications and Services Platform (WASP) to enable easy access to the legacy applications. Now the financial analysts can access these services from Excel using Visual Basic for Applications (VBA) macros and the Microsoft SOAP Toolkit.
Unknown Client Environment
The next bell ringer is any situation in which you have little or no knowledge of or control over the client applications that will be used to access the service. Because Web services don't require a specific software environment, you don't need to worry about compatibility issues.
For example, Con-Way Transportation Services uses Web services to support electronic exchange of shipping data with its customers and business partners. Con-Way is a $2 billion transportation company based in Ann Arbor, Michigan. More than two-thirds of its customers are small to medium-sized businesses. Con-Way wanted to provide these customers with a mechanism that would support tight integration with Con-Way's transportation systems. The challenge was that these customers use a variety of transportation applications on a variety of deployment platforms. Con-Way realized that it didn't have the option of asking these customers to install a proprietary API with limited deployment options to support integrated Con-Way business transactions. Instead Con-Way developed a set of Web APIs using IBM WebSphere. These APIs support invoicing, bill of lading, order pickup, and sales management services. Customers can interface with these services through the Con-Way Web site or use the Web APIs to connect directly from their corporate application systems. The Web APIs support any type of client application-in-house applications as well as packaged applications.
Multichannel Client Formats
A third bell ringer is the need to support many types of client formats, such as browser clients, rich desktop clients, spreadsheets, wireless devices, interactive voice response (IVR) systems, and other business applications. A Web service returns its results in XML, and XML can be transformed into any number of formats to support different client formats.
For example, Wachovia uses Web services to support both browserbased clients and rich desktop clients for Einstein, its customer information system. Wachovia is a leading provider of financial services, with nine million U.S. customer households. Einstein is a GUI application that gives bank staff complete information about a customer, aggregating information from multiple backend systems. Some bank staff use a browser to access Einstein. Others require a richer desktop interface.
As shown in Figure 7-3, Einstein was developed as a multitier Web service application. The backend business functions and data sources are legacy applications implemented in CICS and DB2 on the mainframe. The middle tier, which accesses and aggregates the customer information, is implemented as a set of J2EE Web services using IBM WebSphere. The client environments are implemented using Microsoft .NET. The browser client is implemented using Microsoft .NET WebForms, and the desktop client is implemented using Microsoft .NET WinForms. Einstein's architecture also allows Wachovia to implement other types of client interfaces to support IVR systems, wireless handsets, twoway pagers, and other devices.
 |
| Figure 7-3: Einstein supports browser and rich desktop clients, allowing Wachovia to support other devices if needed. Written using .NET, Einstein aggregates information from numerous CICS-based backend systems via Web services implemented using WebSphere. |
Other Web Services Applications
Web services can help you accomplish many types of business goals. You can use Web services to solve immediate tactical problems. You can use them to help you manage your software assets, leverage legacy applications, and reduce development costs. Web services can also help you optimize your business process and improve customer relationships.
Point-to-Point Integration
The first and most basic way to use Web services is for simple point-to-point integration. For example, Cape Clear uses Web services to connect employees' e-mail clients with its CRM solution. Cape Clear is a Web services software startup. It uses Salesforce.com as its CRM solution. Salesforce.com provides a hosted CRM solution using an ASP-style model. Users typically interface with the CRM solution through a browser, recording customer contact information and correspondence.
Like most software startups, Cape Clear provides e-mail-based customer support. As a result, quite a bit of customer correspondence takes place via e-mail. But Salesforce.com didn't provide a simple, easy way for Cape Clear employees to log this correspondence in the Salesforce.com database. Users had to copy and paste the e-mail from Outlook into the Salesforce.com browser interface. Cape Clear found that lots of correspondence wasn't getting recorded.
Salesforce.com provides a programming API, so Cape Clear decided to eat its own dog food and address this problem using Web services. First Cape Clear used Cape Clear Studio to develop a Web service adapter for the Salesforce.com native programming API. This adapter accepts a SOAP request and translates it into the Salesforce.com native API. Next Cape Clear developed an Outlook macro using Microsoft SOAP Toolkit that takes an Outlook e-mail and uses SOAP to pass it to the Salesforce Adapter Web service. The Adapter service then passes the message to Salesforce.com using the Salesforce API.
This Outlook macro adds a button to the standard Outlook tool bar labeled "Save to Salesforce." As shown in Figure 7-4, when the user clicks on this button, the Outlook macro captures the e-mail message, packages it as a SOAP message, and sends it to the Salesforce.com adapter Web service. The Web service then forwards the e-mail using the native API to Salesforce.com, which logs it.
 |
| Figure 7-4: Cape Clear developed a VBA macro using Microsoft SOAP Toolkit that takes an Outlook e-mail and uses SOAP to pass it to the Salesforce Adapter Web service. The adapter service then passes the message to Salesforce.com using the Salesforce API. |
After seeing the advantages of using SOAP for integration, Salesforce.com has decided to develop its own set of Web APIs in addition to the native programming APIs. If you are a Salesforce.com customer, you won't need to build your own adapter Web services.
Consolidated View
One of the most popular internal integration projects is enabling a consolidated view of information to make your staff more effective. For example, you probably have many people in your organization who interact with customers. Each time your staffs interact with the customer, you want to let them have access to all aspects of the customer relationship. Unfortunately, the customer relationship information is probably maintained in variety of systems. The good news is that a consolidated customer view provides a single point of access to all these systems.
You can use Web services to implement this type of consolidated view. For example, Coloplast is using Web services to improve its sales and customer support functions. Coloplast is a worldwide provider of specialized healthcare products and services. As part of an initiative to improve customer relationships, Coloplast wanted to set up a state-of-the-art call center system that would give customer representatives real-time access to complete customer histories and product information. The company selected Siebel Call Center as the base application, but it needed to connect this system to its backend AS/400-based ERP systems, which manage the sales, manufacturing, and distribution functions. It did so using Web services. Coloplast used Jacada Integrator to create Web services adapters for the legacy AS/400 application systems. Siebel Call Center uses these Web services to deliver a 360 degree view of customer relationships, including access to backend processes such as open order status, inventory information, customer credit checking, and special pricing. This solution improves efficiency and enhances employee and customer satisfaction.
Managing Legacy Assets
Web services can make it easier to manage and maintain your legacy application assets. For example, AT&T estimates that Web services technology has reduced the time it takes to make modifications to some of its oldest application systems by 78 percent.
TIRKS (Trunks Inventory Record Keeping System) is a critical application for AT&T. TIRKS was first developed in the 1960s, and it is connected to more than 100 other application systems. Because of the brittleness of these application connections, every time AT&T makes a modification to TIRKS, it must also make a corresponding modification to the other systems. Using Web services, AT&T has developed much more flexible application connections that don't break every time a change is made to the application. AT&T is using IONA XMLBus to replace the more than 100 brittle application connections with a much smaller set of flexible, reusable Web APIs to TIRKS. Now each modification to TIRKS no longer requires the associated changes in all the other application systems.
Reducing Duplicative Applications
One of the more popular ways to use Web services is to reduce redundant applications. A service can support many types of application clients. If you need to perform the same type of function via multiple applications, it makes a lot of sense to develop a single service shared by all these applications rather than duplicate the functionality in each application.