Microsoft’s field personnel often express interest in hearing about how to manage the lifecycle of a service and, in particular, how to deal with the changes that will inevitably need to be made to services over time. The reason for their interest is that their customers are seeking guidance on the matter. Unfortunately, the literature on service-oriented programming, including the first edition of this book, neglects to pay any attention to the topic. One book that devotes a few paragraphs to the subject is Service-Oriented Architecture Compass: Business Value, Planning, and Enterprise Roadmap, by Norbert Bieberstein and others (Bieberstein and others 2006, 39). The brief discussion there refers to the most useful contribution on the subject of service version management hitherto: the article, Best Practices for Web services versioning by Kyle Brown and Michael Ellis (Brown and Ellis 2004). They make an observation that might well explain why so little has been written about versioning services when so much has been written about building them:

The Windows Communication Foundation actually does have some versioning facilities. This chapter will cover those mechanisms, of course. However, its main purpose is to remedy the shortage of guidance on managing the versioning of services. The chapter aims to do so by using the language the Windows Communication Foundation provides for modeling services, to yield a logically complete set of versioning problems, with the solutions to each one of them.

The challenge in managing modifications to a service over time is to limit the cost the changes incur. The obvious way of accomplishing that is to avoid having to change any existing client applications as a consequence of changing the service.

Brown and Ellis refer to changes to services that would not require changes to existing clients as backwards-compatible changes, and changes to services that would require changes to existing clients as non-backwards-compatible changes (Brown and Ellis 2004). The same nomenclature will be used here.

A versioning decision tree is presented in Figure 20.1. It depicts all of the logically possible ways in which one might have to modify a service, how to implement each change, and what the consequences will be.

Figure 20.1. Versioning decision tree.

The diamonds represent alternative ways in which a service might have to change. The rectangles and the circle represent procedures for implementing changes. The procedures represented by the rectangles yield backwards-compatible changes, whereas the procedure represented by the circle results in a non-backwards-compatible change.

Thus, the versioning decision tree provides two interesting insights at a glance. The first is that there is exactly one thing one might do that would result in a non-backwards-compatible change. The second is that one can have considerable leeway to modify one’s services while still avoiding that outcome.

Trace the routes through the decision tree now to understand the implications of each alternative. Start by imagining that there is a service that has to be modified.

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

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

[ServiceContract]
public interface IExtendedEcho: IEcho
{
    [OperationContract]
    string[] ExtendedEcho(string[] inputs);

public class Service : IEcho, IExtendedEcho
{
    public string Echo(string input)
    {
        return input;
    }
    public string[] ExtendedEcho(string[] input)
    {
        return input;
    }

<endpoint
        address="Echo"
        binding="basicHttpBinding"
        contract="IEcho"
/>

<endpoint
        address="Echo"
        binding="basicHttpBinding"
        contract="IExtendedEcho"
/>

[DataContract]
public class DerivativesCalculation
{
     [DataMember(IsRequired=true)]
     public string[] Symbols;
     [DataMember(IsRequired=true)]
     public decimal[] Parameters;
     [DataMember(IsRequired=true)]
     public string[] Functions;
     public DataTime Date
}

[DataContract]
public class DerivativesCalculation
{
     [DataMember(IsRequired=true)]
     public string[] Symbols;
     [DataMember(IsRequired=true)]
     public decimal[] Parameters;
     [DataMember(IsRequired=true)]
     public string[] Functions;
     public DataTime Date
     [DataMember(IsRequired=false)]
     public decimal LastValue;
}

[DataContract]
public class DerivativesCalculation: IExtensibleDataObject
{
        [DataMember(IsRequired=true)]
        public string[] Symbols;
        [DataMember(IsRequired=true)]
        public decimal[] Parameters;
        [DataMember(IsRequired=true)]
        public string[] Functions;
        public DataTime Date

        private ExtensionDataObject unknownData = null;

