SOA and Web Services
The major advantages of implementing an SOA using Web services are that Web services are pervasive, simple, and platform-neutral.
As shown in Figure 1-6, the basic Web services architecture consists of specifications (SOAP, WSDL, and UDDI) that support the interaction of a Web service requester with a Web service provider and the potential discovery of the Web service description. The provider typically publishes a WSDL description of its Web service, and the requester accesses the description using a UDDI or other type of registry, and requests the execution of the provider's service by sending a SOAP message to it. The basic Web services standards are good for some SOA-based applications but are not adequate for many others.
Figure 1-6 Basic Web services architecture.
Why UDDI Is Not a Core Web Services Specification
It's safe to say that the original vision of UDDI has not been realized. When UDDI was launched in late 2000, it was intended to become a public directory. Companies were supposed to register their Web services with UDDI, and other companies were to come along later and dynamically discover the services they needed to access over the Internet. The assumption, which has not proven true, was that companies would be interested in discovering and requesting services from providers with whom they had no prior relationship. Also UDDI was developed before WSDL, so initially WSDL was not well supported. The data structures proved to be problematic because they are so open-ended with very little required information and a structure based on categorization data that isn't universally recognized. UDDI was also positioned as an inside-the-enterprise technology, and here it has gained some measure of success; however, the standards remain incomplete for this purpose. Companies adopting UDDI for internal use have to define their own naming conventions and categorization structure and metadata, which inhibits adoption. While SOAP and WSDL have gone on to tremendous success and widespread adoption, UDDI still struggles to find its proper place in the Web services universe. It is clear that a service registry is a required part of the Web services platform, but it isn't clear that UDDI will ever truly become that solution.
Besides the core Web services specifications (SOAP and WSDL), a wide array of extended Web services specifications for security, reliability, transactions, metadata management, and orchestration are well on their way toward standardization, providing SOA-based solutions the necessary enterprise-level qualities of service to support a wide variety of mission-critical, corporate-wide projects.
Borrowing from the Web
Some of the important advantages of using Web services as the technology platform for an SOA are derived from the way in which the World Wide Web achieved its tremendous success; in particular, the fact that a simple document markup language approach such as HTML (or XML) can provide a powerful interoperability solution and the fact that a lightweight document transfer protocol such as HTTP can provide an effective, universal data transfer mechanism. On the Web, it doesn't matter whether the operating system is Linux, Windows, OS390, HP NonStop, or Solaris. It doesn't matter whether the Web server is Apache or IIS. It doesn't matter whether the business logic is coded in Java, C#, COBOL, Perl, or LISP. It doesn't matter whether the browser is Netscape, Internet Explorer, Mozilla, or the W3C's Amaya. All that matters is that the Web servers understand an HTTP request for an HTML file and that the browser understands how to render the HTML file into the display. Web services provide the same level of abstraction for IT systems. Similarly, all that matters for Web services is that they can understand and process an XML-formatted message received using a supported communications transport and return a reply if one is defined. Just as HTML and HTTP can be added to any computer system with a TCP connection, Web services can be added to any computer that understands XML and HTTP or XML and most other popular communications transports.
Figure 1-7 illustrates the features and capabilities of the complete Web services platform on which the broad range of SOA-based applications can be built. It includes the basic and extended Web services specifications. See Chapter 2, "Overview of Service-Oriented Architecture," for a complete description of the Web services platform.
Figure 1-7 Web services platform.
The Web services platform contains the basic and extended features necessary to support an SOA, along with an enterprise service bus (ESB) to connect the services.