Dealing with something as an integrated whole is self-evidently easier than having to understand and manipulate all of its parts. Thus, to make programming easier, it is commonplace to define classes that serve as integrated wholes, keeping their constituents hidden. Doing so is called encapsulation, which is characteristic of what is known as object-oriented programming.

The C++ programming language provided syntax for encapsulation that proved very popular. In C++, one can write a class like this one:

class Stock
{
private:
    char symbol[30];
    int number;
    double price;
    double value;
    void SetTotal()
    {
        this->value = this->number * this->price;
    }
public:
    Stock(void);
    ~Stock(void);
    void Acquire(const char* symbol, int number, double
price);
    void Sell(int number, double price);
};

The class hides away its data members—symbol, number, price, and value—as well as the method SetTotal(), but exposes the methods Acquire() and Sell() for use.

Some refer to the exposed surface of a class as its interface, and to invocations of the methods of a class as messages. David A. Taylor does so in his book Object-Oriented Information Systems: Planning and Integration (1992, 118).

Using C++ classes to define interfaces and messages has an important shortcoming, however, as Don Box explains in Essential COM (1998, 11). There is no standard way for C++ compilers to express the interfaces in binary format. Consequently, sending a message to a class in a dynamic link library (DLL) is not guaranteed to work if the calling code and the intended recipient class were built using different compilers.

That shortcoming is significant because it restricts the extent to which the class in the DLL can be reused in code written by other programmers. The reuse of code written by one programmer within code written by another is fundamental not only to programming productivity, but also to software as a commercial enterprise, to being able to sell what a programmer produces.

Two important solutions to the problem were pursued. One was to define interfaces using C++ abstract base classes. An abstract base class is a class with pure virtual functions, and, as Box explained, “[t]he runtime implementation of virtual functions in C++ takes the [same] form[...]in virtually all production compilers” (1998, 15). You can write, in C++, the code given in Listing 2.1.

//IStock.h
class IStock
{
public:
      virtual void DeleteInstance(void);
      virtual void Acquire(const char* symbol, int number, double price) = 0;
    virtual void Sell(int number, double price) = 0;
};

extern "C"
IStock* CreateStock(void);

//Stock.h
#include "IStock.h"

class Stock: public IStock
{
private:
    char symbol[30];
    int number;
    double price;
    double value;
    void SetTotal()
    {
        this->value = this->number * this->price;
    }
public:
    Stock(void);
    ~Stock(void);
    void DeleteInstance(void);
    void Acquire(const char* symbol, int number, double price);
    void Sell(int number, double price);
};

In that code, IStock is an interface defined using a C++ abstract virtual class. IStock is an abstract virtual class because it has the pure virtual functions Acquire() and Sell(), their nature as pure virtual functions being denoted by having both the keyword, virtual, and the suffix, = 0, in their declarations. A programmer wanting to use a class with the IStock interface within a DLL can write code that retrieves an instance of such a class from the DLL using the global function CreateStock() and sends messages to that instance. That code will work even if the programmer is using a different compiler than the one used by the programmer of the DLL.

Programming with interfaces defined as C++ abstract virtual classes is the foundation of a Microsoft technology called the Component Object Model, or COM. More generally, it is the foundation of what became known as component-oriented programming.

Component-oriented programming is a style of software reuse in which the interface of the reusable class consists of constructors, property getter and setter methods, methods, and events. Programmers using the class “...follow[] a pattern of instantiating a type with a default or relatively simple constructor, setting some instance properties, and finally, [either] calling simple instance methods” or handling the instance’s events (Cwalina and Abrams 2006, 237).

Another important solution to the problem of there being no standard way for C++ compilers to express the interfaces of classes in binary format is to define a standard for the output of compilers. The Java Virtual Machine Specification defines a standard format for the output of compilers, called the class file format (Lindholm and Yellin 1997, 61). Files in that format can be translated into the instructions specific to a particular computer processor by a Java Virtual Machine. One programmer can provide a class in the class file format to another programmer who will be able to instantiate that class and send messages to it using any compiler and Java Virtual Machine compliant with the Java Virtual Machine Specification.

Similarly, the Common Language Infrastructure Specification defines the Common Intermediate Language as a standard format for the output of compilers (ECMA International 2005). Files in that format can be translated into instructions to a particular computer processor by Microsoft’s Common Language Runtime, which is the core of Microsoft’s .NET technology, as well as by Mono.

Despite these ways of making classes written by one programmer reusable by others, the business of software was still restricted. The use of COM and .NET is widespread, as is the use of Java, and software developed using Java cannot be used together easily with software developed using COM or .NET. More importantly, the component-oriented style of software reuse that became prevalent after the introduction of COM, and which was also widely used by Java and .NET programmers, is grossly inefficient when the instance of the class that is being reused is remote, perhaps on another machine, or even just in a different process. It is so inefficient because, in that scenario, each operation of instantiating the object, of assigning values to its properties, and of calling its methods or handling its events, requires communication back and forth across process boundaries, and possibly also over the network.

