Web Services: OR's Newest Ally?

By V. S. Rama Ramakrishnan

Data sourcing and integration issues have derailed scores of OR/MS projects and muted OR's impact on the enterprise. An enterprise OR project may be brilliantly conceived, use cutting-edge models and offer compelling business benefits, yet, as experienced practitioners know, if the necessary data cannot be sourced easily or if integration with business process systems appears long and messy, the project's return on investment will be uninspiring and it may end up in the scrap heap.

All this may be about to change. Web Services, a set of emerging XML-based technologies, may enable OR to finally live up to its potential.

Web Services are software applications that can be invoked over the Internet or corporate intranets using open XML-based standards. While it has been possible for years to build business applications that communicate over networks, it is expensive and time-consuming. Web Services' reliance on open standards promises to accomplish the same goals at a fraction of the cost and a fraction of the time.

Media coverage of Web Services has mainly focused on consumer applications or on B2B applications involving inter-enterprise collaboration. While these applications are compelling, they are a few years away. In contrast, using Web Services to facilitate interactions between applications within the enterprise, i.e. for Enterprise Application Integration (EAI), has already begun. The potential of Web Services technology to substantially reduce the time and cost for building, integrating and maintaining business applications within the enterprise is of great relevance to OR professionals.

Figure 1

The Three Protocols

Web Services technology is based on three XML-based standards: SOAP, WSDL and UDDI. XML's central role in Web Services stems from its dual nature: it can be used to describe data as well as to describe message-passing protocols. Further, since XML is a text standard, it can be understood by applications regardless of platform or programming language. These attributes make XML a superb choice for application-to-application communication. Let's now examine the three XML-based protocols that underlie Web Services technology.

Simple Object Access Protocol (SOAP) is at the heart of Web Services and is the glue connecting software written in different languages and running on different platforms. SOAP specifies how to create a special kind of XML document called a SOAP message. SOAP messages are the basic unit of communication in the Web Services world and can be sent over the ubiquitous HTTP protocol (like HTML documents are today).

By sending the right SOAP message to a remote application that understands SOAP, you can do two important things: send data to the application and command it to process the data in a certain way. No knowledge of that application's platform or programming language is necessary! This is what makes Web Services compelling. Further, since a Web Service is simply an application that "talks" SOAP, converting an existing application into a Web Service is straightforward: 1. Write a SOAP wrapper that translates incoming SOAP requests for your application and formats your application's responses into SOAP responses. 2. Locate the application at an URL.

Once a Web Service is created, its existence needs to be communicated to potential users. This need is met by the Universal Description, Discovery, and Integration (UDDI) standard. UDDI specifies a catalog mechanism for providers of Web Services to advertise the existence of their Web Services, and a search mechanism for Web Service consumers to find relevant Web Services. This catalog is called the UDDI Registry and is itself implemented as a Web Service. A special SOAP message called an UDDI Inquiry message can be sent to the UDDI Registry. The response (also a SOAP message) will describe all the available Web Services that match the search criteria along with the URLs where the Services may be found.

To communicate with an available Web Service, the details of its acceptable inputs and outputs, i.e. its program interface, is needed. Web Services Description Language (WSDL — pronounced "WHIZ-dull") specifies a standard way for providers of a Web Service to describe the requests it can handle and the responses it generates. The UDDI Registry response to an Inquiry message includes the location of the WSDL file describing the Web Service. The WSDL file is an XML document in SOAP format. Using this file, developers can quickly create appropriate SOAP requests to send to the Web Service as well as develop code for their application to process the SOAP responses sent back by the Web Service (see Fig. 1 for a typical Web Services process flow).

In summary, SOAP specifies how to send data to, and invoke procedures on, remote applications; UDDI specifies how to create (and use) a special kind of Web Service that acts as a directory of available Web Services; and WSDL specifies a way to detail the requests and responses that a particular Web Service supports. Taken together, the three standards specify a complete solution for creating, discovering and consuming Web Services.

Increasing OR's ROI

The widespread deployment of Web Services is likely to increase the return on investment (ROI) of enterprise OR/MS projects and elevate the rate at which they get proposed, funded and executed.

Consider the key cost elements in a typical OR project: the man-hours related to the OR work (e.g., modeling), the man-hours related to building connectors to enterprise data sources, and the man-hours needed to develop and integrate the production code with the calling application. The latter two costs typically form the bulk of the project's cost structure. Fortunately, Web Services are likely to decrease these costs significantly.

Building data connections will become as easy as searching for relevant Web Services in the enterprise's UDDI Registry, obtaining their WSDL files and network locations, generating SOAP messages to request the relevant data and writing XML parsing code to process the data. Assuming that relevant Web Services are available, this entire process will take days instead of weeks or months.

