Tải bản đầy đủ
Objective 3.6: Version a WCF Service

Objective 3.6: Version a WCF Service

Tải bản đầy đủ

change. Make sure that you understand this difference (which is fortunately one you could
guess at and get right 99 percent of the time).

Contract versioning
Changes to a contract can include the following:
■■

Addition or removal of an operation

■■

Modification of an operation

■■

Behaviors of the contract changing

■■

Components of the contract changing

■■

Elements in the message changing

The contracts used by each party in the communication process do not need to be exactly
the same or identical matches; instead, they simply need to be compatible. Say for illustration
that Vendor A has a service with Method1, Method2, and Method3. As of right now, every
single client has a contract for that service that includes Method1, Method2, and Method3.
Without touching or affecting those methods, let’s say the vendor adds Method4,
Method5, and Method6. Right now, the contracts the consumers have are not identical to
those that the vendor is providing, but they are compatible. That’s ultimately what matters.
Say that, instead of adding the three methods, the vendor opts to add a new overload to
each of the first three methods. Both vendor and client have a contract that has Method1,
Method2, and Method3, but they are absolutely not compatible. The first case could be rolled
out without any problem (the worst that could happen is that a client might notice the new
methods and ask if they were ready for use or try to use one of the methods on their own,
which might not be ready for use). In the second case, unless the consumers were aware of
the changes in advance and had already modified their clients to deal with the change, there
would be major problems and disruption.
Using the same concept and knowing that data contracts (just like service contracts)
need only be compatible, what do you think might break compatibility? The addition of
some new types? The modification of an existing DataContract? The removal of an existing
DataContract?
The first scenario, adding a type, would present no problems; the latter two absolutely
would because changes to the interface will cause compilation to fail. Now that you have covered breaking and nonbreaking change with respect to each service component, you need to
understand versioning strategy concepts: strict versioning and lax versioning.

Strict versioning
The more clients you have, the more damage versioning issues they can potentially cause,
and the less control you have over the response. If you have one client, you might be able to
offer them a discount for the inconvenience they encounter. You can offer them a free update
to their client that they accept. But even with just one customer, they might say “no” and not
tolerate it. The more clients you have, though, the more likely it is that you will run into one
that has serious issues with version changes.


Objective 3.6: Version a WCF service

CHAPTER 3

245

To make sure that you don’t cause any problems, you must ensure that any newly generated messages from your updated service validate against the old schema. The safest way to
have this assurance is to never change existing contracts and just create new contracts, ideally
ones with new and assuredly distinct XML namespaces.

Lax versioning
WCF and even .asmx web services have support for lax versioning. Lax versioning means that
minor changes can often be made without breaking the existing contract. It’s possible, for
example, that you can add a new member and the data will just be ignored.

Configuring address, binding, and routing service
versioning
Changes to an address move from one host to another. Clustering and load balancing all have
the possible result of an address change. Ideally, the service is deployed in such a manner
that initially that changes of this type can be done transparently without the user even being
aware that the change happened, but sometimes that’s not possible.
When configuring bindings, they are either added or removed. You might start out just using the basicHttpBinding and find that you need functionality provided by the wsHttpBinding
or another binding. You might add features that necessitate behavior that isn’t supported by
your existing bindings.
Implementation changes might involve using one gateway to process payments and
changes to a new gateway that needs different information returns different information. You
might have to change the implementation to add caching or include some other optimizations. Implementation changes are almost a certain part of deploying services.

Thought experiment
How should you handle version upgrades?
In the following thought experiment, apply what you’ve learned about this objective to version a WCF Service. You can find answers to these questions in the “Answers” section at the end of this chapter.
You are building several WCF Services. You have to get the service out immediately,
but there’s strong reason to believe you’re going to have to quickly implement
many new features and additional versions.
With this in mind, answer the following questions:

1. How can you avoid breaking changes?
2. If you have breaking changes that you are forced to implement, how would you
handle them?

246

CHAPTER 3

Designing and implementing WCF Services

Objective summary
■■

WCF enables several different aspects of the service to be versioned.

■■

Modifications fall into two primary categories: breaking and nonbreaking.

■■

Breaking changes are extremely problematic, and although sometimes unavoidable,
great care should be taken to minimize their existence and impact.

Objective review
Answer the following questions to test your knowledge of the information in this objective.
You can find the answers to these questions and explanations of why each answer choice is
correct or incorrect in the “Answers” section at the end of this chapter.
1. Version 10 of the TestService (which implements the ITestService interface) is about

to be updated and deployed. The ITestService interface adds two new methods,
both of which are scoped with the public modifier and are decorated with the
OperationContract attribute. Which of the following is true?
A. The two additions will be considered breaking changes unless each assembly

includes the correct version number.
B. The two additions will not be breaking changes because they leave all previous

functionality in place and just add new functionality.
C. As long as the service and contract pairs are both deployed with their respective

version numbers (versions 10, 11), clients will not encounter any problems.
D. Answers B and C.
2. Version 10 of the TestService assembly (which also includes the ITestService interface

and implements it) adds two new methods to the interface definition. The new methods use the Protected modifier and do not currently contain the OperationContract attribute (on either the interface or the implementation). Which of the following is true?
A. There will not be breaking changes on any items that statically link to the assembly.
B. There will not be breaking changes because the access modifiers are set to

Protected.
C. There will not break changes because they don’t implement the OperationContract

attribute.
D. It will be a breaking change to any assembly statically linked to it unless the new

methods are also added to the implementation.