Besides the extra work involved in marshalling data across the process boundaries,

The Web Services Description Language (WSDL) provided a general solution to the first restriction, the problem of using software developed using Java together with software developed using COM or .NET. WSDL provides a way of defining software interfaces using the Extensible Markup Language (XML), a format that is exceptionally widely adopted, and for which processors are readily available. Classes that implement WSDL interfaces are generally referred to as services.

Concomitantly, an alternative to component-oriented programming that is suitable for the reuse of remote instances of classes became progressively more common in practice, although writers seem to have had a remarkably difficult time formalizing its tenets. Thomas Erl, for instance, published two vast books ostensibly on the subject, but never managed to provide a noncircuitous definition of the approach in either of them (Erl 2004, 2005). That alternative to component-oriented programming is service-oriented programming.

Service-oriented programming is a style of software reuse in which the reusable classes are services—classes that implement WSDL interfaces—and the services are designed so as to minimize the number of calls to be made to them, by packaging the data to be transmitted back and forth into messages. A message is a particular kind of data transfer object. A data transfer object is

Messages are data transfer objects that consist of two parts: a header that provides information pertinent to the operation of transmitting the data and a body that contains the actual data to be transmitted. Crucially, the objects into which the content of a message is read on the receiving side are never assumed to be of the same type as the objects from which the content of the message was written on the sending side. Hence, the sender and the receiver of a message do not have to share the same types, and are said to be loosely coupled by their shared knowledge of the format of the message, rather than tightly coupled by their shared knowledge of the same types (Box 2004). By virtue of being loosely coupled, the sender and the receiver of the message can evolve independently of one another.

A definition of the term service-oriented architecture is warranted here for the sake of disambiguation. Service-oriented architecture is an approach to organizing the software of an enterprise by providing service facades for all of that software, and publishing the WSDL for those services in a central repository. The repository is typically a Universal Description Discovery and Integration (UDDI) registry. Having interfaces to all the software of an enterprise expressed in a standard format and catalogued in a central repository is desirable because then, in theory, its availability for reuse can be known. Also, policies defining requirements, capabilities, and sundry other properties of a service can be associated with the service using WSDL or by making suitable entries in the registry. That fact leads enterprise architects to anticipate the prospect of the registry serving as a central point of control through which they could issue decrees about how every software entity in their organization is to function by associating policies with the services that provide facades for all of their other software resources. Furthermore, measurements of the performance of the services can be published in the registry, too, so the registry could also serve as a monitoring locus.

Note that service-oriented architecture does not refer to the process of designing software that is to be composed from parts developed using service-oriented programming. There are at least two reasons why not. The first is simply because that is not how the term is actually used, and Ludwig Wittgenstein established in his Philosophical Investigations that the meaning of terms is indeed determined by how they are customarily used by a community (Wittgenstein 1958, 93). The second reason is that the community really could not use the term to refer to a process of designing software composed from parts developed using service-oriented programming because the process of doing that is in no way distinct from the process of designing software composed using parts developed in some other fashion. More precisely, the correct patterns to choose as guides in designing the solution would be the same regardless of whether or not the parts of the solution were developed using service-oriented programming.

Now, Microsoft provided support for service-oriented programming to COM programmers with the Microsoft SOAP Toolkit, and to .NET programmers with the classes in the System.Web.Services namespace of the .NET Framework Class Library. Additions to the latter were provided by the Web Services Enhancements for Microsoft .NET. Java programmers can use Apache Axis for service-oriented programming.

Yet service-oriented programming has been limited by the lack of standard ways of securing message transmissions, handling failures, and coordinating transactions. Standards have now been developed, and the Windows Communication Foundation provides implementations thereof.

So, the Windows Communication Foundation delivers a more complete infrastructure for service-oriented programming than was available to .NET software developers. Providing that infrastructure is important because service-oriented programming transcends limits on the reuse of software between Java programmers and COM and .NET programmers that had been hampering the software business.

Today, even with the Windows Communication Foundation, service-oriented programming is still suitable only for interactions with remote objects, just as component-oriented programming is suitable only for interacting with local objects. A future goal for the team that developed the Windows Communication Foundation is to extend the technology to allow the service-oriented style of programming to be equally efficient for both scenarios.

Even so, to understand the Windows Communication Foundation as merely being Microsoft’s once and future infrastructure for service-oriented programming severely underestimates its significance. The Windows Communication Foundation provides something far more useful than just another way of doing service-oriented programming. It provides a software factory template for software communication.

The concept of software factory templates is introduced by Jack Greenfield and Keith Short in their book Software Factories: Assembling Applications with Patterns, Models, Frameworks, and Tools (Greenfield and others 2004). It provides a new approach to model-driven software development.

