You can expose the service in two different endpoints.
the SOAP one can use the binding that support SOAP e.g. basicHttpBinding, the RESTful one can use the webHttpBinding. I assume your REST service will be in JSON, in that case, you need to configure the two endpoints with the following behaviour configuration
<endpointBehaviors>
<behavior name="jsonBehavior">
<enableWebScript/>
</behavior>
</endpointBehaviors>
An example of endpoint configuration in your scenario is
<services>
<service name="TestService">
<endpoint address="soap" binding="basicHttpBinding" contract="ITestService"/>
<endpoint address="json" binding="webHttpBinding" behaviorConfiguration="jsonBehavior" contract="ITestService"/>
</service>
</services>
so, the service will be available at
Apply [WebGet] to the operation contract to make it RESTful.
e.g.
public interface ITestService
{
[OperationContract]
[WebGet]
string HelloWorld(string text)
}
Note, if the REST service is not in JSON, parameters of the operations can not contain complex type.
Reply to the post for SOAP and RESTful POX(XML)
For plain old XML as return format, this is an example that would work both for SOAP and XML.
[ServiceContract(Namespace = "http://test")]
public interface ITestService
{
[OperationContract]
[WebGet(UriTemplate = "accounts/{id}")]
Account[] GetAccount(string id);
}
POX behavior for REST Plain Old XML
<behavior name="poxBehavior">
<webHttp/>
</behavior>
Endpoints
<services>
<service name="TestService">
<endpoint address="soap" binding="basicHttpBinding" contract="ITestService"/>
<endpoint address="xml" binding="webHttpBinding" behaviorConfiguration="poxBehavior" contract="ITestService"/>
</service>
</services>
Service will be available at
REST request
try it in browser,
http://www.example.com/xml/accounts/A123
SOAP request
client endpoint configuration for SOAP service after adding the service reference,
<client>
<endpoint address="http://www.example.com/soap" binding="basicHttpBinding"
contract="ITestService" name="BasicHttpBinding_ITestService" />
</client>
in C#
TestServiceClient client = new TestServiceClient();
client.GetAccount("A123");
Another way of doing it is to expose two different service contract and each one with specific configuration. This may generate some duplicates at code level, however at the end of the day, you want to make it working.
Not sure I can give a complete answer here but I spent a lot of time at PDC trying to figure this out myself so here’s a go...
The short answer here is that ADO.Net Data Services are meant to provide an interface to the ADO.Net framework (DataContext, Datasets, DataTables etc…) that is seamlessly integrated with the web, using URIs and well-known data to point to your Data. ADO.Net Data Services are also meant for programming ADO.Net in the cloud. Microsoft's Cloud services, "Azure", is a new cloud programming platform that will be release in the near future. For more info on Cloud Services go here.
One cool thing I found out about ADO.Net Data Services and the cloud is that the underlying DataContext that acts as the provider to your data source can be easily configured to point your resource in the cloud, or, an on premise database. This allows you to switch your DataContext without changing any code!!! (I was impressed by that if you couldn't tell)
WCF Rest Services are just normal WCF Services that have added functionality so that they can be consumed in a RESTful manner (URI vs URL, Usage of HTTTP Verbs, Usage of Different Data Transfer Formats like JSON, YAML, etc...). So for example, if you had a stock ticker web service that you built in WCF, instead of requiring the caller to use a heavy WSDL implementation and ASMX, you could just use the WCF Rest functionality to publish that service as a JSON service instead and have it consumed via AJAX without having to point to an ASMX resource. For more info on WCF using rest check out the PDC Presentation
Best Answer
First, my advice would be to write your MVC code so that it is oblivious to what the back-end data model is. Abstract away any dependencies right from the beginning.
As for deciding whether or not to use WCF, I'd suggest that you decide whether or not you'll want to reuse the data component that you write. If you have plans on using your data code in a Silverlight, WPF, or any other format, then I'd suggest sticking with WCF.
Also, remember that you can always simply wrap the ADO.NET data services with a WCF component and still enable the reuse scenario. Get the best of both worlds!