Solution Architecture

The problem of universal programmatic access to the Internet is similar to the problem faced by designers of the international air traffic control system. A randomly changing set of heterogeneous nodes (different types of aircraft) needs to talk to fixed servers (control towers) and each other. Their internal programming (the flight crews’ thoughts) works in all kinds of different, incompatible languages (Thai, Norwegian, Californian). Communication between the flight crews, aircraft, and control towers has to work right or terrible things happen, such as on March 27, 1977, at Tenerife, when two 747s collided during takeoff because of misunderstood tower communications and 583 people died.

International air traffic control faces a problem similar to universal Internet access.

Solving the problem requires agreement among all parties operating aircraft. Given the size (all aircraft operators in the world) and heterogeneity (rich and poor passenger airlines, cargo carriers, general aviation, military, smugglers, and so on) of this group, the only approach that stands any chance of working is to standardize on the lowest common denominator in two critical areas. First, as the mechanism for physically transmitting information from one party to another, aircraft use VHF radios on designated frequencies. Second, air traffic control requires a standardized way of encoding the information transmitted. By international agreement, all pilots and control towers are required to use only English, even Air France flights landing at Charles de Gaulle International Airport in Paris (which annoys the heck out of them).

The air traffic control problem was solved by agreeing on a lowest common denominator, the English language.

Like the solution for the air traffic control problem, the only way to deal with the enormous numbers of heterogeneous entities on the Internet is to use the lowest common denominator. When we decide how to transfer bytes from one box to another, we need to use something that every box on the Internet has, analogous to the VHF radio that every aircraft carries. The most common Internet transfer protocol is HTTP (Hypertext Transfer Protocol), which is used today by essentially all Web browsers to fetch the pages they display. We also need a lowest common denominator for encoding the information that we transfer with HTTP. As air traffic control uses English, our universal scheme will use XML (eXtensible Markup Language) for encoding the data sent from one party to another.

The lowest common denominator on the Internet is HTTP and XML.

Microsoft put these ideas together and came up with the concept of XML Web services. An XML Web service is a seamless way for objects on a server to accept incoming requests from clients using the Internet’s lowest common denominator of HTTP/XML. To create an XML Web service you don’t have to learn a new way to program. You simply write a .NET object more or less as if it were being accessed directly by local clients, mark it with an attribute that says you want it to be available to Web clients, and ASP.NET does the rest. ASP.NET automatically hooks up a prefabricated infrastructure that accepts incoming requests through HTTP and maps them to calls on your object, as shown in Figure 4-2. When you roll your objects into an XML Web service, they can work with anyone on the Web that speaks HTTP and XML, which should be everybody in the universe, no matter what type of operating system and run-time environment they’re running in. You don’t have to write the infrastructure that deals with Web communication; the .NET Framework provides it for you.

An XML Web service seamlessly connects your .NET objects to incoming HTTP requests.

Figure 4-2: Server-side view of XML Web services.

On the client side, .NET provides proxy classes that allow easy, function-based access to the XML Web services provided by any server that accepts HTTP requests, as shown in Figure 4-3. A developer tool reads the description of the XML Web service and generates a proxy class containing functions in whatever language you use to develop the client. When your client calls one of these functions, the proxy class creates an HTTP request and sends it to the server. When the response comes back from the server, the proxy class parses the results and returns them from the function. This allows your function-based client to seamlessly interact with any Web server that speaks HTTP and XML, which, again, should be everybody.

.NET also provides proxy classes that make it easy to write an XML Web service client by hiding the details of Internet communications.

Figure 4-3: Client-side view of XML Web services.

XML Web services are very much in their infancy today (January 2003). As with raw DCOM, they provide basic connectivity from one box to another. But also as with raw DCOM, when you start making calls from one box to another, you encounter new classes of problems that the basic connectivity package doesn’t address; for example security, reliable message delivery, and operational integrity. These problems are common to most applications, so it only makes sense to address them at an operating system level rather than have each software vendor spend time and money to roll its own incompatible version. As Microsoft developed MTS and later COM+ to address these sorts of problems in the COM world, so they are now working on solutions to these problems in the Web services world. The complicating factor is that since Web services are fundamentally about cooperating with non-Microsoft systems, the design process requires time and compromises among many parties to reach agreement on how they ought to work. The new Web Service Enhancements v1.0, available for download from MSDN, provides early implementations of some of these new standards. The last section of this chapter shows an example.

XML Web services are in their infancy today.

Tips from the Trenches

Web services were originally designed in the euphoric days of the first Web platinum rush, with the NASDAQ index shooting through 3000 en route to 5000. Marketing types crazed on their own hot air turned cartwheels, shouting, “HOORAY! YOUR CELL PHONE WILL GET SPORTS SCORES AND STOCK UPDATES!!!” No one stopped to ask, “Hey, does anyone really CARE about that except as a short-lived curiosity for socially retarded geeks?” And no one asked how anyone was going to make any money with it. The open, free-for-all design of Web Services, with no security or encryption or distributed coordination, reflects that free-love philosophy. But having another computer program call yours is usually at least a semi-intimate transaction, in a way that’s qualitatively quite different from having a human view your Web page. The giant cross- platform orgy never happened, despite sensuous lubrication with tons of Microsoft snake oil, and the NASDAQ is currently down around 1300.

That doesn’t mean that XML Web Services are useless, far from it. They represent the basic solution to a very important and vexing class of problem. But except for projects that appeal to our sense of curiosity, my customers report that they are using XML Web services to connect heterogeneous systems within their own enterprises rather than outside them. For example, it’s common for an insurance company to have their Web servers on one type of system, their policy issue software on another type, their accounting and billing software on a third type, and need to tie them together. Meanwhile, the insurance company might acquire another insurer and need to integrate new systems with their own. XML Web services are excellent for crossing these types of platform boundaries. Connecting systems that they control over network wires that they also control is an order of magnitude easier than interoperating with random Internet passers-by, and the financial return much more certain. The shopping Web service that allows the Internet refrigerator to automatically order more orange juice is waiting for prefabricated solutions to more of the common infrastructural problems.