Every promising technology is heralded as a silver bullet. This is particularly true of new development technologies, most recently Microsoft's .Net and Sun Microsystems' Sun ONE.
Years ago, Java was supposed to reduce your programmer head count while improving your company's bottom line. When that didn't happen, people blamed Sun's refusal to turn Java into a truly open standard or blamed Microsoft for undermining Java with a nonstandard implementation. But maybe we expect too much from new ideas.
Even worse hype circulated around XML. I talked to CEOs who were sure XML would make programmers obsolete. Anyone who's used XSLT, XPATH, UDDI or WSDL knows that the exact opposite is true. Unique positions have been created around XML technologies that let disparate systems communicate.
Now we're in the throes of Web services fanaticism. Pundits claim, "Web services will do everything in record time and with existing staff! They will make you cooler than the competition! You won't survive without .Net or Sun ONE or IBM Web services!"
A word to the wise: Web services aren't new. COM+, CORBA, Enterprise JavaBeans -- that's all they are. They come with a pretty XML interface, but you still must develop and maintain the underlying software. Someone on your development staff will have to become an expert in all the acronyms mentioned above. "But I can develop Web services in VB!" you proclaim proudly. Yes, you can do that with .Net. But you could do that with DCOM, too. A change in the interface doesn't change how you develop an object, only how that object interfaces with surrounding systems.
Before you put too much stock in Web services, assess the maturity of the underlying technologies. Early signs of vendor interoperability problems, similar to the problems that have held CORBA back, are emerging. Moreover, companies like IBM and Microsoft are just starting to make serious security recommendations for Web service technologies like SOAP. The definition language for specifying such Web service interfaces is currently plain-text XML. Do you really want to publish the interface to your system over the Internet in a manner so standard a 12-year-old with a canned set of scripts can tell what you're running?
Am I suggesting you swear off Web services? Absolutely not. They will fit into your existing architecture, most likely helping you with integration and interoperability. But until a solid base of technologists and a reliable security framework materialize, they should play a limited role within your Internet applications.
The best place to start using Web services is with intranet applications. By implementing applications internally, you won't have to worry so much about security, and you can start growing your talent today.
There are plenty of options, many of them free. If you're an MSDN subscriber, you already have .Net capability. The Apache SOAP project also is free. Several Web sites offer C++, Java, PERL, C# and VB libraries for Web services. Find links to many of these at SOAPClient.com.
--Don MacVittie, dmacvittie@nwc.com.