Objective 3.6: Version a WCF service

CHAPTER 3

247

3. Which versioning strategies are supported through WCF?
A. Strict Versioning
B. Lax Versioning
C. Mixed-Mode Versioning
D. Contract Versioning
NOTE  MINIMIZING VERSIONING PROBLEMS

To minimize the impact of versioning, make sure that you publicize any changes well
in advance; the longer the notice period, the better. Make sure that you document the
changes and their known impact as comprehensively as possible. You can’t possibly anticipate every possible downstream side-effect, but you can predict many, particularly if you
test in as many environments as you feasibly can (particularly ones that you know highuse clients have). Communicate throughout the process, and let clients provide feedback.
Many government regulations, for example, involve a “cooling off,” or “feedback” period
in which they accept feedback about the impact (positive and negative) that the change
might cause. You might not be able to accommodate every request, but each one you can
accommodate, even partially, minimizes the impact of the change and deflates the charge
that the change was forced upon them. Make several reminder announcements as the time
period closes on deployment. Have contingency plans and brainstorm about what can go
wrong in advance. Test as much as possible, particularly with alpha and beta releases, and
welcome users to participate.
Finally, after the change is deployed, make sure that you have adequate support staff to
handle the influx of communication you’ll likely receive. Much of the communication will
be questions you already answered several times. Much will be from those looking for
assurances. Much will be complaints or problems (some of which might have nothing to
do with your change, but you get to temporarily take the blame because you’re the easiest target). And always remember to do as much as possible to consider things from your
client’s perspective. This might sound like something from a motivational speaker’s book
instead of a technical one; however, if you win the hearts and minds of your users and
convince them that you’ve done your due diligence, changes are much more likely to be
viewed as necessary and problems as costs of doing business. Keep quiet about everything,
leave customers out of the loop, and do things in a manner that looks disorganized, and
you can bank on a bunch of problems, animosity, and finger pointing. You’ll often get that
even when you do everything right, so make sure that you limit the surface area as much as
you can.

248

CHAPTER 3

Designing and implementing WCF Services

Objective 3.7: Create and configure a WCF service on
Windows Azure
Running applications in Azure gives you and your customers a lot of advantages. However,
not all customers are willing to deploy their applications to a public cloud. Some have concerns regarding the security of their data or they have local regulations that don’t allow them
to use the public cloud.
Instead of giving in to those problems and deploying your application as a typical on
premise application, you can also choose a hybrid scenario. This means that you create an application that spans both the public cloud and on-premise servers that are under your control.
Connecting these types of applications is the topic of this objective. Azure provides a technology called Service Bus Relay to do this. Relaying is used to expose services hosted in your
own datacenter to the outside world in a secure way.
The term service bus is something that doesn’t exist only in Azure. Products such as BizTalk
also expose service bus functionality. The primary goal is to be a bridge between different
applications. The unique point of Azure Service Bus, however, is the capability to not only
connect different applications, but to also connect applications on premise and in the cloud
in a hybrid fashion. By using Azure Service Bus, you avoid the installation and configuration
that typical on-premise service bus products normally need, and you gain all the scalability
and availability advantages Azure offers you.

This objective covers how to:
■■

Create and configure bindings for WCF services

■■

Relay bindings to Azure using service bus endpoints

■■

Integrate with the Azure service bus relay

Creating and configuring bindings for WCF services
As you know, WCF is all about ABC: Address, Binding and Contract. When deploying a regular
WCF service to Azure you don’t have to make any changes and you can just deploy your
service to a Web Role or Web Site.
When using the relay feature of the service bus, you can install some additional bindings
into your project. The easiest way to do this is by using NuGet.



Objective 3.7: Create and configure a WCF service on Windows Azure

CHAPTER 3

249

MORE INFO  NUGET

For more information on NuGet, see Chapter 5’s objective “Manage packages by using
NuGet.”

The NuGet package Windows Azure Service Bus contains all the assemblies you need to set
up your WCF service for relaying. Take the following service as an example:
[ServiceContract(Namespace = "urn:ps")]
interface ISecretService
{
[OperationContract]
string GetSecretData(int d);
}
interface ISecretServiceChannel : ISecretService, IClientChannel { }

The implementation of this class is simple, but you can imagine using your own, more
complex WCF services here:
class SecretService : ISecretService
{
public string GetSecretData(int d)
{
return string.Format("You passed: {0}", d);
}
}

Now that you have your WCF service, you need to host it just as you would with any other
WCF service. The benefit with using the service bus functionality is that it complements your
already existing WCF bindings. This means that you can expose internal endpoints for your
service that can be used to integrate with on-premise applications and that you can expose
special endpoints to connect to the service bus. To host your service, you create an instance
of a ServiceHost, define your endpoints, and then open your server:
ServiceHost sh = new ServiceHost(typeof(SecretService));
sh.AddServiceEndpoint(
typeof(ISecretService), new NetTcpBinding(),
"net.tcp://localhost:9358/secretservice");
sh.AddServiceEndpoint(
typeof(ISecretService), new NetTcpRelayBinding(),
ServiceBusEnvironment.CreateServiceUri("sb", "wcfonazure", "secretservice"))
.Behaviors.Add(new TransportClientEndpointBehavior
{
TokenProvider = TokenProvider.CreateSharedSecretTokenProvider(
"owner",
"D1Kmb83CCLrAtz4du9vb3xn99DaM2dH4jQqSec98if4=")
});
sh.Open();

250

CHAPTER 3

Designing and implementing WCF Services