Summary Observations and Conclusions


Probably the biggest surprise for me in writing this book was the current state-of-the-art of Web services. Reports in the trade press, vendor hype, and even some customer testimonials led me to believe that Web services standards were more advanced and sophisticated than they really are. Web services have a lot of maturing to do in order to become viable for running mission-critical applications. Improvements need to be made in reliability, availability, security, manageability, routing, and numerous other areas in order to make Web services usable for large-scale secure transaction processing and other applications. But until the standard's mature, Web services can be augmented by third-party products and used in some mission-critical computing environments.

Another "shocker" was that Web services can be designed and delivered using XML and HTTP protocols and without using UDDI, WSDL, and SOAP as middleware. Many companies interviewed and reviewed in the "real-world" chapter had made use of COM or CORBA middleware for program-to-program communications purposes, owing to certain shortcomings in Web services maturity. (Some of these shortcomings include reliability, security, and manageability.) In fairness, however, some of these companies had either in-house CORBA or COM expertise or existing COM or CORBA middleware that enabled them to deploy applications more quickly using existing people or existing code. So, for these companies, using non-Web-services protocols and registries proved more expedient.

Yet another surprise was the lack of use of UDDI registries. Most of the early adopters of Web services are not using UDDI registries instead they are hard-coding (entering directly into their applications code) the addresses of the applications with which they want to cooperate. Still, at this juncture in Web services development, this practice makes good sense. You need a large number of applications to create a viable and useful public directory; and you need Web services applications to be reliable, secure, and robust in order to build a viable and useful private directory. The Web services applications architecture still needs to mature a bit in order to create viable enterprise-class solutions for public directories; and private Web services application modules need to be catalogued and quality-tested before being placed in a private UDDI registry.

On the positive surprise side I was very impressed with the level of cooperation that I saw between vendors. In the past, many vendors alleged that they were building a "standards-based" approach to cross-platform program-to-program communications but often these same vendors made decisions that benefited themselves in the design of their respective architectures (alienating other vendors who were trying to follow their lead). And in the past, standards committees acted too slowly and produced standards that were far too complex (overorchestrated) and too cumbersome to be used by small- and medium-sized businesses. I was delighted to see the progress that has been made in building Web services. I am especially pleased to see the level of cross-vendor cooperation that is taking place between Microsoft and IBM in creating true cross-platform program-to-program communications using common Web service protocols and registries.



Web Services Explained. Solutions and Applications for the Real World
Web Services Explained, Solutions and Applications for the Real World
ISBN: 0130479632
EAN: 2147483647
Year: 2002
Pages: 115
Authors: Joe Clabby

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net