Defining Web Services

IBM’s definition of Web Services states that “Web Services are self-contained, modular applications that can be described, published, located, and invoked over a network, generally, the World Wide Web.” When the definition refers to Web Services being invoked over the World Wide Web, it means that they use HTTP as the transport layer and an XML-based message layer. However, Web Services do not actually require HTTP—XML-formatted data can be sent over other transport protocols (message queuing, for example), which may be more suited to mission-critical transactions. In addition, the World Wide Web is associated in the public mind with hypertext (HTML in particular, of course), rather than XML. If (and when) Web Services migrate from HTTP to other transport protocols, then “Web Services” will be less concerned with the World Wide Web as we know it, but will presumably still carry the word “Web” in its name. Web Services connotes producing a “web” of functionality, so the word “web” may still be applicable.

Navigating Firewalls

Web Services generally uses the HTTP and SSL ports (TCP ports 80 and 443, respectively) in order to pass through firewalls. In the early days of “Web Services,” vendors would say that their products were “firewall compliant.” This meant that firewalls would not block the Web Services traffic, whereas CORBA traffic attempting to use CORBA-specific ports may be blocked. Web Services make it easier to deploy distributed computing without having to open firewall ports, or having to “punch a hole in the firewall” as network administrators like to say. This “under the radar” deployment has serious security implications. Most firewalls are unable to distinguish Web Services traffic, traveling over HTTP and SSL ports, from Web browser traffic. With some firewalls it is possible to block Web Services traffic altogether, but not possible to set up different rules for separate Web Services. Chapter 3 discusses these issues in depth.

Service-Oriented Architecture: Publish, Find, and Bind

The word “Services” in Web Services refers to a Service-Oriented Architecture (SOA). SOA is a recent development in distributed computing, in which applications call functionality from other applications over a network. In an SOA, functionality is “published” on a network where two important capabilities are provided— “discovery,” the ability to find the functionality, and “binding,” the ability to connect to the functionality. In the Web Services architecture, these activities correspond to three roles: Web Service provider, Web Service requester, and Web Service broker, which correspond to the “publish,” “find,” and “bind” aspects of a Service-Oriented Architecture.

Web Services use what is termed dynamic binding. This means that applications that make use of Web Services can be dynamically composed, with the client binding to the server at runtime. The programming language used for the Web Service itself is immaterial; implementations of various pieces of functionality published as Web Services can be platform- and programming language-neutral. If a publisher wishes to radically change the way in which they implement functionality, or publish new functionality that can be found (“discovered”) by Web Service requesters, the Web Services architecture provides this capability. Before Web Services, static binding was traditional for application communication. Static binding meant that application integration was less flexible, because the communicating applications (and by extension their IT departments) would have to agree on which object types and programming languages to use.

Previous initiatives, such as CORBA, DCOM, Distributed Smalltalk, and Java RMI, required more agreement and shared context among business systems. Frequently, the functionality that was exposed was linked directly to the software objects used to implement the functionality. This does not mean that these technologies are not useful, just that the coarser-grained integration of Web Services may be more appropriate for distributed computing over the open Internet. Many of the Web Services technologies introduced in this chapter—UDDI, WSDL, and SOAP—were created in order to enable an SOA to run on the open Internet.

That's enough theory for now. Let’s look at the factors that enable this new technology. The SOA publish/find/bind functionality in Web Services depends on XML. So, let’s start with XML.