The notion of model-driven software development has been popular for many years. It is the vision of being able to construct a model of a software solution from which the software itself can be generated after the model has been scrutinized to ensure that it covers all the functional and nonfunctional requirements. That vision has been pursued using general-purpose modeling languages, the Unified Modeling Language (UML) in particular.

A serious shortcoming in using general-purpose modeling languages for model-driven software development is that general-purpose modeling languages are inherently imprecise. They cannot represent the fine details of requirements that can be expressed in a natural language such as English. They also are not sufficiently precise to cover things such as memory management, thread synchronization, auditing, and exception management. If they were, they would be programming languages, rather than general-purpose modeling languages, yet memory management, thread synchronization, auditing, and exception management are precisely the sorts of things that bedevil programmers.

Greenfield and Short argue that progress in model-driven development depends on eschewing general-purpose modeling languages in favor of domain-specific languages, or DSLs. A DSL models the concepts found in a specific domain. DSLs should be used in conjunction with a corresponding class framework, a set of classes specifically designed to cover the same domain. Then, if the DSL is used to model particular ways in which those classes can be used, it should be possible to generate the software described in the model from the class framework (Greenfield and others 2004, 144).

The combination of a DSL and a corresponding class framework constitute the core of a software factory template (Greenfield and others 2004, 173). Software factory templates serve as the software production assets of a software factory from which many varieties of the same software product can be readily fabricated.

A fine example of a software factory template is the Windows Forms Designer in Microsoft Visual Studio .NET and subsequent versions of Microsoft Visual Studio. In that particular case, the Windows Forms Designer is the DSL, the Toolbox and Property Editor being among the terms of the language, and the classes in the System.Windows.Forms namespace of the .NET Framework Class Library constitute the class framework. Users of the Windows Forms Designer use it to model software that is generated from those classes.

Programmers have been using the Windows Forms Designer and tools like it in other integrated development environments for many years to develop software user interfaces. So, Greenfield and Short, in introducing the concept of software factory templates, are not proposing a new approach. Rather, they are formalizing one that has already proven to be very successful, and suggesting that it be used to develop other varieties of software besides user interfaces.

The Windows Communication Foundation is a software factory template for software communication. It consists of a DSL, called the Service Model, and a class framework, called the Channel Layer. The Service Model consists of the classes of the System.ServiceModel namespace, and an XML configuration language. The Channel Layer consists of the classes in the System.ServiceModel.Channel namespace. Developers model how a piece of software is to communicate using the Service Model, and the communication components they need to have included in their software are generated from the Channel Layer, in accordance with their model. Later, if they need to change or supplement how their software communicates, they make alterations to their model, and the modifications or additions to their software are generated. If they want to model a form of communication that is not already supported by the Channel Layer, they can build or buy a suitable channel to add to the Channel Layer, and proceed to generate their software as usual, just as a user of the Windows Forms Designer can build or buy controls to add to the Windows Forms Designer’s Toolbox.

That the Windows Communication Foundation provides a complete infrastructure for service-oriented programming is very nice because sometimes programmers do need to do that kind of programming, and service-oriented programming will likely remain popular for a while. However, software developers are always trying to get pieces of software to communicate, and they always will need to do that because software is reused by sending and receiving data, and the business of software depends on software reuse. So, the fact that the Windows Communication Foundation provides a software factory template for generating, modifying, and supplementing software communication facilities from a model is truly significant.

The key terms in the language of the Windows Communication Foundation Service Model correspond closely to the key terms of WSDL. In WSDL, a piece of software that can respond to communications over a network is called a service. A service is described in an XML document with three primary sections:

Thus, the three primary sections of a WSDL document tell you where a service is located, how to communicate with it, and what it will do.

Those three things are exactly what you specify in using the Windows Communication Foundation Service Model to model a service: where it is, how to communicate with it, and what it will do. Instead of calling those things service, binding, and portType, as they are called in the WSDL specification, they are named address, binding, and contract in the Windows Communication Foundation Service Model. Consequently, the handy abbreviation a, b, c can serve as a reminder of the key terms of the Windows Communication Foundation Service Model and, thereby, as a reminder of the steps to follow in using it to enable a piece of software to communicate.

More precisely, in the Windows Communication Foundation Service Model, a piece of software that responds to communications is a service. A service has one or more endpoints to which communications can be directed. An endpoint consists of an address, a binding, and a contract. How a service handles communications internally, behind the external surface defined by its endpoints, is determined by a family of control points called behaviors.

This chapter explains, in detail, how to use the Windows Communication Foundation Service Model to enable a piece of software to communicate. Lest the details provided obscure how simple this task is to accomplish, here is an overview of the steps involved.

A programmer begins by defining the contract. That simple task is begun by writing an interface in a .NET programming language:

public interface IEcho
{
    string Echo(string input);
}

It is completed by adding attributes from the Service Model that designate the interface as a Windows Communication Foundation contract, and one or more of its methods as being included in the contract:

