Exam Objectives
Create and configure bindings for WCF services (Azure SDK—extensions to WCF); relay bindings to Azure using service bus endpoints; integrate with the Azure service bus relay; host services in Azure (from 3.9);Quick Overview of Training Materials
Exam Ref 70-487 - Chapter 3.7
[MSDN] How to use Azure Relay WCF relays with .NET
[MSDN] Azure WCF Relay tutorial
[MSDN] What is Azure Relay?
[Blog] Azure WCF Web role over http with wshttpbinding
[MSDN] How to use Azure Relay WCF relays with .NET
[MSDN] Azure WCF Relay tutorial
[MSDN] What is Azure Relay?
[Blog] Azure WCF Web role over http with wshttpbinding
[PluralSight] WCF Power Topics - Working with the Azure Service Bus
[Blog] Deploying A WCF Service On Windows Azure
[Blog] Deploying an Existing WCF Service to Azure
My post on Messaging Patterns
[Blog] Deploying A WCF Service On Windows Azure
[Blog] Deploying an Existing WCF Service to Azure
My post on Messaging Patterns
Create and Configure Relay Bindings
The relay bindings are included in the WindowsAzure.ServiceBus NuGet package... the older one with 6+ million downloads, not the other one...
Adding this NuGet package will add a huge section of extensions to the config file in the system.serviceHost element, but it notes that most of it can probably be removed. It does list out all the additional relay bindings that are included:
The endpoint itself doesn't look all that different, just using the different binding, as well as a behavior configuration:
I lifted the behavior config section straight from the How to use Azure Relay article (which I would guess is probably exactly what the Exam Ref does too lol):
Don't worry, I've long since regenerated the key. Beyond that, the bindings and the services that use them are just plain old WCF services. One point to note, there are no relay metadata bindings, so as far as I can tell, if you want to generate a client using "Add Service Reference", you need a mex endpoint exposed directly on the service. The demos I found online all use the ChannelFactory<T> class directly, which is also an option.
Adding this NuGet package will add a huge section of extensions to the config file in the system.serviceHost element, but it notes that most of it can probably be removed. It does list out all the additional relay bindings that are included:
- basicHttpRelayBinding - communicate with ASMX based web services
- webHttpRelayBinding - relay non-SOAP based HTTP requests
- ws2007HttpRelayBinding - updated versions of Security, ReliableSession, and Transactions
- wsHttpRelayBinding - analogous to wsHttpBinding
- netTcpRelayBinding - communication with service over TCP
- netOnewayRelayBinding - secure, one-way connection
- netEventRelayBinding - supports one-way event multicasting (many-many pub/sub)
- netMessagingBinding - used for net messaging (Service Bus Queue).
The endpoint itself doesn't look all that different, just using the different binding, as well as a behavior configuration:
<endpoint address="sb://failedturing.servicebus.windows.net/echo" binding="netTcpRelayBinding" contract="EchoServiceReference.IEchoService" behaviorConfiguration="sbTokenProvider" name="NetTcpRelayBinding_IEchoService" />
I lifted the behavior config section straight from the How to use Azure Relay article (which I would guess is probably exactly what the Exam Ref does too lol):
<behaviors> <endpointBehaviors> <behavior name="sbTokenProvider"> <transportClientEndpointBehavior> <tokenProvider> <sharedAccessSignature keyName="RootManageSharedAccessKey" key="5RVHWGAD3ZL5HkUugxGde0dVjEXSnWCExNjD2BiLBMs="/> </tokenProvider> </transportClientEndpointBehavior> </behavior> </endpointBehaviors> </behaviors>
Don't worry, I've long since regenerated the key. Beyond that, the bindings and the services that use them are just plain old WCF services. One point to note, there are no relay metadata bindings, so as far as I can tell, if you want to generate a client using "Add Service Reference", you need a mex endpoint exposed directly on the service. The demos I found online all use the ChannelFactory<T> class directly, which is also an option.
Integrate with Service Bus Relay
In order to use the Service Bus Relay, you need to create a new Service Bus Namespace in the Azure Portal. While this is super simple, and covered in the How To article referenced above, I'll include it anyway. The first step is to find the "Service Bus" resource in the portal. Under "More services", it's in the "Enterprise Integration" category:
Add a new service bus, give it a globally unique name, set pricing and resource groups, and click "Create":
The service took a few minutes to be created when I ran it, but YMMV. Once the service is created, you'll need the access key that was referenced in the configuration examples above. This is in "Settings => Shared access policies => RootManageSharedAccessKey":
Under the "...More" menu, you have the option of regenerating the Primary and Secondary keys... useful when you keep posting them online on your blog =P.
That done, it's just a matter of running the service and client, which both are configured to talk to the Service Bus:
In my sample code (available on GitHub), I call the service directly over tcp 10 times first, and then 10 times through the relay. The result was that going over the relay was nearly 100 times slower. To be fair, Tcp on the same machine is going to be blazing fast, but even still, it would be something to take into consideration if you were considering using the service in the real world.
Hosting Services In Azure
While this objective is technically part of "Hosting a Service", putting it here seemed like a good fit. The topic is very cohesive, and the hosting post was getting ridonkulous. It really is a much more natural fit here. The "Deploying A WCF Service On Windows Azure" post by Claudio Bernasconi really covers the basics, so I'm pretty much just going to follow along with his example.
The first step is to create an "Azure Cloud Service" project:
Then create a "WCF Service Web Role":
Because I've create the EchoService about a dozen times already, I'm going to skip the part where I create a toy service to deploy, and instead use the default service interface and implementation (I've beat that horse to death several times over). Deploying the project to Azure is literally two clicks:
I did notice that it sort of arbitrarily picked an existing service to deploy into... whoops. This is because I skipped a step. Should have created a publish profile first, then published. Select the "Cloud Service" project, and under the Build top level menu, select "Publish AzureCloudService" or whatever you named your cloud service:
So as to avoid unnecessary charges to my Azure subscription, I went into the portal and deleted the first service:
So now I have my WCF Web Service running at http://failedturing.cloudapp.net/Service1.svc, time to try it out. So I create my billionth console client, "Add Service Reference":
That done, the client application looks like all the other toy client demos I've built. If you are interested, they are littered all over my WCF Examples repo.
No comments:
Post a Comment