|I l @ ve RuBoard|
In the Internet economy, distributed computing architectures are primarily employed to increase application performance and scalability. By using clusters of low-cost servers to host their online applications rather than rely on a single (albeit large and powerful) system, e-commerce sites gain the ability to easily add new servers to handle increased load during periods of peak activity and avoid the expense and delay associated with upgrading or replacing a single system stretched beyond its capacity. Just as important, they gain increased reliability because the loss of one or two servers in a cluster simply increases the load on the remaining servers until the failed nodes are replaced .
Microsoft, Sun Microsystems, and the Object Management Group, along with many others, provide competing protocols and platforms for creating distributed object applications, the type of distributed computing services designed to enhance the scalability and reliability of e-commerce and other mission-critical systems. These systems are all similar in that they provide applications with remote access to data and functionality hosted on servers across a network as well as a wide array of architectural "plumbing" services such as support for remote message queues and distributed transactions. At the same time they attempt to hide the complexity associated with these services by creating the illusion that all of the remote objects, data, and services in use are actually hosted on the programmer's workstation. Quite an accomplishment, to say the least!
In general, all of the aforementioned solutions adequately address the need to create distributed applications that are scalable and reliable. A new problem arises, however, when these systems are required to communicate and share data and services with each other across the Internet. Consider, for example, what occurs when two banks merge to form a single business entity. The distributed systems in one bank could be implemented using Microsoft technologies exclusively, whereas the other bank's systems could be implemented using a combination of Java and Oracle technologies with a few legacy mainframe applications thrown in for good measure. Obviously, the IT departments in both companies would have to figure out a way to make these systems interoperate and present a seamless banking experience to their customers as rapidly as possible.
The unfortunate truth, however, is that today interoperability among these competing technologies can only be achieved at great effort and expense using complex middleware solutions designed to bridge the rather large gaps between them. Like CORBA and Java-based solutions, Microsoft's existing object technology, COM+, does not communicate well with other technologies, presenting a serious problem to those tasked with the unenviable chore of making them work together. In addition, the unpredictable nature of the Internet means that slow network connections, and even connection failures, are the rule rather than the exception. Again, none of the existing crop of distributed object technologies were designed to tolerate these conditions. Even worse , most corporate firewalls are configured by default to prevent the "wire protocols" these technologies use to communicate from entering or leaving the internal networks they are installed to protect which in turn precludes any of them from being widely adopted as an Internet standard.
The good news, on the other hand, is that Microsoft's Web Services architecture, a key component of the .NET initiative and the subject of this chapter, is specifically designed to solve the seemingly intractable problem of interoperability among heterogeneous systems. In fact, Web Services go one step further and address a number of other problems specifically associated with the development of distributed applications designed to communicate over the Internet.
What Is a Web Service?
As mentioned in the introduction, a Web Service can be loosely defined as an application that delivers a service across the Internet in a platform-independent and language-neutral fashion. To accomplish this feat, Web Services rely on several XML protocols based on open standards that are collectively known as the Web Services architecture. In addition to providing cross-platform interoperability, a Web Service can also be published to an Internet directory and queried using an industry standard discovery protocol called Universal Description, Discovery, and Integration (UDDI). UDDI is itself implemented using XML and is designed to provide programmers with an easy way to locate the services they require.
A good example of the potential use of the Web Service architecture is a credit card verification system. Utilizing the Web Services architecture, a financial institution can expose an existing credit card verification system by building a Web Services access layer and publishing it to a UDDI service discovery directory. Later, a potential consumer of credit card verification services can perform a search against the same directory and discover the verification service with minimal effort. After discovering the service, the client simply downloads the service's "contract," the document that describes the service's capabilities and programmatic interface, and adapts his or her application to utilize the service accordingly .
Of course, we glossed over a few issues, such as how one might pay for such a service, acquire the requisite security credentials to access the service, and similar nontrivial details, but from a technological standpoint, this is how the Web Services architecture works at its most basic level.
Now that our introduction to distributed computing is out of the way, we're ready to plunge right in and tackle the specifications and technologies that make up the Web Services architecture.
Coming Clean About SOAP
To allow two different systems to interoperate the Web Services architecture utilizes an XML-based messaging format known as SOAP. SOAP, which stands for Simple Object Access Protocol, acts as a sort of universal wire protocol to mediate communications between Web Services and client applications. SOAP is at the core of the Web Services architecture and is meant to replace DCOM, RMI, IIOP, and other proprietary wire protocols whenever access in a heterogeneous environment is a requirement.
The reason why SOAP succeeds at providing interoperability among heterogeneous systems where other protocols fail lies in the fact that it utilizes XML to provide a standard, yet extensible, data representation and messaging format. In short, SOAP allows any system, whether it is based on COM, Java, CORBA, or even plain old RPC, to communicate with any other system as long as both understand the SOAP protocol. Furthermore, SOAP is able to circumvent the aforementioned limitations imposed by firewalls by operating across standard Web protocols like HTTP and HTTPS. These standard Web protocols, and the TCP ports commonly associated with them, are almost always accessible across network boundaries because they're the same ones that carry standard HTML documents. This also means that Web Services based on the SOAP protocol are URL-addressable using a standard Web browser.
SOAP has been submitted by Microsoft, IBM, Ariba, and other partners for consideration as a standard to the W3C, and it appears to be on track for recommendation by that body. A Java implementation of the SOAP protocol is well underway under the guidance of the Apache Foundation. Both of these factors bode very well indeed for the future of application interoperability among these systems.
WSDL: A Service Contract Language
Another key standard in the Web Services architecture is the Web Services Description Language, or WSDL for short. Whereas SOAP is responsible for providing a platform-neutral protocol for transporting data types and interapplication messaging, WSDL is an XML grammar responsible for exposing the methods , arguments, and return parameters exposed by a particular Web Service. As such, it plays basically the same role that the various dialects of IDL (Interface Definition Language) do within the CORBA and COM architectures. In essence, WSDL provides everything a programmer needs to consume a Web Service from defining the structure of SOAP method calls to providing code-completion and other similar capabilities within the developer's IDE.
Disco and UDDI ”The Discovery Protocols
Disco and UDDI are similar in that they are both protocols used to discover the existence and capabilities of Web Services on the Internet. They differ , however, in their scope. If a developer knows that a particular URL hosts one or more Web Services, but is not aware of the capabilities offered , he or she can request an XML-formatted discovery document from the server revealing this information using the Disco protocol. If, however, as is often the case, the developer does not know beforehand the URL associated with the type of Web service he or she is trying to locate, it is necessary to query a UDDI business registry. UDDI business registries can (and probably will) be implemented themselves as Web Services and allow potential consumers of Web Services to more easily connect with the appropriate supplier.
Although a discussion of the advanced query mechanisms and XML data structures provided by UDDI is beyond the scope of this chapter and, indeed, this book, a quick visit to Microsoft's Web site or to the UDDI homepage at http://www.uddi.org should serve as a good starting point for exploring this topic.
To demonstrate that the Web Services architecture is more than just a set of specifications, you should visit the following Web sites and witness firsthand the power of Web Services to transform the Web into a useful medium for hosting distributed applications.
|I l @ ve RuBoard|