[ServiceContract]
public interface IEcho
{
    [OperationContract]
    string Echo(string input);
}

The next step is to implement the contract, which is done simply by writing a class that implements the interface:

public class Service : IEcho
{
    public string Echo(string input)
    {
        return input;
    }
}

A class that implements an interface that is designated as a Windows Communication Foundation contract is called a service type. How the Windows Communication Foundation conveys data that has been received from the outside via an endpoint to the service type can be controlled by adding behaviors to the service type definition using the ServiceBehavior attribute:

[ServiceBehavior(ConcurrencyMode=ConcurrencyMode.Multiple)]
public class Service : IEcho
{
    public string Echo(string input)
    {
        return input;
    }
}

For example, the concurrency mode behavior attribute controls whether the Windows Communication Foundation can convey data to the service type on more than one concurrent thread. This behavior is set via an attribute because it is one that a programmer, as opposed to an administrator, should control. After all, it is the programmer of the service type who would know whether the service type is programmed in such a way as to accommodate concurrent access by multiple threads.

The final step for the programmer is to provide for hosting the service within an application domain. IIS can provide an application domain for hosting the service, and so can any .NET application. Hosting the service within an arbitrary .NET application is easily accomplished using the ServiceHost class provided by the Windows Communication Foundation Service Model:

