Almost all of the magic of
the Service Bus is embedded in the new WCF service bindings that are
shipped in the AppFabric SDK. All of these bindings start with a
protocol identifier of sb (you’re probably familiar with http and others). The binding names also almost always have the word relay in them, to indicate that you’ll be relaying messages through the Service Bus to their destination.
1. Connecting the service to the bus
Changing your application to
listen for messages from the bus instead of the HTTP endpoint is easy.
You need to change the binding and address information to point to the
bus.
We’ve moved the configuration of
the service from code to the app.config file to make these changes
easier, and you can see these changes in the Service Bus sample code for
this article. Two things still need to be set up. You need to configure
the address and binding information, and you need to configure the
service for authentication to the bus.
First, in the
configuration, you need to change the address of the endpoint to your
namespace on the bus. For this example, you should change it from
http://localhost/processstring to
sb://stringreversalinc.servicebus.windows.net/processtring. This change
tells WCF to use the Service Bus relay bindings, and that the service
you’re publishing should be registered in the stringreversalinc namespace.
<endpoint address=
"sb://stringreversalinc.servicebus.windows.net/processtring"
behaviorConfiguration="sharedSecretClientCredentials"
binding="netTcpRelayBinding"
contract="StringReversalLibrary.Contract.IReverseString" />
Your service also has to
authenticate to the Service Bus when it starts up and registers with the
bus. You use ACS to do this. In this example, you can use the simple
shared secret we used . This will attach the
credentials (essentially a username and password) to your request to
connect to the Service Bus:
<behavior name="sharedSecretClientCredentials">
<transportClientEndpointBehavior credentialType="SharedSecret">
<clientCredentials>
<sharedSecret issuerName="owner" issuerSecret="MZuYNde3ZOzUJxVKo62kmWoFSlzEZEaKai5Fktlt3pQ=" />
</clientCredentials>
</transportClientEndpointBehavior>
</behavior>
This shared secret behavior
that you attach to your service will authenticate to the bus with your
issuer name and signing key automatically.
Once
you make these changes, you can run the service and it’ll start up,
authenticate, and start listening for messages coming from the bus.
You’ll then need to perform similar actions on the client.
2. Connecting to the service
In the previous section, we
looked at what you had to do to connect a service to the Service Bus.
You had to change the bindings to point to the bus and update the
address. You also had to add some authentication so that the bus knew
you were allowed to use your namespace.
You now need to follow the
same steps to change the app.config for the client. You need to change
the client binding so it’s sending messages to the bus. For this
example, you can name your endpoint SBRelayEndpoint, with the same address the service used.
<client>
<endpoint
name="SBRelayEndpoint"
address=
"sb://stringreversalinc.servicebus.windows.net/processtring"
binding="netTcpRelayBinding"
contract="StringReversalLibrary.Contract.IReverseString"
behaviorConfiguration="sharedSecretClientCredentials"
/>
</client>
The client is going to have to
authenticate to the Service Bus as well—you can configure it to use a
shared secret. Use the Maine Reversal issuer from section 7 of this article. Keep in mind that there are two endpoints: one for the
ACS service, and one for the Service Bus. They don’t share issuers. You
can configure the credentials by changing the behavior of the service
in the app.config file:
<behavior name="sharedSecretClientCredentials">
<transportClientEndpointBehavior credentialType="SharedSecret">
<clientCredentials>
<sharedSecret issuerName=" MaineReversal" issuerSecret=" ltSsoI5l+8DzLSmvsVOhOmflAsKHBYrGeCR8KtCI1eE=" />
</clientCredentials>
</transportClientEndpointBehavior>
</behavior>
Now the client can call
your service from anywhere and always be able to connect to it. This
makes it easy to provision new customers. In the old, direct method, you
had to reconfigure the firewalls to let the new customer through. Now
you can point them to the Service Bus address and give them the
credentials they’ll need.
The binding we used in this
example is based on TCP, which is one of the fastest bindings you can
use in WCF. It adds the relay capabilities to allow us to message
through the bus instead of directly. There are other bindings available
that support using the relay.
Now that we’ve covered what AppFabric can do today, let’s consider what its future might hold.
