This chapter covers Web services development with Microsoft .NET, including how to create Web service projects using the .NET Framework and Visual Studio .NET. The chapter also discusses Microsoft s support for emerging Web service standards provided by Web Services Enhancements for Microsoft .NET (WSE). In this chapter, you ll look at the architecture of the WSE components and see how they integrate with ASP.NET and the .NET Framework to support these emerging Web service specifications. You ll also learn how to install, configure, and program with WSE.
Since Web Services Enhancements supports and enriches the development of XML Web services for Microsoft .NET, let s first review the relevant components of .NET and how they are used to support Web services. Microsoft defines .NET as the Microsoft solution for XML Web services, the next generation of software that connects our world of information, devices, and people in a unified, personalized way. (See http://www.microsoft.com/net/basics/faq.asp .) Of course, .NET is all about Web services, and in recent years , Microsoft has rolled out a number of key components that support this Web services infrastructure, the most important of which are the .NET Framework, Visual Studio .NET, and, most recently, Web Services Enhancements.
Before describing the architecture of .NET Web services, I think it s helpful to understand how distributed Internet computing has evolved into Web services by taking a look at Microsoft s previous approach. Before .NET, Microsoft had developed a platform for Internet-based distributed computing known as the Windows Distributed Internet Applications (Windows DNA) architecture. The architecture of Windows DNA (depicted in Figure 2-1) is based on an n- tier model that used a tightly coupled Distributed Component Object Model (DCOM) model to enable the transmission of data over low-level Internet protocols based on TCP/IP.
In this distributed architecture, when a DCOM client called a method on a remote DCOM server, the COM runtime on the client created a proxy object for marshaling the procedure call. This marshaling process involved serializing data from the client into a bit stream of binary data that was deserialized at the other end. DCOM calls were generally synchronous, which meant the thread stayed busy until the call completed.
In contrast with the previous client/server architecture models typified by Windows DNA, Web services support a message-based call structure that can be either synchronous or asynchronous. Also, the need to marshal a call into a stream of platform-specific binary data has been eliminated; instead, a SOAP message is serialized as a standard XML stream. Since the format of this XML stream is defined by a set of publicly available specifications, it is easier for Web services to be implemented on any platform and adhere to these specifications. Web services allow server applications to provide their functionalities over the Internet to other applications and even through firewalls, regardless of the platform or device on which the client application is installed. Figure 2-2 shows an example of the .NET Web services architecture.
The message-based nature of SOAP better supports asynchronous messaging, which can be used when a return message isn t required. Figure 2-2 also illustrates that a Web service application can expose data and services to both client applications and other Web services. In addition, a Web service can itself access other Web services (acting as a client) to provide a value-added service to its own client applications.
Web services rely on underlying Internet-aware platform components when receiving SOAP request messages; for SOAP messages over HTTP, a Web server takes on this role. This Internet-aware component in turn invokes the particular Web methods that the SOAP message is accessing, where these Web methods themselves can in turn call other Web services. While the code that implements Web service methods and serializes and parses XML can be complicated, it is usually provided by the Web service platform. From a high-level perspective, creating Web services is rather simple and requires the following general tasks :
Code your application You can create the core of the Web service application by writing new .NET assemblies in managed code or exposing an existing COM-based application as a Web service. Visual Studio .NET makes it easy to do both.
Set up a SOAP listener To respond to SOAP requests, you need to be able to properly receive and handle them. In Microsoft .NET, ASP.NET implements a listener for HTTP-based Web service requests . The listener reads an incoming HTTP request, parses the XML in the SOAP message envelope, checks for any required information in the SOAP message header, and based on the HTTP SOAPAction header invokes the requested method. Because a Web service client knows when to expect a SOAP response in answer to a request, a SOAP listener needs to be active only on the server side of the exchange. Since SOAP isn t bound strictly to HTTP, it would be possible to receive a SOAP request via a different transport, such as TCP/IP or Simple Mail Transfer Protocol (SMTP). While ASP.NET listens by default on HTTP sockets, WSE 2.0 has an extensible messaging infrastructure capable of using both HTTP and TCP sockets.
Develop discovery and description mechanisms for your Web service Although XML supports strong typing, or using schema to define the data types of various elements and attributes, and is easily described (such as by XML schema documents), it isn t really a self- describing data format. For a client application to access your Web service, it needs to know how to communicate with it. Chapter 1 covered some of the description and discovery mechanisms used by XML Web services. Typically, a Web service is described by publishing a Web Services Description Language (WSDL) document either on the Web server or in another accessible location; or in the case of a .NET Web service, ASP.NET can automatically generate a WSDL document on request. Additional requirements for accessing the Web service, such as security requirements, can be described using a policy document, which I cover in Chapter 6.
Web services facilitate interoperability in your enterprise because they can be hosted on any platform that provides the ability to read and write XML, which is essential to creating and interpreting SOAP messages. However, the code that you must write to manually create and interpret XML that is both valid and in compliance with the required Web service standards can make creating the application components described in the preceding tasks a fairly difficult process. In addition to simply writing your application logic, this process involves writing lots of additional serialization code, where there is much more room for error in the form of incorrect, invalid, or nonstandard serialization.
Today, when you re developing and hosting your own Web services, you re able to avoid this tedious and error-prone work of serializing and deserializing XML. Most of the major enterprise software players have released integrated development environments ( IDEs ) that simplify these processes. Because Web services are a major piece of Microsoft .NET, the extensive support that Microsoft provides for Web services in the Microsoft .NET Framework and Microsoft Visual Studio .NET makes publishing your components as a Web service almost trivial. In this book, I will focus primarily on developing Web services using Microsoft .NET. For more information about developing Web services, check out the books Building XML Web Services for the Microsoft .NET Platform (Microsoft Press, 2002) by Scott Short and Programming Microsoft .NET XML Web Services (Microsoft Press, 2004).
The .NET Framework is the cornerstone of Microsoft .NET. The .NET Framework provides a managed, secure, and XML-aware run-time environment for Web services and other managed code applications. The key technologies in the .NET Framework are the common language runtime (CLR), a unified set of base class libraries, and ASP.NET. Figure 2-3 shows Microsoft s view of the .NET architecture and the key role played by the .NET Framework.
The CLR features technologies that make applications more reliable by, for example, eliminating memory leaks through garbage-collecting released memory blocks and applying its own strict security policies when calling legacy or unmanaged COM objects. The common in CLR refers to the fact that in .NET, all of the CLR-compliant high-level programming languages are compiled down to a common intermediate language (MSIL). This code is then just-in-time (JIT) “compiled into platform-specific machine language that is executed in the same way by the CLR regardless of the original development language. The JIT code can also be cached for improved performance. If you want to learn more about the details of the facilities provided by the .NET Framework, see Jeffrey Richter s book Applied Microsoft .NET Framework Programming (Microsoft Press, 2002).
Currently you can build .NET applications in more than 20 languages, including C++, Microsoft Visual Basic .NET, JScript, and C#, Microsoft s newest object-oriented programming language designed specifically for .NET. As you ll notice, in this book I code almost exclusively in C#, but rest assured that because all .NET programming languages compile down to the same MSIL code, Visual Basic .NET has all the power and performance of C# and can no longer be considered a second-class programming language for enterprise applications.
Because ASP.NET leverages the CLR, you can create applications and services in any programming language that .NET supports (with the exception of Visual C++ .NET). Also, whereas ASP was essentially a script-based technology, ASP.NET is event driven and offers performance improvements; it s also compiled down to MSIL at design time, being JIT compiled only on the first request, and the resulting native code is also cached for additional performance gains. If you like the idea of programming closer to the metal, ASP.NET enables you to write custom HTTP filters to intercept incoming HTTP requests and outgoing HTTP responses and inject your own custom logic. With HTTP filters, you don t have to go through the hassle of writing and implementing custom filters using the Internet Server Application Programming Interface (ISAPI) as in previous versions of ASP and Internet Information Services (IIS).
Generally, ASP.NET applications run with a default set of properties and behaviors, which are specified in a set of XML configuration files. When you want to make an ASP.NET application behave differently, such as changing caching settings or error behaviors, you can change these configuration settings without having to recompile the application. ASP.NET uses four main configuration files:
Web.config This configuration file sets the properties for a single ASP.NET application. This is the primary configuration file for Internet applications, and each Web service can have a separate instance of Web.config in the application s virtual directory.
Machine.config Located in the Config folder of the directory containing the .NET Framework files, this configuration file sets properties that apply to all ASP.NET applications running on the local Web server.
Security.config Located in the Config folder of the directory containing the .NET Framework files, this configuration file sets security properties for all .NET applications running on the local computer.
Enterprisesec.config Located in the Config folder of the directory containing the .NET Framework files, this configuration file sets the properties for all .NET applications in an entire domain.
In this book, I ll assume that you have a moderate skill level with and understanding of ASP.NET. Therefore, I won t spend any more time discussing ASP.NET except as it relates to implementing .NET Web services. For more in- depth information about creating and deploying Web applications using ASP.NET, see Programming Microsoft ASP.NET , by Dino Esposito (Microsoft Press, 2003).
Visual Studio .NET is the latest version of Microsoft s popular software development suite. One of the advantages of using Visual Studio .NET is that it lets you write managed code for .NET client applications in more than 20 programming languages ”including the Microsoft core languages, C#, Visual Basic .NET, Visual C++ .NET, and J# ”as well as install third-party add-ins that enable development in many other languages. These managed code applications have the advantage of being able to leverage the power of the .NET Framework. Another major feature of Visual Studio .NET is that it lets you easily develop Web services without having to do any of the heavy lifting of programmatically serializing SOAP messages.
When using Visual Studio .NET and the .NET Framework, you can create a Web service by simply adding the WebService attribute to the class that implements the Web service and the WebMethod attribute to any public methods in this class that are exposed as Web service methods. This Web service code is contained either in an ASP.NET page or in a file or .NET assembly that is referenced by the ASP.NET entry point for the Web service. ASP.NET does the work of translating SOAP request messages into method calls against these exposed Web methods and serializing SOAP response messages containing the returned data. For example, the following code sample shows how to create a simple Web service that returns the classic Hello, World! string:
// Create an alias for namespace references.
// Define the namespace for the Web service.
// Define a Web service class and apply the WebService
public class TestWebService
// Define a Web service method and apply the WebMethod
public string HelloWorld()
string myString = "Hello, World!";
This simple Web service is accessed by the following SOAP request message:
<?xml version="1.0" encoding="utf-8"?>
And the Hello World response is returned in the following SOAP response:
<?xml version="1.0" encoding="utf-8"?>
This book will focus on enhancements to the .NET Web services platform that are intended to drive enterprise interoperability, and all examples were developed using Visual Studio .NET 2003. For more general information about building Web services and examples that use Visual Studio .NET to do so, read Building XML Web Services for the Microsoft .NET Platform and Programming Microsoft .NET XML Web Services .
While it s easy to create a Web service using Visual Studio .NET, it s equally easy to access a Web service from a Visual Studio .NET application: all you need to do is use the Add Web Reference dialog box to add a Web reference to the Visual Studio project. When you add a Web reference, Visual Studio .NET automatically generates a proxy class (based on the description information published by the Web service ”typically a WSDL document) that abstracts the Web service. When you use this class, accessing the methods of a Web service is as simple as accessing methods of any .NET object. Calling the Web service is as simple as creating a new instance of the Web service class and then calling a desired method.
The more complicated a Web service is with regard to the number of methods and the complexity of types, the longer and more complicated the description files get, with a typical WSDL file for a simple Web service comprising hundreds of lines of code. So now you re asking yourself, Do I really have to write a program to parse all that XML? Deconstructing WSDL and composing SOAP queries by hand, or even with XML utilities, can be a daunting and expensive challenge.
Fortunately, Visual Studio .NET can use a WSDL file to do the following:
Automatically generate local proxy objects that abstract the Web service interface that is described in the WSDL document
Do all the work required to generate the correct SOAP messages from the local class instances and send it to the service
Create the code that captures the response and marshals it back to managed code (in this case, a string)
This makes accessing Web services from your Web site no different from using local built-in class libraries.
Visual Studio .NET provides an Add Web Reference feature that reads a WSDL document and uses it to dynamically construct the necessary proxy objects. In the process of adding a Web reference, Visual Studio .NET parses a WSDL file and generates the necessary proxy objects on the client that do all of the complex SOAP serialization work and provide a nice layer of abstraction when you re programming client applications. Figure 2-4 shows the Add Web Reference dialog box, which allows Visual Studio .NET to locate a Web service, retrieve its WSDL document, and use description information in the WSDL to create proxy programming objects that represent the referenced Web service.
Again, Scott Short and others have covered, in great detail, building Web service “consuming client applications using Visual Studio .NET, so I m not going to cover that territory in this book.
Microsoft has been a strong proponent of using SOAP from the outset of Web services; thus, the .NET Framework includes extensive support for serializing and manipulating SOAP messages. While .NET makes it extremely simple to create and publish Web services, it also provides a powerful set of classes for creating and modifying the contents of SOAP messages. SoapHeader is a particularly useful class within the System.Web.Services.Protocols namespace that lets you add message-specific information to SOAP messages inside customized header elements. For example, say that you wanted to pass a username in a custom SOAP message header as follows :
To direct ASP.NET to serialize the myCustomHeader header element, you simply create a class that inherits from SoapHeader and that exposes a public string named username . This header gets created in the outgoing SOAP message by your specifying an instance of myCustomHeader in the SoapHeader attribute of a Web method as follows:
// Create an instance of a SoapHeader inherited class.
public myCustomHeader myHeaderInstance;
// Apply SoapHeader and WebMethod attributes to the SOAP method.
Although it s certainly beneficial to be able to create customized SOAP headers in which you can pass security tokens and message routing information, applications that rely on custom header formats run the risk of breaking interoperability scenarios and thus undermining the most promising aspect of Web services. Although it s perfectly acceptable, according to the Basic Profile 1.0, to use custom headers to give us this type of enterprise computing feature without jeopardizing interoperability, what s needed is a standard set of SOAP headers that support the enterprise, which is precisely what the proposed Web service specifications provide.