Infosys | Microsoft

Firstly, to have an on-premise service made available for  consumption by an external consumer, the service had to be made publically available. This is possible by using the connectivity capability of the .NET Services which allows for on-premise WCF type services to be seamlessly made accessible on the public cloud. And so we decided to use the .NET service supported configuration bindings in our on-premise service code.

We approached this assuming, for obvious reasons, that .NET Services (DEC 2008 CTP) being a part of the Azure platform would be supported on Windows Azure (Jan 2009 CTP). However we later found out that not all bindings of the .NET services platform were able to support this scenario.

In such a scenario, with the current release of .NET Services, we found that only “basicHttpRelayBinding/wsHttpRelayBinding” along with having the “RelayClientAuthenticationType” set as ‘None’ was supported. Other bindings cannot be used as they cause a conflict with the current version of Azure Platform.

Additionally what was also noticed was that the hosting .NET services using IIS is not supported in this release, which apparently had been available with the earlier release. Hence the use of IIS as a WCF service host had to be substituted with the likes of a custom hosting application such as a console or a windows service. Once the WCF service got hosted a proxy needed to be generated, the usual process followed by which any .net client can consume a WCF service, using svcutil command.

Interestingly the configuration file generated by using the svcutil utility defaulted the binding type in the service model configuration of the client to either a wshttpbinding or basichttpbinding.

Thus, allowing the Cloud-aware services to be consumed by Azure hosted applications.