I am planning to publish my Web Service so it can be used on outside network. The issue comes about is that the Web Admins do not want to make this web service external but want me to wrap a proxy around it and make the proxy external. I am not liking the proxy part due to than having to maintain versioning on both the Service and the Proxy. I was wondering if there is a simple way to do this, if you accessing the webservice using outside network (URL) to use SSL and request authentication but if you are using it in internal network (URL) to not request authentication or SSL. I tried having two endpoint configuration in webconfig one secure and one not secure but the problem is when you consume the webservice both bindings show and the client can choose one or the either. If anyone has done this differently or reccomends a different way let me know, usually I do one approach either all secure or all non secure but not different depending on network. Thanks much :)
You'll be please to know that WCF has built-in support for your 'Proxy'. It is called the Routing Service and is available in WCF 4.0 and later.
You can configure it to route the internet calls for a certain service contract to the WCF service running in your intranet. It can even translate bindings so that your internal service using TCP bindings can be called by external customers using a HTTP binding that can pass through your firewall.
It only needs to know what contracts to route to where. So no need to update it when your contracts change...
See here for more info.
EDITED: The following example system.serviceModel node allows a client to add a service reference to the routed service. The trick is to let the routing service impose itself as the service(s) it is routing to. See the serviceActivations node for that. Note that this removes the need to have a .svc file.
Next we define two endpoint filters to redirect the requests for the service to the routed service and the requests for the mex endpoint (which exposes the metadata) to the mex endpoint of the routed service. See the filters node for that.
Last, we explicitly disable exposing the metadata of the routing service itself via http to force clients to use mex (which we are routing) for the discovery. See the serviceBehaviors node for that.
EDITED AGAIN: added solution for mex size limit
<system.serviceModel>
<serviceHostingEnvironment>
<serviceActivations>
<!--Lets the routing service impose himself as Service.svc (No .SVC file is needed!!!) -->
<add service="System.ServiceModel.Routing.RoutingService" relativeAddress="Service.svc" />
</serviceActivations>
</serviceHostingEnvironment>
<bindings>
<wsHttpBinding>
<!-- a mexHttpBinding is in fact a wsHttpBinding with security turned off -->
<binding name="mexBinding" maxReceivedMessageSize="5000000">
<security mode="None"/>
</binding>
</wsHttpBinding>
</bindings>
<behaviors>
<serviceBehaviors>
<behavior >
<!-- Use the filter table with the name 'Filters' defined below -->
<routing routeOnHeadersOnly="false" filterTableName="Filters"/>
<serviceDebug includeExceptionDetailInFaults="true"/>
<!-- Disable exposing metadata for this routing service to force discovery using mex -->
<serviceMetadata httpGetEnabled="false"/>
</behavior>
</serviceBehaviors>
</behaviors>
<routing>
<filters>
<!-- Declare a routing filter that filters on endpoint Service.svc -->
<filter name="WcfServiceFilter" filterType="EndpointAddress" filterData="http://localhost/ServiceRouter/Service.svc" />
<!-- Declare a routing filter that filters on mex endpoint of Service.svc -->
<filter name="WcfServiceFilter.mex" filterType="EndpointAddress" filterData="http://localhost/ServiceRouter/Service.svc/mex"/>
</filters>
<filterTables>
<!-- Declare the routing table to use -->
<filterTable name="Filters">
<!-- requests that match the WcfServiceFilter (declared above) should be routed to the client endpoint WcfService -->
<add filterName="WcfServiceFilter" endpointName="WcfService"/>
<!-- requests that match the WcfServiceFilter.mex (declared above) should be routed to the client endpoint WcfService.mex -->
<add filterName="WcfServiceFilter.mex" endpointName="WcfService.mex"/>
</filterTable>
</filterTables>
</routing>
<services>
<!-- Declare our service instance and the endpoints it listens on -->
<service name="System.ServiceModel.Routing.RoutingService">
<!-- Declare the endpoints we listen on -->
<endpoint name="WcfService" contract="System.ServiceModel.Routing.IRequestReplyRouter" binding="wsHttpBinding" />
<endpoint name="WcfServiceFilter.mex" address="mex" contract="System.ServiceModel.Routing.IRequestReplyRouter" binding="mexHttpBinding" />
</service>
</services>
<client>
<!-- Define the client endpoint(s) to route messages to -->
<endpoint name="WcfService" address="http://localhost/WcfService/Service.svc" binding="wsHttpBinding" contract="*" />
<endpoint name="WcfService.mex" address="http://localhost/WcfService/Service.svc/mex" binding="wsHttpBinding" bindingConfiguration="mexBinding" contract="*" />
</client>
</system.serviceModel>
Related
I have created a WCF service which is hosted in IIS and that tries to call another web service (3rd party) to return some data. When trying to connect the service fails with the following error:
There was no endpoint listening at https://xxx (3rd party ws) that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.
And this is while, my service is up (i know from my echo method) and it works successfully if it is self hosted.
I have the whole and sections copied to the model of web.config exactly as it is for the self hosting test but something still is missing.
I have been through other similar problems reported but mine is little bit specific in that the service is kind-of hosting another one and that one is causing the issue.
I can try to exlain better with a real example:
There is a simple web service here: http://www.dneonline.com/calculator.asmx which I want to wrap inside our library and provide access to via an IIS hosted WCF.
So, a class library is created (Calculator project) to with one method, add to take two int arguments and use them to call the web service add method. The webservice is referenced as a Service Reference inside the library and is being addressed inside from within the config library app.config file like below:
<configuration>
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="CalculatorSoap" />
</basicHttpBinding>
</bindings>
<client>
<endpoint address="http://www.dneonline.com/calculator.asmx"
binding="basicHttpBinding" bindingConfiguration="CalculatorSoap"
contract="Service.CalculatorSoap" name="CalculatorSoap" />
</client>
</system.serviceModel>
</configuration>
Then there is a WCF class library (CalcService project) which uses the first class library to enable http endpoints. Again, the app.config file includes endpoints both as for the service itself and as a client of the class library. The app.config file looks almost like this:
<configuration>
<system.serviceModel>
<services>
<service name="CalcService.Calc">
<host>
<baseAddresses>
<add baseAddress = "http://localhost:8733/Design_Time_Addresses/CalcService/Calc/" />
</baseAddresses>
</host>
<!-- Service Endpoints -->
<endpoint address="" binding="basicHttpBinding" contract="CalcService.ICalc">
<identity>
<dns value="localhost"/>
</identity>
</endpoint>
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
</service>
</services>
<!-- Client endpoint, i.e. to be able to use the calculator.asmx service addressed in the class library -->
<client>
<endpoint address="http://www.dneonline.com/calculator.asmx"
binding="basicHttpBinding"
contract="Service.CalculatorSoap" name="CalculatorSoap" />
</client>
<behaviors>
<serviceBehaviors>
<behavior>
<serviceMetadata httpGetEnabled="True" httpsGetEnabled="True"/>
<serviceDebug includeExceptionDetailInFaults="True" />
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
</configuration>
I am able to test the whole thing via a console application that makes a call to the WCF service and receives an answer. The console application config file has only one client endpoint to the WCF like below:
<configuration>
<system.serviceModel>
<client>
<endpoint address="http://localhost:8733/Design_Time_Addresses/CalcService/Calc/"
binding="basicHttpBinding" contract="Calculator.ICalc" name="BasicHttpBinding_ICalc" />
</client>
</system.serviceModel>
</configuration>
My question is now how I can host the WCF service inside IIS? I have tried different ways but neither one worked. My current IIS project (which doen't work) looks like this:
1-Has project references to both prevoius projects (Class Library and WCF Service) so two dll files are being added to the references:
CalcService.dll
Calculator.dll
2-Has a CalcService.svc file which creates a ServiceHost toward the CalcService:
<%# ServiceHost Language="C#" Debug="true" Service="CalcService.Calc"%>
3-Has a web.config with cliend endpoint to calculator.asmx:
<system.serviceModel>
<bindings>
<basicHttpBinding>
<binding name="CalculatorSoap" />
</basicHttpBinding>
</bindings>
<client>
<endpoint address="http://www.dneonline.com/calculator.asmx"
binding="basicHttpBinding" bindingConfiguration="CalculatorSoap"
contract="Service.CalculatorSoap" name="CalculatorSoap" />
</client>
<!-- some other settings -->
</system.serviceModel>
Now, when tested with a simple client to make a call to the calculator add method it fails with the following error:
There was no endpoint listening at http://www.dneonline.com/calculator.asmx that could accept the message. This is often caused by an incorrect address or SOAP action. See InnerException, if present, for more details.
I don't know which message the endpoint is expecting, I could just assumed it has to be Service.CalculatorSoap as it worked before from the console application.
On the other hand, what confuses me is that a self hosted WCF also works (via http://localhost:8733/Design_Time_Addresses/CalcService/Calc/ from the config file in the WCF class library project).
I don't know what is missing here, is it something from the IIS configuration or permissions?
Or someting else like the windows firewall setting like explained in this post:
https://social.msdn.microsoft.com/Forums/vstudio/en-US/bec3ab7a-310e-415f-b538-6d5681e5e53c/there-was-no-endpoint-listening-at?forum=wcf
Just note that since I am using a company computer, I'm not able to shut down the firewall. I can just turn on/off some of the rules.
I hope it is clear now what we are after.
We tested the solution on a cloud based machine and it worked fine. In the end it looked to be some firewall rules blocking the IIS outgoing calls and nothing was wrong in the configuration files or in the code.
I have been trying to resolve a problem that I am having with a WCF service hosted on our cloud platform. Service is written targeting .NET 4.0. I can access the service using both wsHttpBinding and basicHttpBinding over just plain http. However, when I try and access the service over a https end point it consistently gives me an endpoint not found exception which is odd because on the client I add a service reference pointing at the https end point and this should be sufficient to build a compatible proxy?
The web site has a SSL certificate setup which is valid, and the site hosting the service has a binding in IIS that uses this certificate. I can browse to the https URL from within the IIS snap-in and it finds the service with no problems, and I can use the same url from my desktop and get the normal "you have created a service page". IIS has anonymous authentication enabled only.
Here is where I get a bit hazy on what I have to do in terms of the WCF configuration.
In the server web.config I have security mode of Transport and
client credentials of None (Think I need this because of the
anonymous authentication on the host service)
Also in the server web.config I have set up mex end points for each
of the server's end points that are defined.
Is there anything else I need to do here?
On the client side
I have created a basic console app, and create a service
reference pointing at the https url and this is found
In the code I instantiate the proxy and call a method that invokes
the service.
When I run the code I get the end point not found exception.
I have created a really basic ASP.NET web site on my local IIS that hosts a really simple service. I have added a self-signed certificate and in the mmc snap-in I have imported this as a trusted certificate. I have set up a wsHttp end point for both secure and non-secure and when I create a simple client that references the service I get the same problem when using a https end point.So I can replicate the problem I am seeing in the live environment.
The event viewer doesn't shed any light on anything untoward happening.On my various searches I found references to re-registering asp.net and the WCF runtime components. Tried all this to no avail. Getting really stuck. I've included the config from my local asp.net web site, and the client config so people can scan what I have. Any suggestions on what else I could try would be great. I'm hoping I have overlooked something obvious that another pair of eyes with more experience with WCF can spot.
Thanks in advance.
Server config:
<system.serviceModel>
<diagnostics>
<messageLogging logEntireMessage="true" logMalformedMessages="true" logMessagesAtServiceLevel="true" logMessagesAtTransportLevel="true" maxMessagesToLog="500" />
</diagnostics>
<services>
<service name="NorthwindServices.ProductService">
<host>
<baseAddresses>
<add baseAddress="http://localhost:8732/Design_Time_Addresses/NorthwindServices/ProductService/" />
</baseAddresses>
</host>
<endpoint address="" binding="wsHttpBinding" contract="NorthwindServices.IProducts">
<identity>
<dns value="localhost" />
</identity>
</endpoint>
<endpoint address="mex" binding="wsHttpBinding" contract="IMetadataExchange" />
</service>
</services>
<bindings>
<wsHttpBinding>
<binding name="Secure">
<security mode="TransportWithMessageCredential">
<transport clientCredentialType="Basic">
</transport>
</security>
</binding>
</wsHttpBinding>
</bindings>
<behaviors>
<serviceBehaviors>
<behavior name="">
<serviceMetadata httpGetEnabled="true" />
<serviceDebug includeExceptionDetailInFaults="false" />
</behavior>
</serviceBehaviors>
</behaviors>
<serviceHostingEnvironment multipleSiteBindingsEnabled="true" />
</system.serviceModel>
</
==================================================================================
Client config:
<?xml version="1.0" encoding="utf-8" ?>
<configuration>
<system.serviceModel>
<bindings>
<wsHttpBinding>
<binding name="WSHttpBinding_IProducts">
<security mode="Transport"></security>
</binding>
</wsHttpBinding>
</bindings>
<client>
<endpoint address="https://localhost/Northwind.svc" binding="wsHttpBinding"
bindingConfiguration="WSHttpBinding_IProducts" contract="ProductProxy.IProducts"
name="WSHttpBinding_IProducts">
<identity>
<dns value="localhost" />
</identity>
</endpoint>
</client>
</system.serviceModel>
</configuration>
BindingConfiguration is optional since an endpoint is primarily composed of address, binding and contract. If no wsHttpBinding is defined under bindings, the default configuration will be used; if there's one under wsHttpBinding without name or with empty name, the binding configuration will be used if the endpoint does not declare a named one. And you may have multiple named binding configuration under wsHttpBinding, and each endpoint may pick one accordingly. The problems so far according to your config files listed has nothing to do with bindingConfiguration as they all look fine. However, the baseAddress in service side and the client endpoint address do not seem to match, and I presume you are using svc files for service activation. Then you need to make sure the svc files are located in the right place through proper routing. Alternatively you may use config activation without using svc files.
I am new in WCF and start my experience with a simple file-less application part of which (web.config) you can see below:
<serviceHostingEnvironment multipleSiteBindingsEnabled="true">
<serviceActivations>
<add
factory="System.ServiceModel.Activation.ServiceHostFactory"
relativeAddress="./RelativeAddress.svc"
service="WCF_Transactions.MyService1"/>
</serviceActivations>
</serviceHostingEnvironment>
Now I can access service at
http://localhost:18148/RelativeAddress.svc
Then I add next lines:
<services>
<service name="WCF_Transactions.MyService1" behaviorConfiguration="MyBehavior1">
<host>
<baseAddresses>
<add baseAddress="http://localhost:18148/" />
</baseAddresses>
</host>
<endpoint address="/RelativeAddressX.svc" binding="basicHttpBinding" contract="WCF_Transactions.IService1"></endpoint>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="MyBehavior1">
<serviceMetadata httpGetEnabled="true" />
</behavior>
</serviceBehaviors>
</behaviors>
So I expect that my service could be accessible through next address:
http://localhost:18148/RelativeAddressX.svc
but I can't do this. What have I misunderstood?
MSDN http://msdn.microsoft.com/en-us/library/ms733749.aspx:
*
There are two ways to specify endpoint addresses for a service in WCF.
You can specify an absolute address for each endpoint associated with
the service or you can provide a base address for the ServiceHost of a
service and then specify an address for each endpoint associated with
this service that is defined relative to this base address. You can
use each of these procedures to specify the endpoint addresses for a
service in either configuration or code. If you do not specify a
relative address, the service uses the base address.
*
So according to your example you have base adress
http://localhost:18148/
and it will be combined with RelativeAddress.svc, as a name of your svc file. And then it will try to combine this string with /RelativeAddressX.svc as a part of endpoint adress. So you will have something like
http://localhost:18148/RelativeAddress.svc/RelativeAddressX.svc.
Your endpoint must not specify the path to svc in IIS. It should containg only a logical adress, assosiated with this point.
So try to change your endpoint to the following:
<endpoint address="RelativeAddressX" binding="basicHttpBinding" contract="WCF_Transactions.IService1"></endpoint>
And it should be accessible by the path
http://localhost:18148/RelativeAddress.svc/RelativeAddressX
You don't need to specify in the config file when hosting in IIS or Cassini - the base URL is provided by the web server. The element is used when self-hosting. Cassini (VS build in web-server) will ignore it.
Here is a good page about WCF addressing:
http://msdn.microsoft.com/en-us/magazine/cc163412.aspx
Here are some related posts:
WCF Service Endpoints vs Host Base address
WCF, changing the baseAdress of an endpoint
First, I am not good in WCF.
I have a WCF service hosted in WindowsService.
Since sometime the service stoped to run because of the exception:
HTTP could not register URL http://+:8092/MyService/ because TCP port 8092 is being used by another application.
Nothing uses this port, it says the same about any port I tried.
SSL certificate is configured.
There are many machines that can start this service, but the most required (customer's) machine cannot.
I saw many posts in this site or anywhere else, but cannot find a solution.
I never see the post like "It helped me".
I am stuck several days already, help please.
Below the data from config file:
<system.serviceModel>
<services>
<service name="MyCompany.MyApp.MyAppService" behaviorConfiguration="MetadataSupport">
<host>
<baseAddresses>
<add baseAddress="http://localhost:8092/MyAppService" />
<add baseAddress="net.tcp://localhost:8093/MyAppService" />
<add baseAddress="net.pipe://localhost/" />
</baseAddresses>
</host>
<endpoint binding="wsDualHttpBinding" contract="MyCompany.MyApp.IMyAppService" />
<endpoint binding="netTcpBinding" contract="MyCompany.MyApp.IMyAppService" />
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange" />
<endpoint address="tcpmex" binding="mexTcpBinding" contract="IMetadataExchange" />
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="MetadataSupport">
<!-- To avoid disclosing metadata information,
set the value below to false and remove the metadata endpoint above before deployment -->
<serviceMetadata httpGetEnabled="True" httpGetUrl="" />
<!-- 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 httpHelpPageEnabled="True" includeExceptionDetailInFaults="True" />
</behavior>
</serviceBehaviors>
</behaviors>
</system.serviceModel>
You are using WCF duplex communication with wsDualHttpBinding. In this case, WCF creates a HTTP socket on port 8092 to service client callbacks. Clearly the client was conflicting with IIS 5.X. (I guess you have XP and IIS 5.x)
To resolve this problem you have to provide a clientBaseAddress in the binding configuration on the client and specify a different port.
Sample client configuration:
I hope that this is really the problem in your machine, please notify me about the results of this solution.
Good luck :-)
Try running the windows service as someone with admin privileges. Certain versions of Windows (2008/Vista and up) are picky about who can open ports. If that helps, then you certainly don't want to actually run the service as an admin, but it at least points you in the permissions direction.
Also, you mention an SSL cert, but it is an 'http' url, not 'https'. That seems unusual.
I suggest to do the following diagnostics steps:
Try hosting the WCF Service in a Self-Host manner (Console Application):
use the class HttpServiceHost
use this binding: var binding = new HttpBinding(HttpBindingSecurityMode.Transport);
AddServiceEndpoint(typeof(YourServiceClass),binding,"https://url...");
If it works for you it seems that you have problems in configuring the WCF service to work under Managed-Windows Service.
Lets me know your results :-)
Like the title says, we need to set up WCF services between a .NET app, and a Adobe AIR app. We don't want to run IIS on the machine, and would much prefer to install and run the WCF services hosted within a windows service.
However, I am uncertain of doing that will let us use HTTP as the transport, of does that only work within IIS? I was able to set things up to use the TCP transport, but that doesn't interop with AIR nearly as nice as using HTTP.
EDIT: Some test code I've been using to see if this works:
Regular console app:
static void Main()
{
using (ServiceHost host = new ServiceHost(typeof(TestService)))
{
host.Open();
}
Console.WriteLine("Waiting...");
Console.ReadLine();
}
TestService is a simple HelloWorld type service.
In the App.Config:
<configuration>
<system.serviceModel>
<services>
<service name="WCFExample2.TestService" behaviorConfiguration="WCFExample2.TestServiceBehavior">
<host>
<baseAddresses>
<add baseAddress = "http://localhost:8731/Design_Time_Addresses/WCFExample2/Service1/" />
</baseAddresses>
</host>
<!-- Service Endpoints -->
<!-- Unless fully qualified, address is relative to base address supplied above -->
<endpoint address ="" binding="wsHttpBinding" contract="WCFExample2.ITestService">
<!--
Upon deployment, the following identity element should be removed or replaced to reflect the
identity under which the deployed service runs. If removed, WCF will infer an appropriate identity
automatically.
-->
<identity>
<dns value="localhost"/>
</identity>
</endpoint>
<!-- Metadata Endpoints -->
<!-- The Metadata Exchange endpoint is used by the service to describe itself to clients. -->
<!-- This endpoint does not use a secure binding and should be secured or removed before deployment -->
<endpoint address="mex" binding="mexHttpBinding" contract="IMetadataExchange"/>
</service>
</services>
<behaviors>
<serviceBehaviors>
<behavior name="WCFExample2.TestServiceBehavior">
<!-- 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>
</behaviors>
</system.serviceModel>
</configuration>
You should have no trouble setting up a Windows NT Service which hosts your WCF service and exposes HTTP endpoints - no need for IIS (but the WCF runtime will use the http.sys kernel mode driver).
Have you tried and failed? If so - can you show us what you had, and how and where it failed?
As a bare minimum, you'd probably want to have something like this config on your service side:
<system.serviceModel>
<behaviors>
<serviceBehaviors>
<behavior name="Default">
<serviceMetadata httpGetEnabled="true"/>
</behavior>
</serviceBehaviors>
</behaviors>
<bindings>
<basicHttpBinding>
<binding name="Default"
sendTimeout="00:05:00"
maxBufferSize="500000"
maxReceivedMessageSize="500000" >
<security mode="Message">
<message clientCredentialType="UserName" />
</security>
</binding>
</basicHttpBinding>
</bindings>
<services>
<service name="Namespace.MyWCFService"
behaviorConfiguration="Default">
<host>
<baseAddresses>
<add baseAddress="http://MyServer:8282/MyWCFService/"/>
</baseAddresses>
</host>
<endpoint
address="basic"
binding="basicHttpBinding" bindingConfiguration="Default"
contract="Namespace.IMyWCFService" />
</service>
</services>
</system.serviceModel>
Of course, you might need to tweak things like the timeout settings, buffer size settings etc. on your binding, the security mode, and quite possibly other settings as you need them to be.
Marc
You could skip all the config and use the WebServiceHost class (which will do it all for you in a fairly standard way). Get that working then look into tailoring the config manually to meet any extra requirements you may have.
All the info you need is here WebServiceHost on MSDN it's a very straightforward way to get started on a custom (i.e. non IIS) hosted http service.
Mike
Apart from the config file settings one more thing to consider.
If you selfhost in a windows service, a http endpoint then
Make the service login account a local admin on the machine
or
You have to register the service account for the http namespace with http.sys.
This step has to be done by a local admin but only once in each machine. You can use the HttpSysCfg tool to do this in XP/win 2003. For vista/win 2008 use netsh.