Background

Dealing with something as an integrated whole is self-evidently easier than having to understand and manipulate all of it 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 members, symbol, number, price, and value, as well as the method SetTotal(), while exposing 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). One can write, in C++, the code given in Listing 2.1.

Listing 2.1. Abstract Base Class

//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.

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.

The Web Services Description Language (WSDL) overcomes that restriction by providing 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. Writing classes that implement WSDL interfaces is generally referred to as service-oriented programming.

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.

However, this way of understanding the Windows Communication Foundation severely underestimates its significance. The Windows Communication Foundation provides something far more useful than service-oriented programmingnamely, 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 natural languages like 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 gets 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.