Above The Cloud

In my last post (only this morning) I talked about an extra endpoint appearing in the WCF Test Client being the result of a rogue entry in Machine.Config, placed there when you install the .Net Services SDK.

I just noticed that this endpoint also appears elsewhere. Consider this screen capture:

This is the ‘Edit WCF Configuration’ screen screen that you can use to specify client and service endpoints in your App.Config / Web.Config. The only problem is that I have not defined any client end points : only service ones. And as you can see, the name is ‘sb’ which is the same name given to the end point defined in machine.config.

Funnily enough you can actually delete the endpoint from here. This causes the following to appear in your app.config:

<client>
  <remove contract=”IMetadataExchange” name=”sb” />
</client>

As a result, the endpoint no longer appears in your application. But it is still there when you run the WCF Test Client, so it still seems the only definitive way to remove it is in the machine.config file.

I came across something interesting today. I was using WCF for something completely unrelated to Azure and .Net Services. Whenever I ran the WCF Test Client (which hosts your service for you) I would get an error: the test client would attempt to add an IMetadata endpoint, even if you don’t have one defined!

There is also a popup message when the client first opens indicating that states:

The contract ‘IMetadataExchange’ in client configuration does not match the name in service contract

Its not a huge deal; you can ignore the error and still proceed to test your service. However it was worth investigating a little further.

I came across this thread that seemed to describe exactly my problem, however it related purely to Biztalk SDK which I definately did not have installed (I even double checked to ensure it wasn’t installed as part of another SDK such as Win2008 SDK, VS SDK, etc). Did I have Biztalk SDK installed somewhere that I couldn’t find?

I proceeded to investigate the machine.config file, found in your C:\Windows\Microsoft.NET\Framework\v2.0.50727\CONFIG directory. Under the <client> section I had quite a lot of interesting stuff, but as expected the IMetadataExchange endpoint was defined there:

<endpoint address=”" binding=”netTcpRelayBinding” bindingConfiguration=”metadataExchangeRelayBinding”
    contract=”IMetadataExchange” name=”sb” />

This was definately the culprit, I knew because the name (sb) matched that in the WCF Test Client. I knew from the article that the solution was to remove the whole <client> section, but I really wanted to know what had put it there. Looking further down I ran across some lines similar to this:

<extension type=”Microsoft.ServiceBus.Description.TcpRelayTransportBindingElementImporter, Microsoft.ServiceBus, Version=0.14.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35″ />

This is when I had my lightbulb moment. The reference to ‘Microsoft.ServiceBus’ gave it all away. Yes, Biztalk is an Enterprise Service Bus, and no doubt lots of its assemblies are probably along these lines, but there is something else that evolved from Biztalk: Biztalk Services… which is now known as ‘.Net Services’.

Summary

In summary, if you see this error in your WCF Test Client, you will know that it is because you either have Biztalk SDK or .Net Services SDK installed. However I am unsure if it is safe for your Azure projects if you remove the <client> section from your machine.config. I’ll put the feelers out to see what I can find out.

To understand the Internet Service Bus Application Pattern we must first understand the concepts of an Enterprise Service Bus (ESB). An ESB is essentially a brokering service that facilitates communication between entities (usually services). Imagine a situation where there is a service that only communicates via TCP on port 1000 and a client that can only make requests over HTTP due to a corporate firewall. An ESB can broker such communication.

For an ESB to be successful it must be flexible. It needs to support many different protocols, be able to communicate synchronously and asynchronously, manage security, translate messages between services, and be programming language agnostic. For more information on what an Enterprise Service Bus is, refer to the Wikipedia article for a detailed description.

So what happens if we want to take these concepts and make them available on the Internet? How would one design an Internet Service Bus (ISB)?

Taking an existing ESB and simply "Internet enabling" it is one such approach, but this doesn’t make it much different from an ESB. One of the key differences is that some of the services need to be hosted in the ISB. That is, users can move some of their service applications into the cloud. Another consideration is security: authentication to use the ISB itself, but also end-to-end security around the brokered communications.

Microsoft have implemented an ISB as a part of their Azure offering, and this naturally manifests itself in the Microsoft .NET Services platform. The ISB is a critical piece of infrastructure in brokering communication and managing workflow. Microsoft has established some important concepts as part of the high level pattern for its own ISB (BizTalk Services):

• Service Registry
• Naming
• Identity and Access Control
• Connectivity

Service Registry
This is a common registry for storing services hosted by the ISB. This helps mediate the brokering process.

Naming
Applying human readable naming conventions such as a URI to easily identify a particular service

Identity and Access Control
This helps identify what kinds of security mechanisms will be available (for example, Active Directory, Live ID, OpenID, etc) and how to manage the authentication and authorization of various services.

Connectivity
The ISB needs to provide brokering services, but also needs to be able to step out of the picture once a connection is established. Or sometimes having all communications going through the relay can help optimize performance.

Each of the above areas is a blog post unto itself, but the most complicated and detailed aspects of the Microsoft ISB definitely lie in Identity and Connectivity. For example, to create a connection between 2 services, the relay within the ISB must be employed to make that connection. But after this we can control how the connection continues: via the relay or via a direct connection. Sometimes maintaining a relay is important because of services that sit behind firewalls. There are now a whole bunch of new protocols for Windows Communication Foundation (WCF) that support connecting via the ISB.

For more information about the Microsoft ISB, please check these articles/videos:

The Internet Service Bus
InternetServiceBus.org
Architecture of the .NET Services – PDC2008 Video

I recommend the 3rd link above which is a video from PDC which describes the ISB extremely well with practical examples in .NET.