OR models that would traditionally be deeply embedded in a business application (and therefore requiring significant integration and testing) can now be made available as an "at arm's length" Web Service that gets called upon by the business application as needed. This "loose coupling" will require significantly less upfront development and integration; it will also consume fewer ongoing maintenance resources since changes to the OR component (e.g., the use of an improved heuristic to find an initial feasible solution) can be deployed without touching the calling business application. Project costs will further decrease through code reuse: if OR components are running as distinct, visible Web Services, they are likely to be used as building blocks for later projects rather than writing code from scratch as is typically done today.

These cost reductions will increase ROI and lead to a higher rate at which OR projects get funded. It will also lead to a higher rate at which OR projects get proposed since project ideas that were previously considered to be too capital-intensive will become attractive. This will be particularly true for high-impact projects spanning functional or departmental boundaries.

In the longer term, as OR deliverables increasingly become distinct, "stand-alone" Web Services, a service-oriented OR value proposition may emerge. OR-delivered Web Services may be offered to outside firms, creating opportunities for OR groups to generate revenue and become profit centers.

Fast Forward: An OR Project in a Web Services World

Your team has developed a product-mix optimization model for the Marketing Department. Test results suggest a 10 percent increase in profitability! There is great urgency to "go to market" with the model and the CEO wants you to get it done ASAP. It is Monday, 10.30 a.m.

The model needs data on production and distribution costs, demand forecasts and prices associated with multiple products. SOAP inquiry messages sent to your firm's UDDI Registry reveal the existence of a Web Service run by Marketing that provides demand and price data and a Web Service run by Accounting that provides production and distribution data. The UDDI response has the intranet URLs where the two Web Services may be found and the locations of their WSDL files. Your developers use the WSDL files and SOAP generation software (a standard feature in Web Services development environments) to quickly create and test the appropriate SOAP requests and the code to process the response. Your data connectors are done! It took just two days.

Your model uses a proprietary algorithm developed by a French software firm. Usually it would take weeks to integrate their software with your code, test and deploy. Fortunately, their algorithm is available as a Web Service; using SOAP generation software and the algorithm's WSDL file, your developers write and test the SOAP request and the XML parsing code to process the SOAP response in a matter of hours. It is done by Thursday around noon.

It is time to deploy. No more multi-month periods for integrating the model with the business application and installing the new version on users' machines. SOAP generation software "inspects" the objects in your code and automatically generates a SOAP wrapper and WSDL file. You register your Web Service with the UDDI Registry and locate it at an intranet URL. Using the WSDL file and SOAP generation software, developers of the calling business application are able to rapidly create code to communicate with your Web Service.

When Marketing end-users arrive at work at 8 a.m. on Monday, the system is ready to go. What would have usually taken several months was accomplished in a week. The CEO and SVP of Marketing congratulate you and your team for a job well done.

Be Prepared

While much work remains before Web Services becomes a stable, broadly supported technology platform capable of making the above scenario possible, enterprise OR/MS professionals should not wait to get started. Read the literature. Download evaluation software. Attend a Web Services conference. Createprototypes. Experiment.

- Volunteer your group for Web Services trial deployments in your organization. This will accelerate your learning as well as position your group as a progressive one.
- Try to join and contribute to Web Services taskforces or similar groups in your firm. Be in the information flow of your firm's Web Services technology evaluation and vendor selection processes.
- Identify one or two highly successful models developed earlier by your group and see if it might be beneficial to expose them as Web Services. As you go down the learning curve, remember: no new technology is a sure bet. Monitor the commitment of key players like Oracle, HP, Sun, IBM and Microsoft to the core standards. Track progress on open issues relating to security and authentication. Splintering of vendor support on any of these fronts may be enough to stop Web Services in its tracks.

Further Information

- "A Web Services Primer"
- "A Platform for Web Services"
- "Web Services — the Web's Next Revolution"
- "SOAP: The Simple Object Access Protocol"
Web sites
- www.webservices.org
- www.webservicesarchitect.com
- http://msdn.microsoft.com/library/
- www-106.ibm.com/developerworks/webservices/
- www.primordial.com
- www.capeclear.com

Dr. V. S. Rama Ramakrishnan (rama@alum.mit.edu) is an independent management consultant specializing in the application of OR/MS techniques. He has more than a decade of experience in management consulting, quantitative modeling and software product management. He has been an engagement manager at McKinsey and Company, a senior OR analyst at Sabre Decision Technologies, and co-founder of an analytical software startup. He has a master's degree and a Ph.D. in OR from MIT.