Have you played with OData much yet? The OData protocol allows you to interact with data resources through a RESTful API. But what if you want to securely expose that OData feed out to external parties? In this post, I’ll show you the very simple steps for exposing an OData feed through Windows Azure AppFabric.
- Create ADO.NET Entity Data Model for Target Database. In a new VS.NET WCF Service project, right click the project and choose to add a new ADO.NET Entity Data Model. Choose to generate the model from a database. I’ve selected two tables from my database and generated a model.
- Create a new WCF Data Service. Right-click the Visual Studio project and add a new WCF Data Service.
- Update the WCF Data Service to Use the Entity Model. The WCF Data Service template has a placeholder where we add the generated object that inherited from ObjectContext. Then, I uncommented and edited the “config.SetEntitySetAccessRule” line to allow Read on all entities.
- View the Current Service. Just to make sure everything is configured right so far, I viewed the current service and hit my “/Customers” resource and saw all the customer records from that table.
- Update the web.config to Expose via Azure AppFabric. The service thus far has not forced me to add anything to my service configuration file. Now, however, we need to add the appropriate AppFabric Relay bindings so that a trusted partner could securely query my on-premises database in real-time.
I added an explicit service to my configuration as none was there before. I then added my cloud endpoint that leverages the System.Data.Services.IRequestHandler interface. I then created a cloud relay binding configuration that set the relayClientAuthenticationType to None (so that clients do not have to authenticate – it’s a demo, give me a break!). Finally, I added an endpoint behavior that had both the webHttp behavior element (to support REST operations) and the transportClientEndpointBehavior which identifies which credentials the service uses to bind to the cloud. I’m using the SharedSecret credential type and providing my Service Bus issuer and password.
- Connect to the Cloud. At this point, I can connect my service to the cloud. In this simple case, I right-clicked my OData service in Visual Studio.NET and chose View in Browser. When this page successfully loads, it indicates that I’ve bound to my cloud namespace. I then plugged in my cloud address, and sure enough, was able to query my on-premises database through the OData protocol.
That was easy! If you’d like to learn more about OData, check out the OData site. Most useful is the page on how to manipulate URIs to interact with the data, and also the live instance of the Northwind database that you can mess with. This is yet another way that the innovative Azure AppFabric Service Bus lets us leverage data where it rests and allow select internet-connected partners access it.
Richard Seroter's Architecture Musings 
Very cool post and simple to follow
Nice article. I have a few doubts. I could not follow the part where you expose this web service using Windows Azure App Fabric using xxxRelayBinding so that it is exposed to the cloud. Can you provide some elaboration around that part?
Hi Karan. Have you used/seen much of the AppFabric Service Bus? Using the “cloud bindings”, you provide specific credentials and the local service connects to the cloud for others to invoke. The samples for the Service Bus are helpful (http://msdn.microsoft.com/en-us/library/ee706741.aspx).
Nice post, but I have some questions. I’m new to this and was wanting additional clarification about this part
“I added an explicit service to my configuration as none was there before. I then added my cloud endpoint that leverages the System.Data.Services.IRequestHandler interface. I then created a cloud relay binding configuration that set the relayClientAuthenticationType to None (so that clients do not have to authenticate – it’s a demo, give me a break!). Finally, I added an endpoint behavior that had both the webHttp behavior element (to support REST operations) and the transportClientEndpointBehavior which identifies which credentials the service uses to bind to the cloud. I’m using the SharedSecret credential type and providing my Service Bus issuer and password.”
Hi Brad,
This refers to the Azure Service Bus and the Relay Service. Using this, you can expose on-premises services – http://azure.microsoft.com/en-us/documentation/articles/service-bus-dotnet-how-to-use-relay/
Hi,
thanks for the explanation. Im actually trying to get a SQL Server Database connected to my salesforce organization in real time and need to create a OData Service with the method you referenced on top.
But Im actually struggling at this part:
“Update the web.config to Expose via Azure AppFabric. The service thus far has not forced me to add anything to my service configuration file. Now, however, we need to add the appropriate AppFabric Relay bindings so that a trusted partner could securely query my on-premises database in real-time.
I added an explicit service to my configuration as none was there before. I then added my cloud endpoint that leverages the System.Data.Services.IRequestHandler interface. I then created a cloud relay binding configuration that set the relayClientAuthenticationType to None (so that clients do not have to authenticate – it’s a demo, give me a break!). Finally, I added an endpoint behavior that had both the webHttp behavior element (to support REST operations) and the transportClientEndpointBehavior which identifies which credentials the service uses to bind to the cloud. I’m using the SharedSecret credential type and providing my Service Bus issuer and password.”
Do I need a microsoft account with a paid azure login to get this done?