using (ServiceHost host = new ServiceHost(typeof(Service))
{
    host.Open();

    Console.WriteLine("The service is ready.");
    Console.ReadKey(true);

    host.Close();
}

Now the administrator takes over. The administrator defines an endpoint for the service type by associating an address and a binding with the Windows Communication Foundation contracts that the service type implements. An editing tool, called the Service Configuration Editor, shown in Figure 2.1, that also includes wizards, is provided for that purpose.

Figure 2.1. Defining an address and a binding.

Whereas the programmer could use attributes to modify the behaviors that a programmer should control, the administrator, as shown in Figure 2.2, can use the Service Configuration Editor to modify the behaviors that are properly within an administrator’s purview. All output from the tool takes the form of a .NET application configuration file.

Figure 2.2. Adding behaviors to a service.

Now that the address, binding, and contract of an endpoint have been defined, the contract has been implemented, and a host for the service has been provided, the service can be made available for use. The administrator executes the host application. The Windows Communication Foundation examines the address, binding, and contract of the endpoint that have been specified in the language of the Service Model, as well as the behaviors, and generates the necessary components by which the service can receive and respond to communications from the Channel Layer.

One of the behaviors that the administrator can control is whether the service exposes WSDL to describe its endpoints for the outside world. If the administrator configures the service to do so, the Windows Communication Foundation will automatically generate the WSDL and offer it up in response to requests for it. A programmer developing an application to communicate with the service can download the WSDL, and generate code for exchanging data with the service, as well as an application configuration file with the endpoint information. That can be done with a single command

svcutil http://localhost:8000/EchoService?wsdl

wherein svcutil is the name of the Windows Communication Foundation’s Service Model Metadata Tool, and http://localhost:8000/EchoService?wsdl is the address from which the metadata of a service can be downloaded. Having employed the tool to produce the necessary code and configuration, the programmer can proceed to use them to communicate with the service:

using(EchoProxy echoProxy = new EchoProxy())
{
   echoProxy.Open();

   string response = echoProxy.Echo("Hello, World!");

   echoProxy.Close();
}

The preceding steps are all that is involved in using the Windows Communication Foundation. In summary, those simple steps are merely these:

At last, the promise of model-driven development might have actually yielded something tangible: a software factory template by which the communications system of an application can be manufactured from a model. The value of using this technology is at least threefold.

First, developers can use the same simple modeling language provided by the Service Model to develop solutions to all kinds of software communications problems. Until now, a .NET developer would typically use .NET web services to exchange data between a .NET application and a Java application, but use .NET Remoting for communication between two .NET applications, and the classes of the System.Messaging namespace to transmit data via a queue. The Windows Communication Foundation provides developers with a single, easy-to-use solution that works well for all of those scenarios. Because, as will be shown in Part V, “Extending the Windows Communication Foundation,” the variety of bindings and behaviors supported by the Windows Communication Foundation is indefinitely extensible, the technology will also work as a solution for any other software communication problem that is likely to occur. Consequently, the cost and risk involved in developing solutions to software communications problems decreases because rather than expertise in a different specialized technology being required for each case, the developers’ skill in using the Windows Communication Foundation is reusable in all of them.

Second, in many cases, the administrator is able to modify how the service communicates simply by modifying the binding, without the code having to be changed, and the administrator is thereby able to make the service communicate in a great variety of significantly different ways. The administrator can choose, for instance, to have the same service communicate with clients on the internal network they all share in a manner that is optimal for those clients, and can also have it communicate with Internet clients in a different manner that is suitable for them. When the service’s host executes again after any modifications the administrator has made to the binding, the Windows Communication Foundation generates the communications infrastructure for the new or modified endpoints. Thus, investments in software built using the Windows Communications Foundation yield increased returns by being adaptable to a variety of scenarios.

Third, as will be shown in Part VII, “The Lifecycle of Windows Communication Foundation Applications,” the Windows Communication Foundation provides a variety of powerful tools for managing applications built using the technology. Those tools reduce the cost of operations by saving the cost of having to develop custom management solutions, and by reducing the risk, frequency, duration, and cost of downtime.

The foregoing provides a brief overview of working with the Windows Communication Foundation Service Model. Read on for a much more detailed, step-by-step examination. That account starts right from the beginning, with building some software with which one might like other software to be able to communicate. To be precise, it starts with developing some software to calculate the value of derivatives.

<service name=
"DerivativesCalculator.DerivativesCalculatorServiceType">

TopNamespace.SubNameSpace.ContainingClass+NestedClass, MyAssembly,
Version=1.3.0.0, Culture=neutral, PublicKeyToken=b17a5c561934e089

<host>
        <baseAddresses>
                 <add baseAddress=
                 "http://localhost:8000/Derivatives/"/>
                 <add baseAddress=
                 "net.tcp://localhost:8010/Derivatives/"/>
        </baseAddresses>
</host>

<endpoint
        address="Calculator"
        binding="basicHttpBinding"
        contract=
"DerivativesCalculator.IDerivativesCalculator"
/>

IDerivativesCalculator.

binding="basicHttpBinding"

binding="basicHttpBinding"

<system.serviceModel>
    <services>
     <service type=
"DerivativesCalculator.DerivativesCalculatorServiceType">
       <endpoint
         address="Calculator"
         binding="basicHttpBinding"
         bindingConfiguration="bindingSettings"
         contract=
"DerivativesCalculator.IDerivativesCalculator"
       />
     </service>
    </services>
    <bindings>
     <basicHttpBinding>
       <binding name="bindingSettings" messageEncoding="Mtom"/>
     </basicHttpBinding>
    </bindings>
</system.serviceModel>

Using the Service

Now a Windows Communication Foundation service is available for accessing the facilities of the derivatives calculator class. The Windows Communication Foundation can be employed to construct a client for the derivatives calculator, a software entity that uses the facilities of the derivatives calculator via the service. Different ways to build the client with the Windows Communication Foundation are shown, as well as ways to build a client in Java for the same Windows Communication Foundation service.

Using the Service with a Windows Communication Foundation Client

For the following steps, access to the tools provided with the Windows Communication Foundation from a .NET command prompt will be required. Assuming a complete and normal installation of the Microsoft Windows SDK for the .NET Framework 3.0, that access is provided by a command prompt that should be accessible from the Windows Start menu by choosing All Programs, Microsoft Windows SDK, CMD Shell. That command prompt will be referred to as the SDK Command Prompt. From that prompt, the Windows Communication Foundation’s Service Metadata Tool, SvcUtil.exe, will be used to generate components of the client for the derivatives calculator:

1. If the Host console application had been shut down, start an instance of it, as before.

2. Open the SDK Command Prompt.

3. Enter

   C:
   

   and then

   cd c:WCFHandsOnFundamentalsDerivativesCalculatorSolution
   

   at that prompt to make the derivatives calculator solution folder the current directory.

4. Next, enter

   svcutil http://localhost:8000/Derivatives/ /out:Client.cs /config:app.config
   

   The output should be as shown in Figure 2.13.

   

   Figure 2.13. Using the Service Metadata Tool.

   The command executes the Windows Communication Foundation’s Service Metadata Tool, passing it a base address of a service that has the scheme http. In this case, it is passed the base address of the derivatives calculator service constructed by the earlier steps in this chapter. Given a base address of a Windows Communication Foundation service, provided it is an address with the scheme http, and provided metadata publishing via HTTP GET is enabled for the service, the Service Metadata Tool can retrieve the WSDL for the service and other associated metadata. By default, it also generates the C# code for a class that can serve as a proxy for communicating with the service, as well as a .NET application-specific configuration file containing the definition of the service’s endpoints. The switches /out:Client.cs and /config:app.config used in the foregoing command specify the names to be used for the file containing the C# code and for the configuration file. In the next few steps, the output from the Service Metadata Tool will be used to complete the client for the derivatives calculator.

5. Choose Debug, Stop Debugging from the Visual Studio 2005 menus to terminate the instance of the Host console application so that the solution can be modified.

6. Select File, New, Project from Visual Studio 2005 menus to add a C# Console Application project called Client to the DerivativesCalculator solution.

7. Choose Project, Add Reference from the Visual Studio 2005 menus, and add a reference to the Windows Communication Foundation’s System.ServiceModel .NET assembly to the client project.

8. Select Project, Add Existing Item from the Visual Studio 2005 menus, and add the files Client.cs and app.config, in the folder C:WCFHandsOnFundamentalsDerivativesCalculatorSolution, to the Client project, as shown in Figure 2.14. Those are the files that should have been emitted by the Service Metadata Tool.

   

   Figure 2.14. Adding output from the Service Metadata Tool to a project.

9. Alter the code in the Program.cs file of the Client project of the derivatives calculator solution to use the class generated by the Service Metadata Tool as a proxy for communicating with the derivatives calculator service. The code in the Program.cs file should be the code in Listing 2.5.

   Example 2.5. Using the Generated Client Class

   using System;
   using System.Collections.Generic;
   using System.Text;
   
   namespace Client
   {
       public class Program
       {
           public static void Main(string[] args)
           {
               Console.WriteLine("Press any key when the service is ready.");
               Console.ReadKey(true);
   
               decimal result = 0;
               using (DerivativesCalculatorProxy proxy =
                    new DerivativesCalculatorProxy(
                       "BasicHttpBinding_IDerivativesCalculator"))
               {
                    proxy.Open();
                    result = proxy.CalculateDerivative(
                        new string[] { "MSFT" },
                        new decimal[] { 3 },
                        new string[] { });
                    proxy.Close();
               }
               Console.WriteLine(string.Format("Result: {0}", result));
   
               Console.WriteLine("Press any key to exit.");
               Console.ReadKey(true);
   
           }
       }
   }
   

   In Listing 2.5, the statement

   DerivativesCalculatorProxy proxy =
                    new DerivativesCalculatorProxy(
                       "BasicHttpBinding_IDerivativesCalculator"))
   

   creates an instance of the class generated by the Service Metadata Tool to serve as a proxy for the derivatives calculator service. The string parameter passed to the constructor of the class, BasicHttpBinding_IDerivativesCalculator, identifies which definition of an endpoint in the application’s configuration file is the definition of the endpoint with which this instance of the class is to communicate. Therefore, an endpoint definition in the configuration file must be named accordingly.

   The app.config file added to the Client project in step 8 should contain this definition of an endpoint, with a specification of an address, a binding, and a contract:

   <client>
           <endpoint
                    address="http://localhost:8000/Derivatives/Calculator"
                    binding="basicHttpBinding"
                    bindingConfiguration="BasicHttpBinding_IDerivativesCalculator"
                    contract="IDerivativesCalculator"
                    name="BasicHttpBinding_IDerivativesCalculator" />
   </client>
   

   Notice that the name provided for this endpoint definition matches the name that is passed to the constructor of the proxy class.

   The binding configuration named BasicHttpBinding_IDerivativesCalculator to which this endpoint configuration refers, explicitly specifies the default values for the properties of the predefined BasicHttpBinding:

   <basicHttpBinding>
       <binding
           name="BasicHttpBinding_IDerivativesCalculator"
           closeTimeout="00:01:00"
           openTimeout="00:01:00"
           receiveTimeout="00:10:00"
           sendTimeout="00:01:00"
           allowCookies="false"
           bypassProxyOnLocal="false"
           hostNameComparisonMode="StrongWildcard"
           maxBufferSize="65536"
           maxBufferPoolSize="524288"
           maxReceivedMessageSize="65536"
           messageEncoding="Text"
           textEncoding="utf-8"
           transferMode="Buffered"
           useDefaultWebProxy="true">
           <readerQuotas
                            maxDepth="32"
                            maxStringContentLength="8192"
                            maxArrayLength="16384"
               maxBytesPerRead="4096"
               maxNameTableCharCount="16384" />
           <security mode="None">
               <transport
                                     clientCredentialType="None"
                                     proxyCredentialType="None"
                    realm="" />
               <message
                                     clientCredentialType="UserName"
                                     algorithmSuite="Default" />
           </security>
       </binding>
   </basicHttpBinding>
   

   Those default values were left implicit in the service’s configuration of the endpoint. The Service Metdata Tool diligently avoided the assumption that the configuration of the binding that it derived from the metadata is the default configuration.

