Is it possible to define a WCF backup list in a client, so that a single-point-of-contact routing service is not nessasary?
I have two services implementing the same contact (interface). If the first service is not avaliable I would like the client to know that the backup service is to be used.
Is this possible or do I have to create a routing service (single-point-of-contact) that the client would communication with?
<client>
<endpoint address="http://localhost:49192/OrdinaryCustomerService.svc"
binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_ICustomer"
contract="OrdinaryCustomerServiceReference.ICustomer" name="OrdinaryCustomerService" />
<endpoint address="http://localhost:49860/PremiumCustomerService.svc"
binding="basicHttpBinding" bindingConfiguration="BasicHttpBinding_ICustomer"
contract="PremiumCustomerServiceReference.ICustomer" name="PremiumCustomerService" />
</client>
<routing>
<backupLists>
<backupList name="CustomerBackupList">
<add endpointName="PremiumCustomerService"/>
</backupList>
</backupLists>
</routing>
Just an idea but i have a similar issue and i have been thinking about creating a routing service on the client (IIS webserver in my case) so that all request on the webserver can fail over to different web services. We also have multiple webservers for fail over so i would put a router on each.
Not ideal but best solution i have found so far. If the router on the IIS box goes down chances are the IIS will be down as well and therefore our system would have kicked over tot he other webserver anyway.
We also have proper wfc routers with backup for our middle teir but before it was a manual change to the webservice to handle this.
Related
My WCF service exposes an https AND an http endpoint. Apart from the SSL they are identical. They map to the same code.
The ultimate intention is for external users to connect via https, internal users to use http.
In development this gives me a problem. Cassini, the development web server packaged in VS, hates SSL.
I'm wondering if I can configure the service from code, so when running under Cassini, I would not configure https.
Hence the question - How do I configure the service from code if it is IIS hosted? I'd be very happy with alternative answers on how I can persuade Cassini to NOT complain about the https part of the configuration.
"IIS will take care of spinning up the necessary ServiceHost based on your *.svc file - not a whole lot you can do about that, really."
Not too close to the truth. Exactly in the SVC file of your service there is attribute named Factory. Where you can specify the the class and the assebly where the class is located. This class may be your own descendant of Web|DataServiceHostFactory
So your svc markup would look like this
<%# ServiceHost
Language="C#"
Debug="true"
Service="name.space.myService"
CodeBehind="name.space.myService.svc.sc"
Factory = "name.space.WebServiceHostFactoryEx, assembly.name"
%>
The WebServiceHostFactory will be created for every service hit and will recreate your host the way you want it.
You will also need to inherith WebServiceHost and create it the way you need it with certain endpoins, behaviors, addresses, etc settings - whatever you like.
There is very nice post from Michele Bustamante here
EDIT: I figured out the above link is not working anymore, so here it is another one.
I am using this in IIS hosted enviroment for couple of services that are initialized same way.
When you're hosting in IIS, you're leaving a lot of care taking into the realm of IIS - you cannot really grab a hold of your service in this case.
IIS will take care of spinning up the necessary ServiceHost based on your *.svc file - not a whole lot you can do about that, really.
My solution would be different - externalize the <service> tag in your configuration file (web.config):
<system.serviceModel>
<services>
<service configSource="service.dev.config" />
</services>
</system.serviceModel>
In your dev environment, only expose the http endpoint - so your service.dev.config would look something like this:
<service name=".....">
<endpoint name="default"
address="....."
binding="basicHttpBinding" bindingConfiguration="insecure"
contract="......" />
</service>
Create a second service.prod.config which then contains both endpoints - http and https:
<service name=".....">
<endpoint name="default"
address="....."
binding="basicHttpBinding" bindingConfiguration="insecure"
contract="......" />
<endpoint name="secure"
address="....."
binding="basicHttpBinding" bindingConfiguration="secure"
contract="......" />
</service>
and reference that in your web.config on the deployment server.
I'm trying to get my head around the addressing of WCF services.
We have a client-server setup where the server occasionally (maybe once a day) needs to push data to each client. I want to have a lightweight WCF listener service on each client hosted in an NT service to receive that data. We already have such an NT service setup hosting some local WCF services for other tasks so the overhead of this is minimal.
Because of existing legacy code on the server I believe the service needs to be exposed as ASMX and use basicHttpBinding to allow it to connect.
Each client is registered on the server by the user (they need to configure them individually) so discovery is not the issue.
My question is, how does the addressing work? I imagine the user entering the client's address on the server in the form
http://0.0.0.0/MyService
or even
http://hostname/MyService
If so, how do I configure the client service in its App.config? Do I use localhost?
If not then what is the reccommended way of exposing the service to the server?
Note:
I don't want to host in IIS as that adds extra requirements to the hardware required for the client.
The clients will be almost certainly located on LANs, not over the public internet
You configure the base address of the service like so:
<system.serviceModel>
<services>
<service name="Ns.FooService">
<host>
<baseAddresses>
<add baseAddress="http://localhost:9999" />
</baseAddresses>
</host>
<endpoint
address="/foo"
binding="basicHttpBinding"
contract="Ns.IFooContract" />
</service>
</services>
</system.serviceModel>
And then your service could be accessible through http://servename:9999/foo. You may take a look at this article for more information.
I've been having major problems with WCF, which are not amenable to any wisdom I can find. I've tried basicHttpBinding, wsHttpBinding, netTcpBinding (with the Net.Tcp service running on both machines). The behaviour can be boiled down to:
works on same machine, when running in debugger, standalone (non-service) process, Windows service
cannot be accessed from other machine, unless I'm running the service in the debugger
I must confess to being baffled by the plethora of options for bindings/security/etc. I must also confess to being ignorant of the restrictions on running as a Windows service, although I'm sure I've read somewhere that the SYSTEM account does not have network credentials. I've tried running the service under my own credentials, with the same results.
I'm up against a deadline in a few hours, and at the moment I'm going to have to resort to running as a standalone process, which is pretty embarassing.
I'm sure I've made some simple but crucial mistake in my understanding, and would be happy to be enlightened. But for now I'd be happy if someone knows a quick and dirty way to run WCF between two machines on the same Windows network without any security necessary, where one is a windows service and the other is a Windows GUI app.
This calls for the NetNamedPipe binding (on-machine communication)!
Your config would have to look something like:
<system.serviceModel>
<bindings>
<netNamedPipeBinding>
<binding name="NoSecurityIPC">
<security mode="None" />
</binding>
</netNamedPipeBinding>
</bindings>
<client>
<endpoint name="internal"
address="channel1"
binding="netNamedPipeBinding"
bindingConfiguration="NoSecurityIPC"
contract="IYourService" />
</client>
<services>
<service name="Namespace.YourService">
<host>
<baseAddresses>
<add baseAddress="net.pipe://localhost/" />
</baseAddresses>
</host>
<endpoint
address="channel1"
binding="netNamedPipeBinding"
bindingConfiguration="NoSecurityIPC"
contract="IYourService" />
</service>
</services>
</system.serviceModel>
Marc
Is it a Windows Firewall issue? BasicHttpBinding defaults to security mode "none", and setting it on netTcp for client and service is as simple as putting a security mode="none" element under the root binding element in both the client and server config. Seems like the firewall on the server would be the only thing that'd keep you from connecting if the security mode is set to none.
1) as well as opening the firewall, you almost certainly need to explicitly permit binding the serving port via the APIs on HTTP.SYS. This can be done by the built in netsh http add command on Vista or later, via the downloadable httpcfg tool on earlier systems, or by directly P/Invoking against the HTTP APIs with administrative privilege as a set-up step.
2) if you have multiple services, getting them to share the address space on a given port is far easier if they talk HTTP than net.tcp
3) as a default, a service that talks across the network should be run with Network Service identity, ideally as a service-specific SID : even if the data are not sensitive, exposing a high privilege user like System on the network is not good practice.
I hope this is a quick question. I have a WCF service running on IIS port 4040. I have added the following headers to this service
4040 (non load balanced domain)
4040 localhost
So locally I can reference this service as http://localhost:4040/service.svc and also by the fully qualified domain name. This is no problem for all the services on this machine, I can reference everything by localhost:4040
The issue comes when I try to access it from another server (as we have other apps that need to consume the service)
I get a 404 error, and was wondering whether the service is defaulting to being exposed on localhost loopback (127.0.0.1) therefore cannot be accessed.
The endpoint is defined as such:
<service behaviorConfiguration="ClaimChaseBehavior"
name="Modules.EClaims.ClaimChase">
<endpoint address=""
binding="basicHttpBinding"
contract="Domain.EClaims.DataInterfaces.IClaimChase" />
<endpoint address="mex" binding="mexHttpBinding"
contract="IMetadataExchange" />
</service>
Notice I don't define an address. The reason for this is to allow us to have a common config file (we are trying to get around defining machine domains/addresses and thus multiple configs)
Is there a way to make the WCF default to the machine IP instead of the loopback connector without defining the actual domain name
Hope this makes sense
Regards
Richard
When you're hosting your service in IIS, the address of the service is defined and controlled by the location of your *.svc file - you cannot override that by defining base addresses or explicit address on your service endpoints.
The service address will always be:
http://machinename/VirtualDirectory/YourService.svc
Marc
Check your web config. Have you spesified that the address of the service is localhost?
EDIT:
On second thoughts, it looks like a firewall problem, is port 4040 blocked by a local firewall?
I'm connecting a WCF client to a group of services all implementing the same contract and all at the same host. I was hoping that there would be a way to combine the endpoint definitions to cut down on configuration clutter. I also would rather not do it programmaticly - just by configuration. Right now, my config has this repeated many times:
<endpoint address="http://hostname/ServiceA.svc"
binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_MyBinding"
contract="ServiceReference.ISearchService" name="ServiceA">
</endpoint>
<endpoint address="http://hostname/ServiceB.svc"
binding="wsHttpBinding" bindingConfiguration="WSHttpBinding_MyBinding"
contract="ServiceReference.ISearchService" name="ServiceB">
</endpoint>
// continued for ServiceC, ServiceD, etc
For server configurations, there is some notion of "baseAddressPrefixFilters" that can be used for this purpose - is there anything for client configuration?
There is the concept of a base address in WCF - unfortunately, that only works if you self-host, e.g. host your service in a console app or NT service. However, that only works on the server side - there's nothing similar on the client side. On the client side, you always have to define the complete, full service address your endpoint should connect to.
If you host in IIS, your service address is determined by the server name, the virtual directory (and possibly subdirectories under that) and the name of the *.svc file used to host the service in IIS. This is a fixed system convention and you cannot influence it, unfortunately (.NET 4 will bring some remedy to that).