Welcome!

SOA & WOA Authors: Liz McMillan, Richard Moulds, Michelle Drolet, Elizabeth White, Patrick Carey

Related Topics: SOA & WOA

SOA & WOA: Article

Book Excerpt: When to Use Web Services

Book Excerpt: When to Use Web Services

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 in 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, as shown in Figure 7-1.

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–as shown in Figure 7-2.

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 browser-based 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, two-way pagers, and other devices.

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 VBA and the Microsoft SOAP Toolkit. 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.

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. As shown in Figure 7-5, 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.

Reduction of redundant applications is a key objective of the U.S. government's E-Gov initiative. The U.S. government encompasses hundreds of federal agencies and bureaus, and there is significant overlap and redundancy of systems across these agencies. A 2001 study by the E-Gov Task Force analyzed the agencies to identify the various business activities performed by the government. The study identified 30 general lines of business, such as economic development, public safety, environmental management, and tax collection. On average, each agency is involved in 17 lines of business, and each line of business is performed by 19 agencies. Some lines of business-such as payroll, travel, HR, procurement, logistics, administration, and finance-are performed by every agency.

The U.S. government spent $48 billion on information technology in 2002 and will spend $52 billion in 2003. The Office of Management and Budget estimates that the government can save more than $1 billion annually in IT expenditures by aligning redundant IT investments across federal agencies. In addition, this alignment will save taxpayers several billion dollars annually by reducing operational inefficiencies, redundant spending, and excessive paperwork.

In October 2001, the President's Management Council approved 24 high-payoff government-wide initiatives that integrate agency operations and IT investments. One of those initiatives is E-Travel, which is being run by the U.S. General Services Administration (GSA). E-Travel delivers an integrated, government-wide, Web-based travel management service. Federal government employees make approximately four million air and rail trips each year, and until recently each agency and bureau managed its own travel department. Cumulatively, these various departments used four travel charge card providers, six online self-service reservation systems, 25 authorization and voucher processing systems, 40 travel agencies, and a unique payment reimbursement system for almost every bureau.

By consolidating these travel systems into a single, centralized travel management system, the U.S. government expects to save $300 million annually, achieving a 649 percent return on investment. In addition, the consolidated system will deliver a 70 percent reduction in the time it takes to process vouchers and reimbursements.

GSA delivered the first phase of E-Travel in December 2002-an online self-service reservation system. The total end-to-end travel management system is scheduled to be complete by December 2003. The system will use a service-oriented architecture, based on XML and Web services, to ensure easy integration with existing agency systems and future adaptability. The E-Travel team refers to this architecture as "Velcro integration," indicating that modules can be easily replaced when necessary.

Managing Portal Initiatives
Web services can also be very useful as a means to manage and coordinate your portal initiatives. A portal is an integrated, Web-based view into a host of application systems. A portal contains a piece of application code (a portlet) for each backend application. A portlet contains the code that talks to the backend application as well as the code that displays the application in the portal.

Web services technology enhances portals in two ways. First, Web services deliver content to the portal as XML. It's then easy for a portal engine to take this XML content and display the information in a portal frame. It's also easy for the portal engine to reformat the XML content to support other client devices, such as wireless handsets or PDAs. Second, Web services technology defines a simple, consistent mechanism that portlets can use to access backend applications. This consistency allows you to create a framework to make it quicker and easier to add new content to your portal. Furthermore, as mentioned in Chapter 5, the new OASIS WSRP specification will allow you to add new content to the portal dynamically. Figure 7-6 shows an overview of WSRP.

Another goal of the U.S. government's E-Gov program is to get a handle on government portals. As of February 2003, the U.S. government was managing more than 22,000 Web sites with more then 35 million Web pages. These Web sites have been developed, organized, and managed using the same stovepipe mentality as used in the backend agency applications. Such decentralization and duplication make it difficult for citizens and communities to do business with the government. For example, a community that is attempting to obtain economic development grants must do a tremendous amount of research to learn about federal grants. There's no single source of information. More than 250 agencies administer grants, and you would have to file more than 1,000 forms (most with duplicate information) to apply for all of them. Some of these forms are available online; others aren't. Currently all forms must be filed by postal mail.

The government is working to consolidate this myriad of Web sites into a much more manageable number of portals, each providing a single point of entry to a particular line of business. Each portal will use Web services to access the backend applications that implement the business process. In many cases the government will consolidate backend applications to reduce redundant systems and to ensure a simpler experience for the portal users. For example, the forthcoming E-Grants portal will provide a single point of entry for anyone looking to obtain or administer federal grants. This site will help citizens learn about all available grants and allow them to apply for these grants online. The government expects to save $1 billion by simplifying grant administration as well as saving $20 million in postage.

All government portals will be coordinated through the FirstGov portal at www.firstgov.gov. From this one portal, citizens, businesses, and government agencies will have a single point of entry to all other government portals.

Web Services: A Manager's Guide
by Anne Thomas Manes
Publisher: Addison-Wesley Professional
ISBN: 0321185773
This book excerpt is from Chapter 7 of Web Services: A Manager's Guide by Anne Thomas Manes, copyright 2003. All rights reserved. This chapter is posted with permission from Addison-Wesley Professional.

More Stories By Anne Thomas Manes

Anne Thomas Manes is a Research Director at Burton Group, a research, consulting, and advisory firm. Anne leads research for the Application Platform Strategies service. Named one of NetworkWorld's "50 Most Powerful People in Networking," in 2002 and one of Enterprise Systems Journal's "Power 100 IT Leaders," in 2001, Anne is a renowned technologist in the Web services space. Anne participates in standards development at W3C and OASIS. She is a member of the editorial board of Web Services Journal. She is a frequent speaker at trade shows and author of numerous articles and the book, Web Services: A Manager's Guide, published by Addison Wesley.
Prior to joining Burton Group, Anne was chief technology officer at Systinet, a Web services infrastructure company, and before that she pioneered Sun's Web services strategy. A 24-year industry veteran, Anne developed her expertise working at a number of the world's leading hardware and software companies. You can reach Anne via e-mail at [email protected] or through her Web site at http://www.bowlight.net.

Comments (0)

Share your thoughts on this story.

Add your comment
You must be signed in to add a comment. Sign-in | Register

In accordance with our Comment Policy, we encourage comments that are on topic, relevant and to-the-point. We will remove comments that include profanity, personal attacks, racial slurs, threats of violence, or other inappropriate material that violates our Terms and Conditions, and will block users who make repeated violations. We ask all readers to expect diversity of opinion and to treat one another with dignity and respect.