Web Services pave the way for unparalleled interoperability over the Internet
As a Windows network administrator, you might be wondering how Microsoft .NET will affect your world. In fact, you might still be wondering what .NET is! I've read several good and bad attempts to describe .NET, but most of those attempts are equal parts technology and marketing spin. You're probably ready for a .NET discussion that cuts through the hype and focuses on the technology.
You're probably particularly curious about some of the new protocols and standards that will fall under the umbrella term of Web Services—a key component of .NET. Web Services promise to vastly simplify your life but will also present some new challenges. Before you dive into the details, check out the sidebar ".NET Demystified," page 24, for my succinct answer to the question, what is .NET?
What Are Web Services?
The media have described Web Services as the next phase of the Web's evolution. Web Services are compelling for many reasons, one of which is that most major e-commerce software vendors (e.g., Microsoft, IBM, Sun Microsystems, Ariba) have committed to support Web Services in their products. Because of this industrywide support, Web Services might finally provide the necessary adhesive to connect applications across networks, application frameworks, and OSs. Web Services provide two key benefits: First, they provide a new, more integrated way for applications to interact over the Web, and second, they let disparate application platforms interact more smoothly than ever before.
In today's Web-application world, you'll find many common elements—despite the varying hardware, software, and OSs in use. Most companies use a Web server (e.g., Microsoft IIS, Active Server Pages—ASP) to develop HTML-based presentation logic. For example, when you visit a Web site to buy a product, you use your browser to view the HTML results of the data that you've requested from the site. Behind the scenes, that site's Web server is communicating with a back-end database (e.g., Microsoft SQL Server) either directly from an ASP-generated page or through middle-tier business-logic application servers. Business logic, which represents the "brains" of a Web site application, is usually encapsulated within components written in object models such as COM or Java. By adding new capabilities, Web Services change this model.
Suppose Company A has developed a Web site that delivers weather forecasts for any city in the world. If I use my browser to visit Company A's site, I can click through a series of Web forms to obtain the forecast for a certain city. Now, suppose I offer worldwide travel information on my Web site, and I'd like to make Company A's weather information available on my site. In today's Web world, I can provide that information in a few ways—none of which are particularly elegant. First, I could link to Company A's site from within a frame on my site, passing a query string based on user input. Second, I could "screen-scrape" the results of a search from Company A's site and present it to the user at my site. Third, if Company A has componentized its weather logic, I might be able to buy it and run it on my site directly. Only the third option results in a good user experience, but I don't particularly want to invest in a new component every time I want to add new functionality to my site. Figure 1 illustrates today's Web site interactions.
What I'd like to do is call the business logic running on Company A's Web server directly from within my Web application. That way, my site could present users with a fully integrated experience and avoid the mess of the above approaches. I've just described the promise of Web Services, which provide applications a way to expose their own components and use other applications' components. Figure 2 illustrates this new interaction.
SOAP Keeps It Clean
Web Services applications use a standard set of protocols and services to communicate directly with other Web Services applications. A Web Services application creates a remote object and calls a remote method on the remote Web application server, just as I might do through Microsoft Distributed COM (DCOM), Java Remote Method Invocation (RMI), or Common Object Request Broker Architecture (CORBA) Internet Inter-ORB Protocol (IIOP). However, the Web Services set of technologies instead uses the Simple Object Access Protocol (SOAP).
SOAP is an XML-based way of representing interobject communication that's independent of the underlying object technology (e.g., COM, Java, CORBA). Figure 3 shows a Network Monitor trace from a SOAP message. The top frame shows the client application's HTTP requests and replies (designated as LOCAL) to the server running the Web Service (designated as ROUTER because the server resides across a router). The middle frame shows an exploded view of the currently selected HTTP packet. Notice that I've drilled into the HTTP request portion of the packet. The bottom frame shows the data values of the portion of the packet that I've highlighted.
Previous
