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.
I had a similar issue with Windows 7 running Visual Studio 2010. My solution was a simple WCF service library with a simple console project serving as the WCF service host.
My base address in app.config was "http://localhost:8080/BookService" and I forgot that I had to start Visual Studio as an administrator in order to get Windows to map that port to my app.
As soon as I started Visual Studio as an Administrator (right click, Run as administrator) it ran like a champ.
Best Solution
From what it sounds like, you have both the service and client in the same executable. While this can be done, when you want them on separate machines you need to have an executable/host for the service (either self hosted, or in IIS) and an executable for the client. Each will need to be properly configured with the address, binding, and contract in the appropriate configuration section for it. So on the server you'd have something like this:
And on the client you'd have this:
The main thing is to make sure that the client and server can communicate with each other over the specified port and protocol (primarily making sure a firewall isn't blocking communication). The other thing to be aware of is changing your binding protocol may impact other aspects of your service (security is a big one, but also what you can and cannot do with the service).