Why Web Services Work
Why Web Services Work
By: Michael Blank
Jan. 1, 2000 12:00 AM
Having been endorsed by virtually every technology vendor on the planet, Web services are now evolving from "feature" to "fabric." They are moving from the latest buzzword (hot new feature) to a mature and accepted technology (fabric of the technology landscape). The hype is fading; it is no longer interesting to develop Web services simply as a proof of technology, or as an end in themselves.
This series explores the use of Web services in real-world situations, with the purpose of identifying usage patterns. The idea behind the series is to help answer questions like: Where and how do Web services deliver value? Where might they be counter-indicated? What works? What doesn't?
For the first time, there is enough data from real-world, business-driven projects to allow us to begin to recognize patterns. The data analyzed here is drawn from production Web services case studies culled from two sources:
Where possible, case studies are attributed to specific companies. However, in many cases organizations requested anonymity, generally because their projects are not public and are considered competitive differentiators.
Reasons for Choosing Web Services
Four major reasons for using Web services emerged from the analysis. A few initiatives were too broad or too unique to categorize, but the vast majority - over 70 of the 80 case studies reviewed - coalesced around the following major themes:
Reason #1: Simplicity
For example, a logistics and transportation company needed to make it easier for developers at partner companies to remotely call the company's shipping functionality from within their applications. In the past, the company distributed software development kits (SDKs) for several platforms, but it was a nightmare to maintain and never gained any traction. Web services were a perfect solution that allowed developers to use whatever development tool they already had. The company believes that its transition to Web services will make its shipping functionality ubiquitous, and will serve as a customer acquisition tool.
Andy Ellicot, technology director for Infinity Pharmaceuticals, notes that he didn't have to hire expensive programmers to implement his Web service projects. "Our team of technical analysts was able to deliver the project without having to get the engineering team involved. This helped us save time and money," adds Ellicott. The technical analysts, who knew the end-user application but weren't programmers, used a Web services-based integration platform to orchestrate individual Web services developed by engineering into business process-spe- cific Web services that were exposed to the portal team. The graphical environment made this easy, and they didn't require expertise with Java, .NET, or WSDL.
Reason #2: Interoperability
Because of Web service interoperability, companies can implement a loosely coupled, global IT infrastructure. Consider the CIO of a large rental car company in Europe, faced with the difficult task of integrating every reservation system in Europe so that a customer can pick up a car in France and drop it off in Germany. This company has grown by acquisition, and each country has their own custom reservation system. Without Web services, his alternative was to standardize on a technology, and then force each country to implement it. A risky venture, even if he wins the political battle. With Web services, though, he just needs to define and gain consensus on the interface. The interface, then, can be implemented by each of the countries with whatever technology they prefer.
Web service interoperability was a key factor for companies that needed to connect their portals to their back office. In fact, over half of the companies surveyed used Web services with a portal or application server. In this scenario, an integration platform is typically used as the central Web services provider that feeds the portal with various back-end data sources. For example, at NEC Electronics America, Web services connect their application server to their back-end databases' integration platform. The project would have taken another 4-6 weeks with an alternative, proprietary approach, such as RMI, and may not have been easily reusable by other business units.
Perhaps the most significant aspect of Web service interoperability is the ability to bridge J2EE and .NET environments. For Infinity Pharmaceuticals, this was the primary driver for using Web services. Andy Ellicot says, "because many applications speak SOAP they can be easily plugged into the architecture. I'm not locked into any one proprietary solution." Various commercial off-the-shelf (COTS) products plug into the integration framework via Web services. This has allowed Infinity to quickly adapt their IT infrastructure to take advantage of market opportunities. A leading mortgage lender and financial services company relied on Web service interoperability to efficiently connect their various portals to their integration platform. Because of acquisitions, the company had to maintain both J2EE and .NET environments. Web services were the only way to feasibly connect these portals to their back office.
Reason #3: Abstraction
Nearly all of the companies interviewed are using Web services in projects that require integration with another organization, i.e., another internal team or an external trading partner. The issue with integrating with another organization is that you rarely (a) control them and their technology decisions or (b) have expertise about their systems. With Web services you agree on the interface, not necessarily on the technology, and you don't require domain expertise about the other's back-end systems. Therein lies the power of Web services abstraction.
Future Electronics, a multibillion-dollar electronics components distributor, decided to use WSBI to help ease integration between their e-commerce portal and the company's mainframe system that processed all orders. Without Web services, the only way to accomplish the integration with the mainframe was for the e-commerce team to access the mainframe database tables directly. Understandably, the mainframe team was highly uncomfortable with this. Furthermore, the e-commerce team would have had to acquire mainframe expertise. Instead, they agreed on the (WSDL) interface, and implemented that interface using technology that was already familiar: the e-commerce team used the webMethods Integration Platform and the mainframe team deployed a mainframe SOAP add-on product. Brad Hudon, director of IT Development for Future Electronics, says "Web services allowed us to implement a 'black-box' integration framework that lets each of the teams retain their existing business logic." He adds that the project would not have succeeded without the use of Web services.
A large financial services company consolidated 50 back-end systems into a simple set of Web services that are consumed by 20 front-office and customer-support applications. One Web service operation, called Update Customer Information, for example, sets off a complex business process that sends the data to 10 different customer systems. However, all of this complexity is abstracted to the consumer of that service, greatly speeding the integration.
Avnet Computer Marketing, a leading provider of enterprise systems, software, networking, and storage, was able to reduce the cost of maintaining and extending their integration architecture by consolidating their FTP, XML, and IP socket interfaces and standardizing on Web services. Now the e-commerce portal team can focus on the presentation layer and no longer needs to know about these various proprietary interfaces and file formats - they just call a Web service.
Enables Application "Plug-and-Play"
Reason #4: Component Reuse
For example, a large financial services company implemented Web services because they planned to connect multiple front-office applications that needed to access the same type of data. A service hub exposed their back-end systems as a simple set of Web services. While Web services didn't save time on the first connection, they did have significant impact for subsequent connections. Implementing the first Web services-based business process and integrating it with the customer portal took seven weeks, but the second connection to the automated voice response system took only several days (much to the surprise of the project manager, who had initially budgeted two months!).
Avnet Computer Marketing already had several Web services projects under their belt, and today integration projects are measured in days instead of weeks. Integrating the quote-to-order application with the mainframe took about six weeks, but connecting the order entry e-commerce system to the same Web service took only one day.
Reader Feedback: Page 1 of 1
SOA World Latest Stories
Subscribe to the World's Most Powerful Newsletters
Subscribe to Our Rss Feeds & Get Your SYS-CON News Live!
SYS-CON Featured Whitepapers
Most Read This Week