I'm about to go and visit a client where we've been having some odd connectivity issues talking to a WCF based service. The WCF service is being hosted by a windows service rather than IIS.
On the client side I'm happy to use fiddler and I'm also using WCF tracing at the server end to generate a service trace file. On the wire I can use WireShark to see what's going on, my worry is that there is a little black hole between the windows network stack and the web service at the server end.
Does anyone know of a network shim or something that can grab the data at the server end between windows and the WCF service? (or can I configure fiddler to do this?)
Related
I have an ARM embedded processor that talks to a .net WCF SOA (SOAP) web service application. The ARM device is remotely located and web service is hosted in a WS2k8 cloud server. I am having some protocol issues with the ARM code and would like to run Fiddler on my WS2k8 machine to observer the SOAP exchange between the embedded device and the web service application. I installed Fiddler Web Debugger V4.4.8 on the server but it does not capture any http requests. I know the ARM device is talking to my web services as it responds to several good SOAP exchanges. Anyone know how to set up Fiddler to work in the configuration I have explained?
Best Regards,
Steve Mansfield
Fiddler is a proxy, it captures any requests sent to it. If your ARM device supports a proxy, then point its proxy settings at the Fiddler endpoint on the Windows Server, port 8888. Also tick Allow Remote Clients to Connect in the Tools > Fiddler Options > Connections tab, and restart Fiddler.
If the client doesn't support configuring a proxy, you need to Use Fiddler as a Reverse Proxy.
They way I fixed it was to set in the client application to use a proxy (http://127.0.0.1:8888) so now the calls are redirected to fiddler and fiddler call the services, so I can see the traffic. Hope it helps someone
We have a client server application.
My application need to be changed to work via WCF service in order to receive/send data to the database (security demands).
I also need another service which be hosted at the client side and will connect the client to the WCF service on the server side connect with Https.
The WCF service on the server is in PerSession mode.
Most of my work with the server is insert / select queries.
So my design is:
Client ->windows service ->WCF server service(iis7) ->database.
This windows service act as client and as server at the same time.
Act as server: for the Client application.
Act as client for the WCF service which located at the server.
The application needs to support XP and forward operating systems with .net 4.
The windows service will need to connect the WCF service on demand only (when the client application is launched).
I need to decide in which way to implement the client windows service.
I prefer to implement it with WCF hosted service with TCP/IP, but it feels like over kill to do so.
Should I use other IPC implementations? And if so which one?
So, what is the best way to implement this Windows service?
Thanks
I do not fully understand the point why a windows service should be used on the client side in order to communicate with the WCF service. But the question was not about architectural patterns...
So, for inter-process communication I would use NetNamedPipeBinding.
You can find more information on how to decide which binding to use here.
Using a WCF service for inter-process communication does not feel overkill to me at all. Actually WCF services are quite lightweight except the host initialization process, which should not happen frequently in case of a windows service I guess. WCF provides reliability and extensibility in exchange for this tiny inconvenience.
[EDITED]
I just reread you post, and I would like to clarify some details about the hosting. You can host a WCF service in a Windows Service, which is explained here, but not the other way around. Sorry, if I misunderstood your question. And yes, TCP/IP for inter-process communication is definitely an overkill, but NetNamedPipeBinding uses shared memory according to this article, so it should be the fastest way.
On 1st server, there is wcf service hosted in windows managed service. On the 2nd server, there is another wcf service, hosted in their own windows managed service. I try to connect to 1st service from the inside of the 2nd service, but I become a exception "The socket connection was aborted". With same configuration and same code I successfully connect from console application and winform application, but not from this windows managed service.
Configure your WCF services on both servers to perform diagnostic logging. Follow the instructions in http://msdn.microsoft.com/en-us/library/ms730064.aspx to achieve that.
Make sure the account your service on server 2 is running under is capable of connecting to server 1. This is a typical difference between the client test you did (and worked) and a service running on that system. For a test, make the service on server 2 run under your personal login credentials.
I've got a WCF service on a server on one side of a firewall. I need to access the service from many workstations on the other side of the firewall. The network guys insist that all holes through the firewall are one-to-one so at the mo, I'll have to set up every workstation one by one. There could be loads and it'll get tedious and be prone to errors.
Is it possible to set up a WCF server on this side of the firewall that can in some clever way just act as a proxy to the 'real' WCF service on the other side of the firewall? If so, could you point me to some reference material?
There is a new concept of a WCF Relay service being developed for the Windows Azure "cloud" computing space. That would allow you to create your scenario fairly easily - just host some bits of your service out in the cloud.
See these links for more information:
WCF services hosted on Windows Azure
Software in the cloud: the Relay service
.NET ServiceBus: Hands-On with Relays
or search Google for "WCF Relay Service". There are also a number of new bindings specifically for these WCF scenarios.
Hope this helps.
Marc
UPDATE:
WCF v4 - to be released with .NET 4.0 later this year (2009) will include a RoutingService class which can be used in scenarios like this.
See more info about the WCF4 routing service here:
Content based routing in WCF 4
Routing messages in WCF 4.0
A developer's introduction to WCF .NET 4 Beta 1
I have a few suggestions, maybe one would work in your case:
Place the WCF service outside the firewall. If the WCF service needs to talk to the database, open the database port for the IP address of the machine running the WCF service.
Program or use code generation to create a WCF service that is simply a pass through layer
There may be some functionality in your firewall that allows you to publish an end point
Does anyone recognise this error?
The SecurityContextSecurityToken with context-id=urn:uuid:xxx (key generation-id=) is not registered
It has suddenly appeared in the service trace log of my WCF service.
We had a Windows service successfully transmitting data into the WCF service for a day until it broke. The error manifests when the Windows service tries to connect to the WCF service.
It's highly unlikely that the environments changed. The two services exist on separate machines (an application server and a web server). Both are Windows Server 2003 SP1 machines, and the web server is running IIS 6.
Unfortunately, we have scarce access to the servers to help us debug, so any guesses on what might be wrong would be highly appreciated.
Indi
We had this problem with Web Service Extension 3.0, which was used before WCF. I have not experianced this with WCF, but I think that it is worth checking.
The scenario works like this:
The service starts and the user that is the identity of the service gets logged on.
When the service makes a call it is done in the security context of this user
After a while the logon token becomes so old (a day?) that the service will no longer accept it.
The easy way to test this is to restart the windows service.