We have a problem with our industry. Every new technology that comes along is heralded as a "silver bullet." This is particularly true of new development technologies such as Microsoft's .NET framework and Sun's recently announced ONE initiative.
Years ago Java was supposed to reduce your programmer headcount while improving your bottom line, washing your car, and making IRS regulations understandable. When that didn't happen, people either blamed Sun's refusal to turn Java into a truly open standard or pointed fingers at Microsoft for undermining Java with a non-standard implementation. These are both very real problems with the industry. But perhaps we are expecting too much from new ideas.
Then a couple of years after Java came into the spotlight, the same over-inflated hype circulated around XML. Only this time, it was worse. I talked to CEOs who were actually sure that XML would remove the need for programmers. Anyone who's looked at XSLT, XPATH, UDDI or WSDL knows that this is worse than a myth -- just the opposite is true. Unique positions have been created around XML technologies that allow disparate systems to communicate.
And now we're in the throes of Web Services Fanaticism. Industry pundits claim that Web services will do everything you ever need in record time and with existing staff! Web services will make you cooler than that competition! You won't survive unless you implement Web services! You must have .NET or Sun One or IBM Web services!
A word to the wise. Web services are not new. CORBA, Enterprise Java Beans, COM+ -- that's all they are. They come with a pretty XML interface, but you will still need to develop the underlying software. And more importantly, you'll need to maintain that software. Worse, someone on your development staff will have to become an expert in all of the acronyms I 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 it interfaces with surrounding systems.
Before you pay too much attention to the industry pundits and the companies that stand to make a bundle from Web services, you should probably take a very close look at the underlying technologies, assessing their maturity and their ability to deliver.
Early signs of interoperability problems between different vendors are emerging. And they are similar to the problems that have held CORBA back all these years.
Moreover, companies like IBM and Microsoft are just starting to make serious security recommendations for Web services technologies like SOAP. The definition language for specifying such Web services interfaces is currently plain-text XML. Think about that for a moment. Do you really want to publish the interface to your system over the Internet in a manner so standard that a 12 year old with a canned set of scripts can tell what you have running? I don't. And finally, the required experts in advanced XML will take a while to train -- there are very few of us out there today.
Am I suggesting that you to swear off of Web services? Absolutely not, they will fit into your existing architecture, most likely helping you with integration and interoperability issues. But they're not ready today, and they won't be until a solid base of technologists and a reliable security framework emerge. Until then, they should play a limited role within your Internet applications.
If you want to start using Web services now, your best place to start is with applications that will be deployed on your intranet. By implementing applications internally, you won't have to worry about the security concerns, and you can begin to grow your talent today.
There are plenty of options available to you, many of them free. If you're an MSDN subscriber, then you already have .NET capability. And the Apache SOAP project is free also. There are several sites online that offer C++, Java, Perl, C#, and VB libraries for Web services as well. You can find links to many of these at SOAPClient.com.
RSS
