This chapter is from the book
This chapter is from the book
This chapter is from the book
The Web Architecture
The Web architecture assumes and deals gracefully with failure, latency, and all kinds of other real-world problems. This is a major strength and one that Web services have for the most part inherited. When you launch a Web browser, you expect that a number of the pages, graphics, and other files that you try to download will challenge you for credentials, or will have moved locations, or simply will no longer exist. Web services are challenged with the realities of this environment.
Assuming failure is a more advanced concept than it seems at first. For example, imagine you are building an application that will download a movie. As the size of your movie increases, the likelihood of some of the packets getting lost increases as well. As the developer of this application, you have a few choices: You can re-download every frame if you lose any one frame, you can ask for just the frames you missed, or you can skip them. Clearly the first choice isn't the best one, but deciding between the next two is difficult.
At its most basic level, the Web makes the last choice: It forgets about what it loses. This is an interesting choice, and it seems like the wrong one on the face of it. But the alternative requires a huge investment in infrastructure to make it work. Clearly, sometimes you need a thick and durably reliable infrastructure, but not always.
Imagine how much more traffic would be generated if your browser acknowledged every image it was downloading, and then the server resent until you received the image. As another example, consider the ubiquitous 404 error code: Built into the HTTP specification itself is the idea that a file may be missing from the server.
The Web is also hugely concurrent. It's the most concurrent system ever seen in computers. Every Web server and every client is operating in parallel. But programming for concurrency is extremely difficult. This is one of the ironies of modern Web development: The system itself is by definition almost unmanageably hard to develop for. The essential challenge is to handle state in an effective manner that takes into consideration the principle of assuming failure.
Web services are a set of technologies that enable you to develop distributed applications which take both failure and concurrency into account. Before we examine in more detail how Web services do this, let's take a moment to define what a Web service is.
Defining Web Services
Web service is one of the more difficult terms to define. Most definitions are inadequate on some level or another, which may be an indication that we are using the term too generally. It may be easier to begin by saying what a Web service is not. A Web service is not a Web site that a human reads—at least not in the way this book uses the term. A Web service is not anything with which an end user (even a very sophisticated end user) would directly interact. A Web service is something another process on another machine uses.
The Significance of Internet Standards
Web services are hard to define, but here is a serious attempt: A Web service is application logic that is accessible using Internet standards. The idea of getting data from one machine to another—that is, building a distributed application—is decades old. There have been many technologies for exposing application logic—but generally these were based on difficult-to-implement (binary in most cases) and often proprietary protocols. Standards, and in particular Internet standards such as XML, have simplified the building of a distributed application.
What Makes a Standard?
Some would argue that SOAP, for example, isn't a standard because it's not yet (as of this writing) a W3C (World Wide Web Consortium) recommendation. However, I think it is reasonable to say that standards may occur outside of standards bodies. A protocol such as SOAP may become a de facto standard, owing to its wide implementation across many platforms and
languages. SOAP easily meets this litmus test, as it has more than 50 implementations in every language I can think of, and on every OS I've ever heard of, plus some others I've never heard of! Furthermore, it is based on recommendations from the W3C, such as XML and HTTP.
The Significance of WSDL
Another, semicircular definition of a Web service is to say that it is anything a Web Services Description Language (WSDL) document can describe. Although true, this isn't much better than the first definition, but it is the one that most closely mirrors what I see in my head when I say "Web service." And, when I think of Web service clients, I think of technologies that consume WSDL documents to learn how to communicate with Web services. Of course, one could build a server or client that does nothing with WSDL, but the concepts of WSDL should be present, at the least.
The Significance of Interoperability
So why do Web services exist? There are many other technologies for accessing and exposing application logic, but these technologies usually have serious shortcomings. Web services attempt to solve these problems by promoting heterogeneous, interoperable, loosely coupled, and implementation-independent programs. I would say that the two largest design goals of most Web service technologies are interoperability and loose coupling.
Interoperability is usually the reason people become interested in Web services. The significance of interoperability is fairly easy to comprehend. For example: Web services allow a Perl developer to interoperate with a C++ developer on Microsoft Windows 2000, who in turn can interoperate with an AppleScript programmer on a Macintosh OSX. I've seen this exact scenario, not just in demonstrations, but also in actual deployed applications that allow businesses to integrate more easily than in the past. That is because now they can work with their partners without having to adopt a platform that isn't their usual one. Table 1.1 lists a small sampling of the Web service technologies currently available.
Table 1.1: Popular Web Service Technologies
|
Product |
Support OS |
Language |
|
Apache SOAP |
UNIX, Windows |
Java |
|
WASP |
UNIX, Windows |
C++ |
|
GLUE |
UNIX, Windows |
Java |
|
SOAP BEA WebLogic |
UNIX, Windows |
Java |
|
MS SOAP Toolkit |
Windows |
C++, VB, COM |
|
.NET Framework |
Windows |
C#, VB.NET |
|
SOAP::Lite |
UNIX, Windows |
Perl |
|
PocketSOAP |
WinCE |
C++ |
|
SOAP for ADA |
Linux |
Ada |
|
Web Service Behavior |
Windows |
JavaScript, DHTML |
|
SOAPx4 |
UNIX |
PHP |
|
Delphi 6 |
Windows |
Delphi |
The Significance of Loose Coupling
Another powerful feature of Web services is how easily they allow you to build loosely coupled systems. Loosely coupled is another term that is difficult to define precisely. In general, when I say loosely coupled, I mean that a system exhibits both implementation independence and versioning without breakage.
Implementation independence is an easy enough concept to get across. If I want to implement the same Web service on machine A to machine B, then it shouldn't matter that machine A is a Java/UNIX program and machine B is a C#/Windows program. This is a basic requirement of Web services.
Versioning ease via loose coupling is a little harder to describe and grasp at first. Clearly, a machine running a version 1 client can expect to interoperate with a version 1 server. But what about mismatched versions? If machine A is running version 1 of a service and sends a message to machine B, which is running version 2, then machine B should be able to receive and understand the message. Of course, Web services don't make this possible in every case because there is always the human element to deal with: business rules and other facts of the real world. Regardless, versioning without breakage is a genuine goal, and a powerful one. Figure 1.1 gives an example of this.
)
Figure
1.1: Versioning Web Services