        public ExtensionDataObject ExtensionData
        {
                get
                {
                        return this.extensionData;
                }

                set
                {
                        this.extensionData = value;
                }
        }
}

namespace Fabrikam.Derivatives
{
        [DataContract(
                Namespace="http://www.fabrikam.com/derivatives/v1.0.0.0",
                Name="DerivativesCalculation")]
        public class DerivativesCalculation
        {
                [DataMember(IsRequired=true)]
                public string[] Symbols;
                [DataMember(IsRequired=true)]
                public decimal[] Parameters;
                [DataMember(IsRequired=true)]
                public string[] Functions;
                public DataTime Date
        }
}

namespace Fabrikam.Derivatives
{
        [DataContract(
                Namespace="http://www.fabrikam.com/derivatives/v2.0.0.0",
                Name="DerivativesCalculation")]
        public class SimplifiedDerivativesCalculation
        {
                [DataMember(IsRequired=true)]
                public string[] Symbols;
                [DataMember(IsRequired=true)]
                public decimal[] Parameters;
                public DataTime Date
        }
}

[DataContract]
public class RetiredEndpointFault
{
        [DataMember]
        public string NewEndpointMetadataLocation;
}

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

In Chapter 2, service-oriented architecture was defined as 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. Among the perceived virtues of that approach is the prospect of centralized lifecycle management. Specifically, proponents of service-oriented architecture anticipate the registry serving as a central point of control through which system administrators could determine how the software entities in their organizations function by associating policies with the services that provide facades for all of the other software resources.

For that prospect to be realized, it would be necessary for services to monitor the registry for changes in policy applicable to them, and then automatically reconfigure themselves in accordance with those policies. As remarkable as that might sound, the Windows Communication Foundation actually can be made to reconfigure itself according to stipulated policies.

A policy, in the sense in which that term is being used here, refers to a collection of policy assertions, and a policy assertion is a nonfunctional requirement of a service endpoint (Weerawarana and others 2005, 128). WS-Policy provides an interoperable, standard way of expressing policies.

Because policies define the nonfunctional requirements of a service endpoint, they pertain to the binding of the endpoint, in Windows Communication Foundation terms, rather than to the contract, which defines the functional characteristics. So, for Windows Communication Foundation applications to be able to configure themselves in accordance with policies retrieved from a registry, they would have to be able to convert policies into bindings. They can. Follow these steps to learn how.

In this case, the stream of metadata from which the Windows Communication Foundation’s System.ServiceModel.WsdlImporter retrieved a collection of bindings included policies, and those policies consisted of standard policy assertions defined by the WS-SecurityPolicy specification. The System.ServiceModel.WsdlImporter has the facilities for understanding such standard policy assertions and configuring bindings accordingly. However, the WS-Policy language allows one to formulate an unlimited variety of policy assertions, and the System.ServiceModel.WsdlImporter is naturally not inherently capable of understanding every policy assertion one might devise. One can readily extend its capabilities to understand any given policy assertion, though. To do so, one creates a type that implements the System.ServiceModel.Description.IPolicyImportExtension interface that can read the policy assertion and apply it to a binding, and then one adds an instance of that type to the System.ServiceModel.WsdlImporter object’s PolicyImportExtensions collection.

It should be apparent, then, that the Windows Communication Foundation does allow services to reconfigure themselves in accordance with stipulated policies. However, while the notion of services being able to do this has some currency, it is ill-advised. It has already been explained that having a service reconfigure itself to conform to new policies means having the service change its binding. The versioning decision tree showed that the least costly way to implement a change to a binding is to expose a new endpoint with the modified binding, and to avoid the option of retiring the old endpoint. However, when a service reconfigures its binding to conform to a new policy, the existing endpoint is changed, and any clients that used that endpoint will very likely no longer be able to do so until they are reconfigured as well. Chapter 2 already showed that Windows Communication Foundation clients can configure themselves dynamically from updated binding information that they could retrieve from the metadata of the modified service, but one must consider how many potential points of failure this scenario incorporates.

This chapter provided a versioning decision tree that depicts all the logically possible ways in which one might have to modify a service, how to implement each change, and what the consequences will be. The tree shows that one has considerable leeway to modify a service without incurring the cost of having to update all its clients.