Is it possible to use the new WCF routing serice in WCF 4 for REST based services? I have something similar to a reverse proxy in mind. Basically I have a number of selfhosted rest based serivces which I want to expose via IIS with the same base url and port. The routing should be done by the last part of the url. I'm absolutly new to thw WCF routing service, so forgive me if that's a silly question, but I couldn't find any information about that on the web.
I have tried something like this (where serivce1/2 are the selfhosted services):
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior name="RoutingBehavior">
<routing routeOnHeadersOnly="false" filterTableName="RoutingTable"/>
<serviceDebug includeExceptionDetailInFaults="true"/>
<serviceMetadata httpGetEnabled="true"/>
</behavior>
</serviceBehaviors>
</behaviors>
<services>
<service behaviorConfiguration="RoutingBehavior" name="System.ServiceModel.Routing.RoutingService">
<endpoint address="myservices" contract="System.ServiceModel.Routing.IRequestReplyRouter" binding="basicHttpBinding"/>
</service>
</services>
<routing>
<filterTables>
<filterTable name="RoutingTable">
<add filterName="service1Filter" priority="0" endpointName="service1"/>
<add filterName="service2Filter" priority="0" endpointName="service2"/>
</filterTable>
</filterTables>
<filters>
<filter name="service1Filter" filterType="MatchAll"/>
<filter name="service2Filter" filterType="MatchAll"/>
</filters>
</routing>
<client>
<endpoint address="http://somehost:8888/test/service1" binding="basicHttpBinding" contract="*" name="service1"/>
<endpoint address="http://somehost:8732/test/service2" binding="basicHttpBinding" contract="*" name="service2"/>
</client>
<serviceHostingEnvironment multipleSiteBindingsEnabled="true"/>
</system.serviceModel>
but that doesn't seem to work. I'm getting an endpoint not found exception. http://somehost:8888/test/service1 ist the base address of the selfhosted service and not the actual endpoint. Can I do routing based on the base address or (if rest routing is possible) must I add a route for every endpoint?
I solved the problem by using a reverse proxy (in my case arr). I don't konw if using the WCF routing service for this purpose is possible, but it's probably a misuse.
Routing Service is only available for SOAP requests. To use routing with RESTful WCF you need to setup your routes using System.Web.Routing similar to MVC routing.
Related
Background
I have created ASMX web services in the past and have been able to access the service from the web browser and Ajax GET requests using the address convention: MyService.asmx/MyMethod?Param=xxx
I just got started using WCF and created a new web service in my ASP.NET project. It creates a file with the .svc extension such as MyService.svc.
Current Situation
I am able to consume the service using the WcfTestClient that comes with VS2008. I am also able to create my own WCF Client by either adding a service reference in another project or using the svcutil.exe commandline to generate the proxy and config file.
The Problem
When I try to use the service from a browser using MyService.svc/MyMethod?MyParam=xxx, I get a blank page without any errors.
What I have tried
I have already added a basicHttpBinding to the web.config and made it HttpGetEnabled in the behavior configuration. I also added the [WebGet(UriTemplate = "MyMethod?MyParam={MyParam}")] attribute to my operation contract.
I have already followed the information in this other stack overflow question:
REST / SOAP EndPoints for a WCF Service
However, I either get a blank page or an HTTP 404 Error after following those steps. There's nothing special about the code. I am just taking in a string as a parameter and returning "Hello xxx". This is a basic "Hello WCF World" proof-of-concept type thing.
UPDATE - Here's the relevant code
[ServiceContract]
public interface IMyService
{
[WebGet(UriTemplate = "MyMethod/MyParam={MyParam}")]
[OperationContract]
string MyMethod(string MyParam);
}
Web.Config - system.serviceModel Section
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior name="MyServiceBehavior">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true"/>
</behavior>
</serviceBehaviors>
</behaviors>
<services>
<service behaviorConfiguration="MyServiceBehavior" name="MyService">
<endpoint address=""
binding="wsHttpBinding" contract="IMyService" />
<endpoint address="MyService.svc"
binding="basicHttpBinding" contract="IMyService" />
<endpoint address="mex"
binding="mexHttpBinding" contract="IMetadataExchange"/>
</service>
</services>
</system.serviceModel>
Looking at your web.config serviceModel section, I can see that you need to add a webHttpBinding and associate an endPointBehavior that includes webHttpGet.
Your operation contract is correct. Here's how your system.serviceModel config section should look in order for you to be able to consume the service from a GET HTTP request.
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior name="MyServiceBehavior">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true"/>
</behavior>
</serviceBehaviors>
<endpointBehaviors>
<behavior name="WebBehavior">
<webHttp />
</behavior>
</endpointBehaviors>
</behaviors>
<services>
<service behaviorConfiguration="MyServiceBehavior" name="MyService">
<endpoint address="ws" binding="wsHttpBinding" contract="IMyService"/>
<endpoint address="" behaviorConfiguration="WebBehavior"
binding="webHttpBinding"
contract="IMyService">
</endpoint>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
</service>
</services>
</system.serviceModel>
Be sure to assign a different address to your wsHttpBinding endpoint, otherwise you will get an error saying that you have two endpoints listening on the same URI.
Another option is to leave the address blank in the wsHttpBinding, but assign a different address to the webHttpBinding service. However, that will change your GET address as well.
For example, if you assign the address as "asmx", you would call your service with the address "MyService.svc/asmx/MyMethod?MyParam=xxxx".
The normal WCF requests are always SOAP requests - you won't be able to get this going with just your browser, you'll need the WCF Testclient for that.
There is an add-on for WCF called the WCF REST Starter Kit (which will also be included in WCF 4.0 with .NET 4.0), which allows you to use GET/POST/PUT/DELETE HTTP commands to query WCF services and such. You need to write your services specifically for REST, though - you can't have SOAP and REST on the same service call.
Marc
As marc_s says, the REST Starter Kit can help, but you should also be aware that .NET 3.5 has support for REST services directly in it. It's not quite as complete as what you can do with the starter kit, but it is useful.
The way it works is that you put a [WebGet] attribute on your operations to indicate where in the URL the various parameters should come from:
[WebGet(UriTemplate = "helloworld/{name}")]
string Helloworld(string name);
See this portal for tons of information.
Note, you can have the same service exposed as both SOAP and REST if you specify multiple endpoints/bindings in the configuration.
i am working with wcf service application where svc file is created. now i want to design my service in such a way that people can connect to my service by http url and as well as by tcp url
so i would like to add three endpoint in my config one for wshttp, one for wsDualhttp and another one for tcp. so please someone give me sample config entry with 3 endpoints for wshttp, wsDualhttp and tcp.
in this case do i need to have three different mex endpoint for wshttp, wsDualhttp and tcp.
also tell me 3 url by which i can create proxy classes at client side. thanks
You could have something like this (assuming self-hosting, since only then can you really determine the full service addresses yourself - hosting in IIS, the service address(es) are most determined by where your .svc file lives):
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior name="Default">
<serviceMetadata httpGetEnabled="true"/>
</behavior>
</serviceBehaviors>
</behaviors>
<services>
<service name="YourNamespace.YourService" behaviorConfiguration="Default">
<endpoint name="Default"
address="http://YourServer/Services/MyService"
binding="basicHttpBinding"
contract="YourNamespace.IYourService"/>
<endpoint name="TCP"
address="net.tcp://YourServer/ServicesTCP/MyService"
binding="netTcpBinding"
contract="YourNamespace.IYourService"/>
<endpoint name="mex"
address="http://YourServer/Services/MyService/mex"
binding="mexHttpBinding"
contract="IMetadataExchange"/>
<endpoint name="Dual"
address="http://YourServer/Services/MyService/Dual"
binding="wsDualHttpBinding"
clientBaseAddress="http://localhost:8001/client/"
contract="YourNamespace.IYourDualService"/>
</service>
</services>
</system.serviceModel>
This would define three endpoints:
a HTTP endpoint at http://YourServer/Services/MyService for your service
a HTTP MEX endpoint at http://YourServer/Services/MyService/mex for the metadata exchange (service discoverability)
a Net.TCP endpoint at net.tcp://YourServer/ServicesTCP/MyService for your service
You could of course also use two base addresses to make things a bit easier in the config:
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior name="Default">
<serviceMetadata httpGetEnabled="true"/>
</behavior>
</serviceBehaviors>
</behaviors>
<services>
<service name="YourNamespace.YourService" behaviorConfiguration="Default">
<host>
<baseAddresses>
<add baseAddress="http://YourServer/Services"/>
<add baseAddress="net.tcp://YourServer/ServicesTCP"/>
</baseAddresses>
</host>
<endpoint name="Default"
address="MyService"
binding="basicHttpBinding"
contract="YourNamespace.IYourService"/>
<endpoint name="TCP"
address="MyService"
binding="netTcpBinding"
contract="YourNamespace.IYourService"/>
<endpoint name="mex"
address="MyService/mex"
binding="mexHttpBinding"
contract="IMetadataExchange"/>
</service>
</services>
</system.serviceModel>
This would configure the equivalent service endpoints.
The wsDualHttpBinding is different in that it requires at least a clientBaseAddress for the callback mechanism (the WCF service will call back your client to send back e.g. status messages) - so it needs some extra tweaks and it cannot really be bolted onto an existing service that works over wsHttpBinding - it needs to be done separately. But basically - it's still pretty much all the same thing....
Update: after reading up on the topic (it's not something I use very often), it does appear that duplex communication is indeed possible also using netTcpBinding, but only if you're self-hosting your service - IIS doesn't support duplex communication over netTcpBinding.
Creating a duplex service does still require extra steps and extra code - so you cannot really have a service that's both non-duplex using basicHttpBinding or wsHttpBinding and duplex at the same time. So it really doesn't make sense to have another endpoint in this example using the wsDualHttpBinding because that service either needs to be really duplex (then you can use wsDualHttpBinding and netTcpBinding) - or it's not duplex - then you can use basicHttpBinding, wsHttpBinding, netTcpBinding and a few more "exotic" bindings (like MSMQ, named pipes etc.)
I have two websites hosted on the same IIS server. SiteA contains WCF services that need to be accessed by SiteB, as well as anything else that is authenticated on the domain.
The service is configured with a wsHttpBinding and thus I believe uses Windows security by default. Right now I can call the services from a console app running on my local machine, as well as from a web application running in the default Visual Studio web server, so I am taking that the authentication is working.
However, when SiteB tries to access the services, it fails with this error:
The caller was not authenticated by the service.
SiteB runs on the same machine than SiteA so I don't understand why it could not be authenticated. SiteB uses Forms Authentication and I mapped Anonymous access to a domain user.
Here are the config bits:
SiteA (service):
<system.serviceModel>
<serviceHostingEnvironment aspNetCompatibilityEnabled="true" multipleSiteBindingsEnabled="true" />
<services>
<service behaviorConfiguration="wcfServiceBehaviour" name="MyService">
<endpoint address="" binding="wsHttpBinding" contract="IServiceContract" />
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="wcfServiceBehaviour">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="true" />
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
SiteB (client):
<system.serviceModel>
<client>
<endpoint address="http://xxxxx/Services/xxService.svc"
binding="wsHttpBinding"
contract="IServiceContract" />
</client>
</system.serviceModel>
You are correct - wsHttpBinding configured in WCF will use Windows Authentication by default.
There is a suggestion here - WCF - changing endpoint address results in securityexception - that the Identity block will not work with Windows Authentication - try removing it.
When SiteB impersonates another user, does your code specify the impersonation level?
My guess is that your are not specifying a high enough level of impersonation. (Delegation is the highest, allowing SiteB to pass the permissions to a different service).
I suspect that fixing up the SiteB impersonation code will be enough to solve the problem.
If not, try passing the allowable impersonation level to the server:
<system.serviceModel>
<client>
<endpoint address="http://xxxxx/Services/xxService.svc"
binding="wsHttpBinding"
contract="IServiceContract"
behaviorConfiguration = "ImpersonationBehavior" />
</client>
<behaviors>
<endpointBehaviors>
<behavior name="ImpersonationBehavior">
<clientCredentials>
<windows allowedImpersonationLevel = "Delegation" /> <!-- The highest level -->
</clientCredentials>
</behavior>
<endpointBehaviors>
</behaviors>
</system.serviceModel>
If you're using a self hosted site like me, the way to avoid this problem (as described above) is to stipulate on both the host and client side that the wsHttpBinding security mode = NONE.
When creating the binding, both on the client and the host, you can use this code:
Dim binding as System.ServiceModel.WSHttpBinding
binding= New System.ServiceModel.WSHttpBinding(System.ServiceModel.SecurityMode.None)
or
System.ServiceModel.WSHttpBinding binding
binding = new System.ServiceModel.WSHttpBinding(System.ServiceModel.SecurityMode.None);
I created a web service for which I am trying to provide 3 endpoints with different bindings.
1. basicHttpBinding,
2. wsHttpBinding,
3. webHttpBinding
When I make the service reference, I get only the endpoints with the basicHttpBinding and wsHttpBinding bindings created. I don't get webHttpBinding. What could possibly wrong.
Here's the structure of the serviceModel node in web.config.
<system.serviceModel>
<diagnostics>
<messageLogging logEntireMessage="true" logMessagesAtServiceLevel="true" logMessagesAtTransportLevel="true"/>
</diagnostics>
<services>
<service behaviorConfiguration="VersionTolerance.Service1Behavior" name="BookShop.BookShopService">
<endpoint address="sadha" binding="basicHttpBinding" contract="BookShop.IBookShopService" />
<endpoint address="ws" binding="wsHttpBinding" contract="BookShop.IBookShopService" >
</endpoint>
<endpoint address="web" binding="webHttpBinding" behaviorConfiguration="webHttpBehavior"
contract="BookShop.IBookShopService" />
<host>
<baseAddresses>
<add baseAddress="http://localhost:49654/" />
</baseAddresses>
</host>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="VersionTolerance.Service1Behavior">
<!-- To avoid disclosing metadata information, set the value below to false and remove the metadata endpoint above before deployment -->
<serviceMetadata httpGetEnabled="true"/>
<!-- To receive exception details in faults for debugging purposes, set the value below to true. Set to false before deployment to avoid disclosing exception information -->
<serviceDebug includeExceptionDetailInFaults="false"/>
</behavior>
</serviceBehaviors>
<endpointBehaviors>
<behavior name="webHttpBehavior">
<webHttp/>
</behavior>
</endpointBehaviors>
</behaviors>
There's nothing wrong - that's just the way it works!
basicHttpBinding and wsHttpBinding are SOAP bindings that expose metadata about their service - your Visual Studio Add Service Reference can interrogate their endpoints, find out what they're called, what methods they offer, what data types they expect as parameters and what they return.
webHttpBinding is REST - and REST by default doesn't have a concept of metadata - you won't get a service description, list of methods etc. - REST is all about resources - not methods.
So therefore, when you do a Add Service Reference, you get proxy clients for the SOAP endpoints - but not for the REST / webHttpBinding endpoint. Works as designed.
The WCF Data Services - built on top of REST - offer a similar experience to the SOAP bindings, in that you can do an Add Service Reference and get a nice client side proxy and all - and this is done since the OData protocol defines a metadata exchange on top of REST. So if you can turn your REST service into a WCF Data Service, you'd be fine again.
Otherwise, with REST, you just have to "know" (from a documentation page or something) what the resource URI's for your REST service are, and what the HTTP verbs do in your REST context.
Should the WSDl only be accessible via the ".svc?wsdl" ? I have a service that has multiple endpoints. For example (in the web.config):
<services>
<service behaviorConfiguration="MyServiceTypeBehavior" name="WcfService1.Service">
<endpoint binding="wsHttpBinding" bindingConfiguration="ws1"
name="ws1" contract="WcfService1.IMyService" />
<endpoint address="http://www.blah.com/Service.svc/Basic" binding="basicHttpBinding"
bindingConfiguration="Basic" name="Basic" contract="WcfService1.IMyService" />
<endpoint address="http://localhost:5606/Service.svc/Secured"
binding="wsHttpBinding" bindingConfiguration="WsSecured" name="WsSecured"
contract="WcfService1.IMyService" />
</service>
</services>
If I go to: http://www.blah.com/Service.svc/Basic I get a 404 page error. When I go to http://www.blah.com/Service.svc?wsdl I see my wsdl and my 3 endpoints at the bottom of the page. Should I be able to get to the other endpoints via their address? I have a client that is using Axis2 to get to our services and I would like to use multiple endpoints for different clients. I know that I can add this to the serivce behavior:
<behavior name="MyServiceTypeBehavior">
<serviceMetadata httpGetEnabled="true" httpGetUrl="Basic" />
<serviceDebug includeExceptionDetailInFaults="true" />
<dataContractSerializer maxItemsInObjectGraph="2147483646"/>
</behavior>
But I would have to create a service entry for each endpoint, right? Should I even be concerned about being able to access the endpoints via a URL?
Thanks
Daniel
I think you might be over-thinking this. The WSDL will specify all endpoints and their policies. Clients can specify which endpoint to use for communication.
You don't need to navigate to the URL of the endpoint.