10. Prepare to have the client use the derivatives calculator by modifying the startup project properties of the derivatives calculator solution as shown in Figure 2.15.

    

    Figure 2.15. Startup project properties of the derivatives calculator solution.

11. Choose Debug, Start Debugging from the Visual Studio 2005 menus.

12. When there is activity in the console for the Host application, enter a keystroke into the console for the Client application. The client should obtain an estimate of the value of a derivative from the derivatives calculator service, as shown in Figure 2.16. Note that the value shown in the Client application console might vary from the value shown in Figure 2.16 due to variations in prevailing market conditions over time.

    

    Figure 2.16. Using the derivatives calculator via a service.

13. In Visual Studio 2005, choose Debug, Stop Debugging from the menus.

Different Ways of Coding Windows Communication Clients

In the preceding steps for building a client for the derivatives calculator service, the code for the client was generated using the Windows Communication Foundation’s Service Metadata Tool. The generated code consists of a version of the IDerivativesProxy interface, and the code of a proxy class for communicating with the derivatives calculator service. The latter code is in Listing 2.6.

Example 2.6. Generated Proxy Class

[System.Diagnostics.DebuggerStepThroughAttribute()]
[System.CodeDom.Compiler.GeneratedCodeAttribute(
        "System.ServiceModel", "3.0.0.0")]
