I paritcularly do not understand Mr. Zinmeister (a bank analyst) when he brings the following points to bear ,
- The use of common standards allows software developers to spend more time developing business logic rather than application code, automating processes and cutting costs
- The need for specialized skills is relatively low, according to Zinsmeister, because training a programmer to transition from C++ to C# (in the case of .NET, Microsoft's Web services framework), or from Java to J2EE (the competing Web services framework supported by IBM, Sun Microsystems, BEA and others), is fairly easy
- It enables wide-spread code reuse and a reduction in integration costs because all interfaces use the same standards and can now understand each other, which means that application code functionality can be written once and then leveraged by multiple applications rather than being written into each application separately; this also lowers maintenance costs because a change to the underlying logic of the application code only needs to be changed in one application rather than all
- More rapid development
- The ability to move architectures to lower cost hardware and software
- The ability to extend the lifecycle of legacy systems by wrapping an application (or a specific component of business logic within an application) in Web services standards, allowing other applications to leverage the data or logic that resides within the legacy system.
I can almost grant the first and last points. However, to both of these I must reply that these have been a goal for as long as there have been "legacy" applications or any business-related applications to develop. It is not clear to me, how allowing RPC via XML over HTTP really simplifies the first goal, that of common standards. I can easily write a Web Service (and have done so on purpose) that will not be digeastable by anyone else, common standards or not. As for legacy applications -- companies that really have valuable stuff on their mainframes have already invested into building applications to give them access to their data. Uboubtedly, many would benefit from getting easier and more uniform access to these systems -- that is not in contention; however, it is not clear how Web Services solve this problem easier than anything else or faster than anything else.
As far as other points go, I have to wonder how many thousands of feet in the air this views are taken from. I do not see how adding extra layers of web servers, security precautions, and management tools is going to help "move architectures to lower cost hardware and software". The fact that Linux is free and excellent, and current hardware is fast and cheap have little to do with Web Services, IMO. "Wide-spread code reuse" and "all interface use the same standards" are holy grails that do not become easier or harder with Web Services. If Amazon or Google opened up their systems via perl CGI they would have been just as effective. I plain do not know what "same standards" are or how they help to [applications to] "understand each other", unless it is equivalent to "all humans use sound waves transmitted over the air to understand each other". Sure we do, but it is not automatic and it is not easy. At some point blogspot may know how to interact with amazon API, but I doubt it would ever automatically recognize those from some random homepage.
Same kind of uncertainly I see for the "more rapid development" point. It is not at all clear to me that Web Services have somehow, or will in the near-to-mid-term future, provide us with a significantly faster development lifecycles than more traditional web applications or client-server applications. There is a lartge market for components that can be used to speed up development. Most shops do not use them, or use them very sparingly. The truth that most developers know is that components are often as hard to use as anything home-brewed. It is very hard to write good, general-purpose components. Everyone has their own very specific problems and there are always one or two requirements that are just not implemented in a general purpose component. We, as developers, have gotten used to some charting or statistical components, but in general, anything that is high-level enough to be considered a component is most of the time too inflexible to be used by a wide variety of developers employed by a wide variety of corporations.
In conclusion, I would like to write that it is not that I so completely disagree with this evaluation of problems facing IT, or that Web Services are incapable of alleviating some of the issues, only that bold points like those brought above tend to only confuse the picture rather than clarify it.