Software in the cloud: The Relay Service

I’m now back from a trip to Seattle a few weeks back where I attended a huge week-long Microsoft internal technical training event. I presented three times during the week, two of the presentations were “Software in the cloud” sessions which received fantastic feedback.

The premise of these sessions was to paint a view of how software solutions may look in the future if they were to leverage cloud based services such as SQL Server Data Services (SSDS) and BizTalk Services (Cloud Workflow, Identity and Connectivity).

I presented a fictional but realistic architecture using today’s technologies and discussed the challenges, I then presented a forward view on how you might approach the same problem using cloud based technologies and how this solves a number of challenges today and opens up completely new opportunities which for the most part aren’t possible today.

I’m going to present this scenario and the resulting solution in a series of blog posts, this being the first.

Before we get started I want to introduce the BizTalk Services Relay which by itself is incredibly powerful but often overlooked. There is an SDK to download and play with via https://www.biztalk.net

So, if I have a Service offering today, say Credit Scoring functionality, it’s hard to enable business partners to invoke this service, especially if your organisation doesn’t host things out on the internet regularly.

You’ve got any number of options generally involving any combination of leased lines, VPNs, proxy configuration, etc. The key point here is that you must put in infrastructure and/or specific configuration for each business partner that wishes to leverage your service, and of course vice versa, each business partner will have to do the same to enable messages to pass out of their corporate boundary.

So, imagine a technology that enabled you to avoid all of this infrastructure/configuration whilst still maintaining security and integrity of messages passing between the organisations?

This is where the Relay comes into play; the first step is for your WCF service to register it’s endpoint with the cloud based relay service, a valid BizTalk Services account will be required to register an endpoint under the users namespace. This step is shown below as step number 1.

The endpoint address will use a specific “service bus” prefix, e.g: sb://connect.biztalk.net/services/darrenj/OrderService/

Once an endpoint has been registered with the relay service it must be kept alive otherwise the socket could of course timeout. This is done through a series of “ping” messages automatically passed under the covers between the relay service and the endpoint.

Once an endpoint is registered a client can then invoke the service, within Visual Studio you can simply type in the sb:// prefixed address via the usual Add Service Reference dialog and the proxy will be automatically created and configured – neat!

The proxy can then use the contract as usual, once invoked the message will be passed to the endpoint registered in the cloud (shown as number 3 in the diagram above) which will in-turn pass the message on to the service (shown as number 4 in the diagram above), the reverse then happens with the response (shown as number 4 in the diagram above).

In essence this is a straight forward message relay pattern with all messages passing via the relay, enabling two parties to exchange messages where they otherwise wouldn’t have been able to.

This works fine, but it would be nicer (and probably quicker) if we could enable both parties to communicate directly but the firewalls won’t allow this. However the relay service knows quite a bit about the two parties.

When the service registered itself with the relay, the relay can see which dynamic port number the hosting organisation’s firewall is using for this communication session. When a client communicates with the relay, the relay can again see the dynamic port number being used.

By sharing the port numbers with each party the relay can effectively step out of the way and enable both parties to communicate with each other after this initial port handshaking, this is depicted below and is explained in better detail in this great article

This process is called NAT traversal and is used by many things today including MSN Messenger, Groove, Skype, etc. Some firewalls may not allow NAT traversal at which point the relay will fall back to the original relay pattern. As long as both parties can see the internet and therefore the relay service then we’re in business!

This is a big step forward from today where you have to provision and configure network infrastructure such as Proxies, Firewalls, Private Network Links, VPNs, etc. whenever you wish to expose invoke services between organisations.

With this relay service you can break down your corporate barriers to communicate across organisations and through the relay you can also utilise non-durable publish/subscribe messaging effectively publishing business “events” which others can subscribe to.

So how about security? Firewalls are there for a reason and you typically aren’t allowed to punch holes through them. Access to any services exposed through the relay is restricted through the BizTalk Services provided implementation of a Security Token Service (STS) and messages can be secured as you require using encryption of the payload and digital signatures.

So, it must be hard to host a service through the relay? Well not really, it’s just a bit of WCF configuration on your service an example of which is shown below:

<system.serviceModel>

  <bindings>

  <relayBinding>

    <binding name="default" allowBrowsing="true" sendTimeout="01:00:00"

  connectionMode="RelayedDuplexSession">

  </binding>

  </relayBinding>

  </bindings>

 

  <!-- Service endpoint using the BizTalk Services relay -->

  <endpoint

  address=""

  binding="relayBinding"

  contract="PaymentService.IPayment"

  behaviorConfiguration="relayBehavior"

  bindingConfiguration="default"/>

  <behaviors>

  <endpointBehaviors>

  <behavior name="relayBehavior">

  <transportClientEndpointBehavior credentialType="UserNamePassword">

      <clientCredentials>

      <userNamePassword userName="USERNAME" password="PASSWORD"/>

      </clientCredentials>

      </transportClientEndpointBehavior>

    </behavior>

  </endpointBehaviors>

  </behaviors>

</system.serviceModel>

You don’t need to include the custom endpointBehavior in all cases, if you don’t then CardSpace will pop up to authenticate you and validate that you have permission to register a service at the specified endpoint – not ideal for non-interactive services J

Hopefully that’s given you a good flavour of what the relay service can do, it’s a fantastic piece of technology and opens up the opportunity to break down the enterprise SOA barriers whereby your services can only be consumed or exposed within your corporate boundaries.

To my mind, this opens up some great new opportunities for solutions moving forward, as we’ll see in my next few blog posts J