public partial class DerivativesCalculatorClient :
        System.ServiceModel.ClientBase<IDerivativesCalculator>,
        IDerivativesCalculator
{

    public DerivativesCalculatorClient()
    {
    }

    public DerivativesCalculatorClient(
                 string endpointConfigurationName) :
            base(endpointConfigurationName)
    {
    }

    public DerivativesCalculatorClient(
                 string endpointConfigurationName,
                 string remoteAddress) :
            base(endpointConfigurationName, remoteAddress)
    {
    }

    public DerivativesCalculatorClient(
                 string endpointConfigurationName,
                 System.ServiceModel.EndpointAddress remoteAddress) :
            base(endpointConfigurationName, remoteAddress)
    {
    }

    public DerivativesCalculatorClient(
                 System.ServiceModel.Channels.Binding binding,
                 System.ServiceModel.EndpointAddress remoteAddress) :
            base(binding, remoteAddress)
    {
    }

    public decimal CalculateDerivative(
                 string[] symbols,
                 decimal[] parameters,
                 string[] functions)
    {
        return base.Channel.CalculateDerivative(
                         symbols,
                         parameters,
                         functions);
    }
}

Naturally, one can write such a class instead of generating it with the Service Metadata Tool. To do so, one simply defines a class that inherits from the Windows Communication Foundation’s ClientBase<T> generic, and that implements the contract for the service:

  [ServiceContract]
public interface IDerivativesCalculator
{
     [OperationContract]
     decimal CalculateDerivative(
            string[] symbols,
            decimal[] parameters,
            string[] functions);
     ...
}

public partial class DerivativesCalculatorProxy :
     ClientBase<IDerivativesCalculator>,
     IDerivativesCalculator
{
     ...
}

Then, in the class’s implementations of the contract, one simply delegates to the methods of the Channel property of ClientBase<T>:

public partial class DerivativesCalculatorProxy :
    ClientBase<IDerivativesCalculator>,
    IDerivativesCalculator
{
    public decimal CalculateDerivative(string[] symbols,
        decimal[] parameters,
        string[] functions)
    {
        return base.Channel.CalculateDerivative(symbols,
            parameters,
            functions);
    }
}

This way of writing a Windows Communication Foundation client for the derivatives calculator service is one of at least three ways of doing so. The other way of writing a client for the service, given a definition of the IDerivativesCalculator contract, would simply be to write

