News Stay informed about the latest enterprise technology news and product updates.

Web Services (Part 2)

Steve Vinoski continues his article, saying because Web services represent the evolution and convergence of EDI, traditional middleware, and the Web itself, some tend to exaggerate their capabilities. Some describe them as finally providing true component-oriented software, and thus finally bringing about the death of monolithic applications and systems.


Web Services
By Steve Vinoski, Chief Architect, IONA Technologies

Continued from Page One

What About the Hype?

Because Web services represent the evolution and convergence of EDI, traditional middleware, and the Web itself, some tend to exaggerate their capabilities. Some describe them as finally providing true component-oriented software, and thus finally bringing about the death of monolithic applications and systems. Others portend the end of traditional middleware, which they claim was always too big or too complicated anyway. Some even predict that Web services eliminate the need for operating systems.

The desire to finally find "The Silver Bullet," be it Web services or something else, drives many to count on things that simply cannot happen. For Web services, these hopes tend to ask us to suspend disbelief, to accept that traditional distributed systems issues - bandwidth, latency, performance, scalability, coupling, granularity, and so on - no longer matter. For example, the XMethods Web site (http://www.xmethods.net/) lists a number of Web services available for your immediate use:

  • There are several Web services that act as converters from one unit to another. There are converters for currency exchange, temperature, distance, volume, pressure, and weight. These all operate as simple RPC services. You invoke the method, passing in the data value you want converted, and the method returns the converted value.
  • There are several stock quote services. You invoke the method, passing in the desired stock symbol as a string, and the method returns the current value of the stock.
  • There are a couple of calculator services. These allow you to pass in expressions, and the service will evaluate them and return the result.
  • There is a Web service that, when invoked, returns a Globally Unique Identifier (GUID).
  • Other services allow you to track Federal Express packages, check the weather, check the bid price of an eBay auction, or check California traffic conditions.

Technology soothsayers say that future software will be composed of Web services like those described above. Is this really possible?

Imagine you're writing a stock trading application that allows a user to request that a certain stock be bought or sold at a particular price. You can implement such a system by making use of one of the stock quote Web services on XMethods. All you have to do is write a Web services client application that invokes the stock quote service with the symbol name of the stock that the user wants to trade, wait until the return value matches the user's desired trade price, and then perform the trade. Right?

Well, yes, you could implement a stock trading application as described, but even if you managed to actually deploy such an application and got people to use it, you'd quickly find that it didn't work very well.

The problem is that by implementing the stock trading application in this manner, you've ignored some of the most fundamental issues in distributed systems development. In particular, you've ignored the fact that the polling approach is usually one of the worst ways imaginable to build a distributed system.

Think about it: your application has to continually invoke the stock quote Web service to check the price of the stock to be traded. Imagine that your user has decided to set up trades for, say, four different stocks. Now imagine that there are 9999 other users out there, each of them also wanting to trade four different stocks. Each user's copy of your trading application is going to be polling the stock quote Web service continually to check the price of each stock to be traded.

Multiply the number of users (10,000) by the number of stocks each wants to trade (4), and then multiply that by the number of polling operations required to determine the target trade price. Assuming each Web service invocation across the Internet takes an average of 0.5 second, meaning that each copy of your trading application performs two polling operations per second, you wind up with 80,000 Web service invocations per second. This translates to 288,000,000 Web service invocations per hour, assuming none of the target stocks hits its target price within that hour. Wow! And what if you had 100,000 or 500,000 users instead, each trading eight stocks?

Looking at all the Web services advertised on XMethods, it appears that most of them ignore some fundamental rules of distributed computing, just like the stock quote service described above. Why are these rules so flagrantly ignored?

  • Reinventing the wheel. Anyone who has been around the software industry long enough knows that many would rather develop everything from scratch than build upon the work of others. As the old saying goes, those who ignore history are doomed to repeat it, and this is true in software as well. Those who have ignored the lessons learned from years of building and deploying CORBA middleware, for example, thinking it was too complicated or too bloated, are now jumping on the Web services bandwagon and are unwittingly having to (re)discover those lessons for themselves.
  • Plain ol' ignorance. Many who have recently taken to Web services do not have distributed systems backgrounds. Some are joining as pure Java application developers. Others are coming from a world of J2EE servlets and Java Server Pages (JSPs) and dynamic Web pages. Still others are XML aficionados. Even though these people may not have set out to reinvent the wheel, like those described above, they'll still have to learn the hard lessons of distributed computing for themselves.
  • "But these are only examples!" Web services zealots no doubt would respond to my criticisms by suggesting that the Web services advertised on XMethods are intended for demonstration purposes only. They would counter that "real" Web services would be more substantial, or perhaps more specific to vertical industries. And there is probably an element of truth in this explanation, given that the demonstration programs that typically ship as part of middleware products are also often quite simple.

The polling approach advocated by a number of the XMethods Web services is known to lack performance and scalability. For example, Michi Henning (see http://www.ooc.com.au/staff/michi-henning.html) and I have described these issues in the context of CORBA systems in "Advanced CORBA Programming with C++," and Doug Schmidt (see http://www.ece.uci.edu/~schmidt/) and I have also described them in detail in our "Object Interconnections" magazine columns. (For more information on both the book and for links to the columns, see my home page at http://www.iona.com/hyplan/vinoski/.) Using a callback approach instead for a stock quote service allows for far better performance and scalability. In the next issue of this column, I'll discuss these real-world issues.

Summary

Do I believe that the significant technical shortcomings of the first commercially available Web services, such as those advertised on XMethods, means that Web services are another useless overhyped hoax technology? Not in the least. Web services represent the convergence and evolution of the triumvirate of EDI, middleware, and the Web itself. They therefore hold a great deal of promise for turning the Web from a two-tier browser oriented system into a multi-tier system supporting application-to-application interaction and business-to-business integration. And the combination of business process standards learned from the world of EDI, together with the distributed computing and integration lessons learned from years of middleware development and deployment, all hosted over the ubiquitous infrastructure of the World Wide Web, is in fact quite compelling.

Steve Vinoski
Steve is Chief Architect and VP Platform Technologies for IONA Technologies in Waltham, Mass. Steve is also an IONA Fellow. He is the coauthor of "Advanced CORBA Programming with C++", published in January 1999 by Addison Wesley Longman, and he has written the "Object Interconnections" column for the C/C++ Users Journal (and formerly for SIGS C++ Report) for the past six years with Dr. Douglas C. Schmidt. Steve's current technical interests lie in the areas of business-to-business integration (B2Bi) and Web Services.

Go to Page One


Copyright 2001, IONA Technologies. Reprinted by permission.

FOR MORE INFORMATION:

.8tVvawOFlrW^1@.ee85eda>Talk back or comment on this article

The Best Web Links for Web Services

The Best Web Links for SOAP

Free Tutorials for Web services, SOAP, UDDI and more

Dig Deeper on Topics Archive

Start the conversation

Send me notifications when other members comment.

Please create a username to comment.

-ADS BY GOOGLE

SearchSoftwareQuality

SearchAWS

SearchCloudComputing

TheServerSide.com

Close