The World Wide Web Consortium defines a web service as
...a software system designed to support interoperable machine-to-machine interaction over a network. It has an interface described in a machine-processable format (specifically WSDL). Other systems interact with the Web service in a manner prescribed by its description using SOAP messages, typically conveyed using HTTP with an XML serialization in conjunction with other Web-related standards (Booth and others; 2004).
Those other web-related standards are designed to be composable, meaning that any one or more of them can be selected for use in a given case. That the standards are composable in that way was intended from the outset because “SOAP’s [very] architecture anticipates the composition of infrastructure protocols through the use of a flexible header mechanism” (Cabrera, Kurt, and Box; 2004). The protocol defined by each standard specifies the format and use of a separate header of a SOAP message. The composability of the web service specifications is in contrast to
...[n]umerous domain-specific communication protocols [that] are effectively “silos” in which protocol designers find themselves coining new mechanisms for dealing with security, reliability, error reporting, etc. ...[T]his approach to defining an entire protocol for each vertical domain breaks when domains overlap and becomes extremely costly in terms of both initial development and ongoing support costs (Cabrera, Kurt, and Box; 2004).
The Windows Communication Foundation is designed to facilitate interoperability via the web services standards. Specifically, it provides implementations of a great many of those standards, and developers can use those implementations to achieve interoperability with other systems that implement a subset of those same specifications.
The complete list of specifications implemented by the Windows Communication Foundation is included in the documentation, and made available on the Internet. To locate it, search for “Web Services Protocols Supported by System-Provided Interoperability Bindings” in the Microsoft Developer Network Library at http://msdn.microsoft.com/library/default.asp.
The predefined BasicHttpBinding binding implements a profile—the WS-I Basic Profile 1.1—that specifies how a small subset of the web services protocols can be used to maximize the likelihood of interoperability. WSHttpBinding and WSFederationBinding bindings incorporate implementations of a number of communications protocols for which profiles do not yet exist, including WS-Security, WS-ReliableMessaging, WS-SecurityPolicy, WS-AtomicTransaction, WS-Coordination, and WS-Trust. Although communication via those protocols with non–Windows Communication Foundation applications using other implementations of the same protocols can be accomplished using the WSHttpBinding and WSFederationBinding as a foundation, doing so might require considerable effort. As developers create profiles for additional protocols, versions of WSHttpBinding and WSFederationBinding with the appropriate defaults will likely become available, and interoperability with other software that conforms to the same profiles should be easy to achieve.
Chapter 2, “The Fundamentals,” showed that by virtue of the WS-I Basic Profile 1.1, it is possible to build a Java client for a Windows Communication Foundation service. To see that a Windows Communication Foundation client can also readily interoperate with a non–Windows Communication Foundation service, follow these steps to build a client for Sun Microsystems’ public services for interoperability testing:
Create a new Visual Studio 2005 C# Console Application project called SunClient in the folder C:WCFHandsOnInteroperability.
Open the SDK Command Prompt by choosing All Programs, Microsoft Windows SDK, CMD Shell.
Use the
cdcommand at the prompt to make C:WCFHandsOnInteroperabilitySunClient the prompt’s current directory.Enter this command at the prompt to generate a Windows Communication Foundation client in a file that should be named InteropTest.cs, and a Windows Communication Foundation configuration file named App.config:
svcutil http://soapinterop.java.sun.com/round2/base?WSDL /config:App.configAdd the generated files C:WCFHandsOnInteroperabilitySunClientInteropTest.cs and C:WCFHandsOnInteroperabilitySunClientApp.config to the Visual Studio project.
Open the Interop.cs file and look at the list of types defined therein to find one with the suffix Client. That will be the Windows Communication Foundation client that you can use for communication with the Sun Microsystems’ service. It should be a class named
RIBaseIFClient.Choose Project, Add Reference from the Visual Studio 2005 menus and add a reference to the Windows Communication Foundation’s
System.ServiceModelassembly.Open the Program.cs file and add this code to the
Main()method defined therein:RIBaseIFClient client = new RIBaseIFClient(); client.Open(); foreach (string currentString in client.echoStringArray( new string[] {"Hello", ",", " ", "World!" })) { Console.Write(currentString); } Console.Write(" "); client.Close(); Console.Write("Done!"); Console.ReadKey();Notice that in writing
RIBaseIFClient client = new RIBaseIFClient();
no information about the endpoint with which the client is to communicate is specified. This phrase takes advantage of a convenience provided by the Windows Communication Foundation by which, if the code does not explicitly identify an endpoint configuration, the Windows Communication Foundation uses the first endpoint configuration it finds in the configuration file. Because the configuration file should have only the configuration for the Sun Microsystems service endpoint for which it was generated, that convenience provides a suitable result in this case.
Choose Debug, Start Debugging from the Visual Studio 2005 menus. The console should show the application using the Windows Communication Foundation client to send an array of strings to the Sun Microsystems service, which echoes them back to the client for display in the console.
Choose Debug, Stop Debugging from the Visual Studio 2005 menus.
This chapter covered the Windows Communication Foundation’s facilities for interoperating with applications on other platforms. The Windows Communication Foundation provides for interoperability through its implementation of various web services protocols. The WS-I Basic Profile 1.1 defines how you can use a subset of those protocols to maximize the likelihood of interoperability. Thus it was possible to show how a Windows Communication Foundation client can easily be made to communicate with a non–Windows Communication Foundation service that conforms to the profile.