IDerivativesCalculator proxy =
new ChannelFactory<IDerivativesCalculator>("BasicHttpBinding_IDerivativesCalcula-
tor").
      CreateChannel();
proxy.CalculateDerivative(...);
((IChannel)proxy).Close();

The ChannelFactory<T> generic is defined in the System.ServiceModel.Channels namespace. Whereas the first method for writing clients yields a reusable proxy class, this second method merely yields a proxy variable.

A third option for writing the client would be to program it in such a way that it downloads the metadata for the service and configures a proxy in accordance with that meta-data while executing. Listing 2.7 shows how to do that using the Windows Communication Foundation’s MetadataExchangeClient class. A MetadataExchangeClient object is provided with a location for the metadata for the derivatives calculator service, the same metadata shown earlier in Figure 2.12. Then the GetMetadata() method of the MetadataExchangeClient object is used to download that metadata, which is represented in the form of a MetadataSet object. A WsdlImporter object is constructed from that MetadataSet object. A collection of ServiceEndpoint objects that describe the service endpoints defined in the metadata is obtained using the WsdlImporter object’s ImportAllEndpoints() method. Each ServiceEndpoint object is used to configure a proxy variable that can then be used for communicating with the service.

Example 2.7. Retrieving Metadata Dynamically

using System;
using System.Collections.Generic;
using System.ServiceModel;
using System.ServiceModel.Channels;
using System.ServiceModel.Description;
using System.Text;

namespace Client
{
     class Program
     {
         static void Main(string[] args)
         {
             Console.WriteLine("Press any key when the service is ready.");
             Console.ReadKey(true);

             MetadataExchangeClient metadataExchangeClient =
                  new MetadataExchangeClient(
                  new Uri(
                      "http://localhost:8000/Derivatives/?wsdl"),
                  MetadataExchangeClientMode.HttpGet);

             MetadataSet metadataSet =
                  metadataExchangeClient.GetMetadata();
             WsdlImporter importer =
                  new WsdlImporter(metadataSet);
             ServiceEndpointCollection endpoints =
                  importer.ImportAllEndpoints();
             IDerivativesCalculator proxy = null;
             foreach (ServiceEndpoint endpoint in endpoints)
             {
                  proxy = new ChannelFactory<IDerivativesCalculator>(
                      endpoint.Binding, endpoint.Address).CreateChannel();
                  ((IChannel)proxy).Open();
                  Console.WriteLine(proxy.CalculateDerivative(
                      new string[] { "MSFT" },
                      new decimal[] { 3 },
                      new string[] { }));
                  ((IChannel)proxy).Close();
             }
             Console.WriteLine("Press any key to exit.");
             Console.ReadKey(true);
         }
     }
}

Using the Service with a Java Client

The service by which the facilities of the derivatives calculator class are made available for use by other software entities, is configured to use the Windows Communication Foundation’s predefined BasicProfileBinding. That binding conforms to the WS-I Basic Profile Specification 1.1. Therefore, the service can be used not only by clients built using the Windows Communication Foundation, but by any clients that can consume services that comply with that specification.

The Apache Foundation provides a web services development toolkit for Java programmers called Axis. Axis incorporates a tool called WSDL2Java, which, like the Windows Communication Foundation’s Service Metadata Tool, will download the WSDL for a service and generate the code of a class that can be used as a proxy for the service. Whereas the Windows Communication Foundation’s Service Metadata Tool can generate code in the C#, Visual Basic .NET, VBScript, JScript, JavaScript, Visual J#, and C++ programming languages, the WSDL2Java tool generates code only in the Java programming language.

You can download Axis from http://ws.apache.org/axis/. After it has been installed correctly, and the Host console application of the derivatives calculator solution is running, one can issue this command from a command prompt:

java org.apache.axis.wsdl.WSDL2Java http://localhost/Derivatives/?wsdl

That command should cause WSDL2Java to download the WSDL for the Windows Communication Foundation derivatives calculator service and generate Java code for accessing the service.

The quantity of that code will be much larger than the quantity of code emitted by the Windows Communication Foundation’s Service Metadata Tool. The code for a proxy class for the derivatives calculator service generated by the WSDL2Java tool is 18KB in size, whereas the code for a proxy class for the same service emitted by the Windows Communication Foundation’s tool is about 3KB in size.

Given the code emitted by the WSDL2Java tool, one can write a Java application to use the derivatives calculator service. The code for such an application is in Listing 2.8. Figure 2.17 shows the application executing within the Eclipse 3.1 development environment, which is available from http://eclipse.org/downloads/.

Example 2.8. WSDL2Java Proxy

import org.tempuri.*;
import java.math.*;

public class Client
{
    public static void main(String[] arguments)
    {
        try
        {
            String[] symbols = new String[1];
            symbols[0] = "MSFT";

            BigDecimal[] parameters = new BigDecimal[1];
            parameters[0] = new BigDecimal(3);

            String[] functions = new String[1];
            functions[0] = "TechStockProjections";

            DerivativesCalculatorServiceTypeLocator locator =
                 new DerivativesCalculatorServiceTypeLocator();
            IDerivativesCalculator stub =
                 locator.getBasicHttpBinding_IDerivativesCalculator_port();
            BigDecimal[] values = new BigDecimal[1];
            values[0] = stub.calculateDerivative(symbols,parameters,functions);


            System.out.println(String.format("Result: %f", values));
        }
        catch(Exception e)
        {
            System.out.println("Error: " + e.getMessage());
        }

        try
        {
            System.in.read();
        }
        catch(Exception e)
        {
        }
    }
}

Figure 2.17. Using the derivatives calculator service using a Java Client.

<%@ServiceHost Service="DerivativesCalculator.DerivativesCalculatorServiceType" %>

<system.web>
        <compilation>
                 <compilation debug="true">
                         <buildProviders>
                                  <remove extension=".asmx"/>
                                  <add extension=".asmx"
                                     type="System.ServiceModel.ServiceBuildProvider,
                                     System.ServiceModel,
                                     Version= 3.0.0.0,
                                     Culture=neutral,
                                     PublicKeyToken= b77a5c561934e089" />
                         </buildProviders>
                 </compilation>
        </compilation>
</system.web>

The Windows Communication Foundation provides a software factory template for software communication, consisting of a modeling language called the Service Model, and a programming framework called the Channel Layer. The Service Model incorporates a class library and a configuration language by which services are described simply as collections of endpoints defined by an address, a binding, and a contract. Descriptions of software communication solutions expressed in the language of the Service Model are used as input for generating the components of the solution from the lower-level class library that is the Channel Layer. Using the software factory template for communication among applications that the Windows Communication Foundation provides, one can quickly adapt code to new scenarios. For instance, as demonstrated in the foregoing, one can host the same service within a .NET console application or within IIS without modifying the code for the service at all. One can also easily change how a client and a service communicate, making the communication between them confidential, for example. Being able to adapt software to diverse scenarios with little effort has always been the promise of model-driven development. With the Windows Communication Foundation, that promise is realized for software communications.