Web services reality check
Microsoft and IBM in particular have been astonishingly effective in communicating the advantages of Web services--reusable components, easy integration among enterprises, and so on. The press has taken these high-level concepts to heart, even though actual Web services implementation is only in the pilot phase. Developers, contrarians that they are, have a different take. And with Web services they've got plenty of opportunity to poke holes.
Here are some common objections developers raise about Web services. Some have good answers and some don't:
Security and authentication. Of all the objections to Web services, these two get raised earliest and most often. Fortunately, when you're dealing with sensitive data, SSL, that old Web standby, works fine to prevent interception of XML messages. But authenticating XML documents on the server is another matter. A half-dozen authentication schemes--being bandied about various standards committees--try to address the problem through digital signatures and such, but it's going to take awhile before standards solidify.
Transaction completion. When multiple parties are involved--as in a supply chain, for example--transactions may be long-running and complex. A way needs to be found to monitor complex transactions so that all parts of the process are identified. Several standards, including Secure Assertion Markup Language, Business Transaction Protocol, and IBM's Reliable HTTP, have been introduced to address the problem, but the standards committees have not approved any of them.
Performance. There's no good answer to this one. XML over HTTP is simply not a high-performance solution. And with security protocols on top of that, users who need an immediate response to a particular action will be frustrated. Aside from operations where the user expects delays--credit-card checks, let's say--the latency problem may keep Web services consigned to intra-enterprise projects and automated B2B transactions for some time.
Increased dependencies. When multiple applications rely on one Web service, any change to that Web service can cause several applications to fail. Similarly, the popularity of individual Web services will need to be monitored closely to ensure the hardware is scaled accordingly. And as with any component architecture, Web services components will need to be developed for the common denominator, as programmers try to anticipate functionality that can be used across many applications.
Availability and reliability. Web connections may be more reliable than they once were, but when you call on components outside the firewall, you have to live with a lower percentage of uptime. You also have to trust components that are essentially black boxes accessed through XML APIs. Old-fashioned trust relationships will have to be built between companies before it's worth the risk of using someone else's Web services.
Extra development effort. Everyone likes to build applications the right way: fully documented and with maximum reusability of code in mind. But in the real world, projects need to get done on time and within a certain budget. Creating applications built from Web services components the first time out will require extra effort and time. Rightly or wrongly, many IT managers won't want to delay projects just to reap the benefits of reusability down the road. By the same token, the probability of an IT manager "componentizing" applications that work just fine seems pretty low, even if breaking them down into Web services components would benefit other apps.
None of these objections are showstoppers. In fact, all the developers I've talked to agree with the general direction of Web services and many are working on pilot programs.
With more realistic expectations about the time and effort that will be needed to derive the benefit of Web services--as well as a clear understanding of Web services' limitations at this time--perhaps this promising technology won't suffer from the overheated expectations that befell so many other technologies.
Do you think Web services promise more than they'll deliver--or vice versa? E-mail Eric or Talk Back below.